This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Use cases: - open multiple autoplay videos in multiple browser windows or tabs (for example, when a user Ctrl-clicks on multiple video links) - move between windows or tabs that have audio playing in them (for example, when a user is listening to two radio stations) - minimise a window with a video playing in it. Desired behaviour: - media is paused (even if set to autoplay) when opened in a page that is hidden - media is paused when the page its on becomes hidden - media play resumes when the page its on becomes visible, if the media was playing when the page became hidden, or the media was set to autoplay and never started. Proposed solution: - provide media elements with a pauseifhidden attribute that defaults to true (but maybe an attribute with multiple possible values, to cope with a greater variety of use cases, would be more sensible?) Implementation: - this feature could make use of the work done on the Page Visibility API though it might also make sense for media to pause when the page its on loses focus, not just when the page becomes hidden. Prototypes: - for browsers that support the Page Visibility API I've built a demo that pauses video when it's hidden: http://www.samdutton.com/pageVisibility - for versions of Chrome that support the API (Chrome 13+) I've built an extension that uses the Page Visibility API to pause video playback in hidden tabs: https://chrome.google.com/webstore/detail/ojpfpnnblmkgkpobiamilejllmkfmflg
Hmm, is it likely that the page author knows whether or not to pause a video when it's in a background tab? For things like background music for a game I guess it would, but what about things like YouTube? Some people play music in the background on YouTube, while would probably not. An alternative (or complementary) approach would be to encourage user agents to provide tab-wide mute/unmute and pause/unpause functionality. If that were available, would you still require the pauseifhidden attribute?
(In reply to comment #1) > Hmm, is it likely that the page author knows whether or not to pause a video > when it's in a background tab? For things like background music for a game I > guess it would, but what about things like YouTube? Some people play music in > the background on YouTube, while would probably not. > > An alternative (or complementary) approach would be to encourage user agents to > provide tab-wide mute/unmute and pause/unpause functionality. If that were > available, would you still require the pauseifhidden attribute? I think you're right about background music -- and also for radio, podcasts, etc. However, I think there is still a need for pausing video on hidden pages. I can imagine a video player with a Pause If Hidden control, on by default -- though I also have doubts that many users would understand or use this. User agent mute/unmute/pause/unpause functionality sounds useful, but it doesn't solve the problem of opening multiple video links (in hidden tabs/windows) or when navigating between tabs/windows, each with playing media.
(In reply to comment #2) > I think you're right about background music -- and also for radio, podcasts, etc. > However, I think there is still a need for pausing video on hidden pages. > > I can imagine a video player with a Pause If Hidden control, on by default -- > though I also have doubts that many users would understand or use this. > > User agent mute/unmute/pause/unpause functionality sounds useful, but it > doesn't solve the problem of opening multiple video links (in hidden > tabs/windows) or when navigating between tabs/windows, each with playing media. Just to add an additional data-point here re: Audio. While looking at accessibility of <audio> there will be instances where the content author has included captioning associated to the audio-stream (think speeches, podcasts, etc.): in those instances adding accessible audio would actually require using the <video> element as that would be the only way to also include a region for visible (supporting) content, such as those caption files (or perhaps sign-language interpretation). Yet there is a strong likelihood that not all content consumers will require those supporting visual aids (and may want to have the audio portion in a background tab), so for your use-cases making a distinction between audio and video will introduce potentially unintended negative behaviors. I suspect that what is really required is that auto-start be disabled if a page is not visible, but once a stream is started, the end user can choose to send it to a non-visible tab/window without silencing the audio stream FWIW
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: Lets first see how many authors implement this via http://www.w3.org/TR/page-visibility/ before we add it at the markup level.