Bugzilla

Thanks, Hamish, I will reply your comment on the issue today as well. Back to your questions here, first we need to know that the actual mechanism to block autoplay varies by different user agent, and it's hard to make all user agents to agree with using the same mechanism. Eg. Chrome uses their own media engagement index (`chrome://media-engagement/`) which is not available to other browsers. Therefore, Autoplay Policy Detection API wants to act as an interface to maximally generalize the difference between different mechanisms by returning simple answer.

> if the method returns allowed (or allowed-muted) for a type you're saying that you always expect it to be allowed - it is not going to the be the case where you'll change from allowed to disallowed due to some user interaction. So basically if you get those values back you can just assume them true in the session.

This assumption is true for most of mechanism so far I know. The only exception is Firefox's [transient user gesture policy](https://wiki.mozilla.org/Media/block-autoplay#Transient_user_gesture_activation) (optional, not default), which would only allow autoplay happening within a certain time window. After that, the autoplay would be blocked again, which means the result will become `disallowed` later.  

As that is the only case resulting in this situation and it's not common, we could discuss whether Firefox needs to keep this policy, or remove it in order to keep consistent with other user agents' policy.

> if the value returned is disallowed then you're saying that this is the default or "the policy" that applies generally to the page. However it might change or might not apply to all elements in the type -e.g. one of several elements might have been whitelisted through user interaction, so even though generally the page is disallowed, some elements might be allowed.

Yes, the policy can be changed later. And also some elements in the page could be exception. Like what [example 2](https://www.w3.org/TR/autoplay-detection/#example-4ae289b9) describes. This behavior currently happens Firefox's [click-to-play policy](https://wiki.mozilla.org/Media/block-autoplay#Click-to-play) (optional, not default).

> IN other words you don't need to recheck each element / context to be sure of its autoplay value except for the disallowed case.

In general, yes, if the `getAutoplayPolicy(type)` returns `allowed`/`allowed-muted`, web developers should expect that the only possible change for the result would be `allowed-muted` -> `allowed`. The only exceptional case is what I mentioned above, Firefox's [transient user gesture policy](https://wiki.mozilla.org/Media/block-autoplay#Transient_user_gesture_activation).

> So it is possible for different elements/contexts in a document to have a different return value?

Yes, eg. [example 2](https://www.w3.org/TR/autoplay-detection/#example-4ae289b9).

> If my assumptions above are all wrong, what is the point of having the type - presumably you'd always have to check all individual elements/contexts to be sure that you have set their behaviour correctly if you can't trust the single value returned.

Your assumptions are basically correct, except those exceptions I mentioned above. 

> So is this saying that if you click the element anywhere (not on some play control) that might be enough to say it is blessed, so it will autoplay automatically at that point. However the policy is still disallowed, even though the particular element is allowed?

No, in example 2 what I'd like to express is if the play is triggered by user's activation. Eg. click a button or a interface which will trigger element's play method.

Here is one example you can check on Firefox.
1. go to `about:config` and turn `media.autoplay.blocking_policy` to `2`
2. go to https://alastor0325.github.io/htmltests/autoplay_tests/iframe_a1_a2_a3.html (there will be three videos on the page)
3. click play on ONLY one of those three videos
4. you can see only the video you clicked is allowed to play, but other videos still remain blocked 

> But is there any similar "exception" for allowed or allowed-muted cases? I.e. are they "rough" like disallowed, or reliable?

Yes,  Above example can also be applied to the situation where `getAutoplayPolicy(type)` returns `allowed-muted`.

However, during testing, I found out the Firefox current implementation for `getAutoplayPolicy(type)` is not correct. After step3, the result of `getAutoplayPolicy(type)` shouldn't be changed. But now it would always be changed to `allowed` and I will file a bug to fix it.

Feel free to ping/NI me if you have more questions. Thank you so much.

Thanks, Hamish, I will reply your comment on the issue later as well. Back to your questions here, first we need to know that the actual mechanism to block autoplay varies by different user agent, and it's hard to make all user agents to agree with using the same mechanism. Eg. Chrome uses their own media engagement index (`chrome://media-engagement/`) which is not available to other browsers. Therefore, Autoplay Policy Detection API wants to act as an interface to maximally generalize the difference between different mechanisms by returning simple answer.

> if the method returns allowed (or allowed-muted) for a type you're saying that you always expect it to be allowed - it is not going to the be the case where you'll change from allowed to disallowed due to some user interaction. So basically if you get those values back you can just assume them true in the session.

This assumption is true for most of mechanism so far I know. The only exception is Firefox's [transient user gesture policy](https://wiki.mozilla.org/Media/block-autoplay#Transient_user_gesture_activation) (optional, not default), which would only allow autoplay happening within a certain time window. After that, the autoplay would be blocked again, which means the result will become `disallowed` later.  

As that is the only case resulting in this situation and it's not common, we could discuss whether Firefox needs to keep this policy, or remove it in order to keep consistent with other user agents' policy.

> if the value returned is disallowed then you're saying that this is the default or "the policy" that applies generally to the page. However it might change or might not apply to all elements in the type -e.g. one of several elements might have been whitelisted through user interaction, so even though generally the page is disallowed, some elements might be allowed.

Yes, the policy can be changed later. And also some elements in the page could be exception. Like what [example 2](https://www.w3.org/TR/autoplay-detection/#example-4ae289b9) describes. This behavior currently happens Firefox's [click-to-play policy](https://wiki.mozilla.org/Media/block-autoplay#Click-to-play) (optional, not default).

> IN other words you don't need to recheck each element / context to be sure of its autoplay value except for the disallowed case.

In general, yes, if the `getAutoplayPolicy(type)` returns `allowed`/`allowed-muted`, web developers should expect that the only possible change for the result would be `allowed-muted` -> `allowed`. The only exceptional case is what I mentioned above, Firefox's [transient user gesture policy](https://wiki.mozilla.org/Media/block-autoplay#Transient_user_gesture_activation).

> So it is possible for different elements/contexts in a document to have a different return value?

Yes, eg. [example 2](https://www.w3.org/TR/autoplay-detection/#example-4ae289b9).

> If my assumptions above are all wrong, what is the point of having the type - presumably you'd always have to check all individual elements/contexts to be sure that you have set their behaviour correctly if you can't trust the single value returned.

Your assumptions are basically correct, except those exceptions I mentioned above. 

> So is this saying that if you click the element anywhere (not on some play control) that might be enough to say it is blessed, so it will autoplay automatically at that point. However the policy is still disallowed, even though the particular element is allowed?

No, in example 2 what I'd like to express is if the play is triggered by user's activation. Eg. click a button or a interface which will trigger element's play method.

Here is one example you can check on Firefox.
1. go to `about:config` and turn `media.autoplay.blocking_policy` to `2`
2. go to https://alastor0325.github.io/htmltests/autoplay_tests/iframe_a1_a2_a3.html (there will be three videos on the page)
3. click play on ONLY one of those three videos
4. you can see only the video you clicked is allowed to play, but other videos still remain blocked 

> But is there any similar "exception" for allowed or allowed-muted cases? I.e. are they "rough" like disallowed, or reliable?

Yes,  Above example can also be applied to the situation where `getAutoplayPolicy(type)` returns `allowed-muted`.

However, during testing, I found out the Firefox current implementation for `getAutoplayPolicy(type)` is not correct. After step3, the result of `getAutoplayPolicy(type)` shouldn't be changed. But now it would always be changed to `allowed` and I will file a bug to fix it.

Feel free to ping/NI me if you have more questions. Thank you so much.