Bug 1773551 Comment 17 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Thanks very much Alastor. I think I understand this. But please confirm my paraphrasing:
1. `getAutoplayPolicy(type)` returns the "default policy" for all items of a type assuming there is no user interaction.
   - This should not change across the life of a session even if individual elements become allowed due to specific user interaction 
   - (I guess we don't need to consider that it might change if the policy for the whole site changed mid-session - say due to a permission-policy change)
1. But on firefox (only, currently) you might change the status for a particular element/context by transient user interaction. This might cause the particular element associated with the interaction from autoplay disallowed to allowed-muted to allowed - right?, at which point it would play.
1. So on most browsers you could just rely on `getAutoplayPolicy(type)` and apply the result for all the items of the type. But on FF you might have the case where later on a particular element could still autoplay because of transient user interaction, so it would return allowed. 
1. This last case doesn't feel like "autoplay", which is why it is so confusing. The page has already loaded so it hasn't autoplayed - you've basically touched the control to cause it to play.

The use cases for autoplay blocking are generally to avoid surprising audio on page load, and the point of this API is to allow users to modify their content to play muted if they know it is going to be blocked (or some other strategy). So  `getAutoplayPolicy(type)` allows you to catch that particular content is disallowed or only will play if muted on page load, and format your content appropriately to allow autoplay.

Later on someone touches a particular control in FF changing autoplay policy for that element from allowed-muted to allowed. At this point the content could autoplay with sound? I guess the "bad case" here is that you might have made the content not have an audio track so the user will no longer be able to play this. 

1. Ultimately the question is do I recommend that developers?
   - just do the type check
   - always check every single element/item 
   - check for allowed using type, but if not allowed, then check every single element
   - something else?

My gut feeling is that on firefox at least, you type check for a policy of allowed, and for any other value you would always need to check every element. Was that your thinking?
Thanks very much Alastor. I think I understand this. But please confirm my paraphrasing:
1. `getAutoplayPolicy(type)` returns the "default policy" for all items of a type assuming there is no user interaction.
   - This should not change across the life of a session even if individual elements become allowed due to specific user interaction 
   - (I guess we don't need to consider that it might change if the policy for the whole site changed mid-session - say due to a permission-policy change)
1. But on firefox (only, currently) you might change the status for a particular element/context by transient user interaction. This might cause the particular element associated with the interaction from autoplay disallowed to allowed-muted to allowed - right?, at which point it would play.
1. So on most browsers you could just rely on `getAutoplayPolicy(type)` and apply the result for all the items of the type. But on FF you might have the case where later on a particular element could still autoplay because of transient user interaction, so it would return allowed. 
1. This last case doesn't feel like "autoplay", which is why it is so confusing. The page has already loaded so it hasn't autoplayed - you've basically touched the control to cause it to play.

The use cases for autoplay blocking are generally to avoid surprising audio on page load, and the point of this API is to allow users to modify their content to play muted if they know it is going to be blocked (or some other strategy). So  `getAutoplayPolicy(type)` allows you to catch that particular content is disallowed or only will play if muted on page load, and format your content appropriately to allow autoplay.

Later on someone touches a particular control in FF changing autoplay policy for that element from allowed-muted to allowed. At this point the content could autoplay with sound? I guess the "bad case" here is that you might have made the content not have an audio track so the user will no longer be able to play the audio. They'd be fine if your action had just been to mute the content. 

1. Ultimately the question is do I recommend that developers?
   - just do the type check
   - always check every single element/item 
   - check for allowed using type, but if not allowed, then check every single element
   - something else?

My gut feeling is that on firefox at least, you type check for a policy of allowed, and for any other value you would always need to check every element. At least this would be the case if your content should have audio but your removed it. Was this your thinking?

Back to Bug 1773551 Comment 17