Spec first version #1
Conversation
index.bs
Outdated
|
|
||
| ## Web Audio ## {#web-audio-integration} | ||
|
|
||
| Let |frame| be an <{iframe}>. Let {{Document}} |document| be the [=content document=] of one of |frame|'s [=child navigables=]. Let |audioContext| be an {{AudioContext}} in |document|. |
There was a problem hiding this comment.
iframe
What if the policy is applied to a top level document? Do we need to generlize this?
There was a problem hiding this comment.
Here's an example of a recent permission policy that might help us find the "right" terminology:
https://fetch.spec.whatwg.org/#available-deferred-fetch-quota
There was a problem hiding this comment.
Changed the terminology usage to be more precise. Main difference now is that I am taking into consideration whether the document's navigable is a top-level traversable. LMK what you think.
| Let |audioContext| be an {{AudioContext}}. Let {{Document}} |document| be the |audioContext|'s [=relevant global object=]'s [=associated Document=]. Let |navigable| be [=/Navigable=] whose [=active document=] is |document|. Let |navigableContainer| be the [=navigable container=] whose [=content document=] is |document|. | ||
|
|
||
| Amend the definition of [=allowed to start=] so that |audioContext| is also not [=allowed to start=] if all the following conditions are met: | ||
| - |navigableContainer| is not null; |
There was a problem hiding this comment.
Does this mean that the permission policy does not apply to top level documents?
There was a problem hiding this comment.
Yes. IIUC, top-level documents do not have a navigable container and thus cannot be "not rendered".
|
A quick question I’d like to raise is about the part of your proposal where media is prevented from playing again. I’m concerned this could create conflicts with system-level media controls. For example, if an iframe outside the viewport gets paused due to this spec, but the user later tries to resume it using system media controls—such as physical media buttons or the platform’s virtual media interface— while the iframe is still out of the viewport, then the iframe wouldn’t be able to resume correctly because the play/resume would be rejected. In addition, just as an FYI from our (Mozilla) past experience: pausing a media element from the browser is usually fine, but pausing Web Audio can cause issues, as some sites don’t expect their audio context to be externally paused. This can make it difficult for users to resume playback. The proposal sounds reasonable overall, but there are definitely more implementation-level details worth discussing, especially regarding Media Session, Audio Session, and Picture-in-Picture as mentioned in the meeting. |
|
Thanks for the comment @alastor0325! I created the issues below to track this upcoming work: |
There was a problem hiding this comment.
This spec looks good to us (Mozilla). I’ve left a few comments, and we’d be happy to discuss any follow-up issues. Please feel free to ping @padenot or me if you need any additional input from our side. Thanks!
|
Thanks for the feedback, @alastor0325 and @padenot! |
SHA: 098b399 Reason: push, by gabrielsanbrito Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
3 participants
Preview | Diff