Bug 1572869 Comment 4 Edit History

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

(In reply to Marc Streckfuß from comment #3)
> Speaking of [448910](https://bugzilla.mozilla.org/show_bug.cgi?id=448910), there is one take away though:
>  1. We might need a bug to track control of regular <video> and <audio> elements
All those things are based on controlling <video> and <audio> tags, so I don't understand why we need another bug to track them. 
Eg. In bug1575995, we are able to control those tags via mac play/pause key.

>  2. We have to think about in-app-focus. What happens if I open two videos in different tabs vs different windows etc.
Audio competing between tabs has been implemented in bug1565689. On Android, we have an android component to handle audio focus between apps.

>  3. We might need a bug to track combining all the bugs, wiering up the APIs
That's why we use this bug to track all related implementations.
(In reply to Marc Streckfuß from comment #3)
> Speaking of [448910](https://bugzilla.mozilla.org/show_bug.cgi?id=448910), there is one take away though:
>  1. We might need a bug to track control of regular <video> and <audio> elements

All those things are based on controlling <video> and <audio> tags, so I don't understand why we need another bug to track them. 
Eg. In bug1575995, we are able to control those tags via mac play/pause key.

>  2. We have to think about in-app-focus. What happens if I open two videos in different tabs vs different windows etc.

Audio competing between tabs has been implemented in bug1565689. On Android, we have an android component to handle audio focus between apps.

>  3. We might need a bug to track combining all the bugs, wiering up the APIs

That's why we use this bug to track all related implementations.

Back to Bug 1572869 Comment 4