New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 26 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 153199



Sign in to add a comment

HTML5 Autoplay should be disabled for Session Restore

Project Member Reported by tommycli@chromium.org, Jul 10 2015

Issue description

When a user restores a session, there's no reason to Autoplay HTML5 Video and Audio.

For example, if Chrome updates in the middle of the night and restarts, HTML5 video and audio that was on those pages should not be autoplayed.
 
Blocking: chromium:153199

Comment 2 Deleted

I think this is reasonable provided it can be accomplished in an unobtrusive way. What does your implementation look like?
See also  crbug.com/486163  - Session restore should also restore the playing or paused state of streaming media. TL;DR: most streaming media doesn't have the ability to save or restore current playing state and play or pause point location.

Note we should also include autoplay audio in any change of this sort.
Cc: dalecur...@chromium.org
Hey guys:

My implementation is here: https://codereview.chromium.org/1233623006/

It doesn't save the timeline state. It just re-uses the 'autoplay requires user gesture' flag used by Android build.

This change impacts both video and audio tags.
Cc: rleider@chromium.org strobe@chromium.org
The impl looks good to me, nice reuse of the existing code paths!

+strobe,rleider from YouTube for their thoughts. tl;dr summary: When restoring previously opened pages on browser relaunch, we're considering disabling autoplay until a user interacts with the page. Do you foresee any issues with the YT player?

Comment 7 by strobe@google.com, Jul 13 2015

So:

- This is a divisive issue.

- I am actually in favor of a system like that used in Safari 8 *desktop*, where a video opened in a background tab will start playing as soon as that tab is foregrounded.

- I am absolutely, completely, viscerally opposed to spreading the experience-destroying contagion of the "user gesture requirement" as implemented on Mobile Safari and Mobile Chrome. This implementation violates the spec, is impossible to differentiate from the still-ongoing stuck-audio-output issues, and makes transitioning to a Promises-based internal architecture impossible (*everything* must be done synchronously from a user gesture for this to work, which is now impossible thanks to the heavy use of async code in new web APIs - we can't select a format now for HVC without going async, which means getting a video to play actually involves up to three taps on the video element). The mobile equivalent of this feature causes massive breakages on a regular basis. We're having to do insane things like create proxy implementations of the entire video element stack so that we can use a video element parented in a separate origin from the Media Source to make mobile embeds work properly, which is certain to cause even more delightful catastrophes and definitely breaks all of the new features we're adding like spherical.

Please please please don't implement this using a user gesture. Please please please please please please don't. Page visibility checks are fine.
Do you know what the difference between the two approaches is? I.e. in terms of what events that are fired which make one preferable to the other? We can certainly consider foregrounding the tab on desktop as a user gesture.
I support deferring autoplay until the tab is foregrounded (in all cases, not just session restore).

I also support disabling autoplay for even the foreground tab on session restore.

Comment 10 by strobe@google.com, Jul 13 2015

An important distinction: "defer playback if the tab is not foregrounded" in all circumstances breaks a critical use case for YouTube, which is playlists in a background tab. "Defer playback if a tab has *never* been foregrounded" seems like it wouldn't break this use-case as badly.
strobe: Yes, what you just said (#10) sounds right to me.
all: So... is this dead in the water due to the Youtube concerns? Or is this still viable?
Hmm, I thought you agreed with strobe@ above that it should be tied to foregrounding and we're going to implement that? I think using the current definition of a user-gesture-requirement is dead, however if that can also mean "video was foregrounded" and start playback, it's fine.
Oh, I must have been unclear.

I think deferring autoplay until the tab is foregrounded is good in all cases. It solves the issue for all session restored background tabs.

But what about the foreground session-restored tab? I think we should still some require some kind of user intervention before it starts playing.
One thing we could do is defer autoplay until 1) Tab has been foregrounded at least once AND 2) Chrome is not idle / screensaver / background.

That might solve the issues without breaking youtube.
I meant to say 1) The video / audio element has been visible at least once. Ideally we still defer below-the-fold videos.
strobe's main complaint seems to be that the user-gesture-requirement drops the play intent on the floor. So long as we're deferring and not dropping I think YT is okay.

I think idle is a good metric, but if the restore is automatic after a crash would that be detected as idle? I think just deferring foreground videos until mouse movement / non-idle behavior sounds good. If you're worried about impacts on startup time we can just add a flat time delay.
Cc: georgesak@chromium.org
While debugging another issue, I think I've found an easy way we can accomplish deferral with just a few lines of code:

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/render_frame_impl.cc&l=2042

This code used to defer the media load for prerendering and restart it once the user interacted with the page. Prerendering seems dead, but this piece remains, so we could use it for this feature. I'll try a quick prototype and see if it works.
Cc: derekjchow@chromium.org gunsch@chromium.org
Actually prerender isn't dead, it's just hiding in another file:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/renderer/chrome_content_renderer_client.cc&l=684

And it looks like Cast is already doing something like this:

https://code.google.com/p/chromium/codesearch#chromium/src/chromecast/renderer/cast_content_renderer_client.cc&l=214 

+gunsch, derekjchow for the CL they added it in https://codereview.chromium.org/824733002 -- in case they want to add anything about the implementation.
Correct, there are some cases on Cast in which we load a page in the background. We intentionally defer media loading until we bring that page to the foreground (https://code.google.com/p/chromium/codesearch#chromium/src/chromecast/renderer/cast_media_load_deferrer.cc&l=22).
https://codereview.chromium.org/1292433002/ -- doesn't use the cast loader since we'll want an idle notification as well for session restore and compentizing the code for sharing is a ton of overhead for a 10 line class.
Cc: -dalecur...@chromium.org tommycli@chromium.org
Owner: dalecur...@chromium.org
Project Member

Comment 24 by bugdroid1@chromium.org, Aug 19 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f9e7f4c43221c205982328021138a7ea54261ef

commit 0f9e7f4c43221c205982328021138a7ea54261ef
Author: dalecurtis <dalecurtis@chromium.org>
Date: Wed Aug 19 00:12:55 2015

Defer media playback in background tabs.

Videos which autoplay in the background will now have their load
deferred until the tab is visible for the first time -- this avoids
autoplay during session restore and premature playback.

Once a tab / RenderFrame has ever played media before, it's allowed
to continue to autoplay/autoload indefinitely; this is to support
playlist type applications.

BUG= 509135 
TEST=manual verification that background tabs don't autoplay;
playlist type media continues to work.

Review URL: https://codereview.chromium.org/1292433002

Cr-Commit-Position: refs/heads/master@{#344092}

[add] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/browser/media/defer_background_media_browsertest.cc
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/chrome_renderer.gypi
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/chrome_tests.gypi
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/renderer/BUILD.gn
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/renderer/chrome_content_renderer_client.cc
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chrome/renderer/chrome_content_renderer_client.h
[delete] http://crrev.com/2fc0baecacffffb7aa2d5a6c891667acda6d9c8c/chrome/renderer/prerender/prerender_media_load_deferrer.cc
[delete] http://crrev.com/2fc0baecacffffb7aa2d5a6c891667acda6d9c8c/chrome/renderer/prerender/prerender_media_load_deferrer.h
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chromecast/renderer/cast_content_renderer_client.cc
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/chromecast/renderer/cast_content_renderer_client.h
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/content/public/renderer/content_renderer_client.cc
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/content/public/renderer/content_renderer_client.h
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/content/renderer/render_frame_impl.cc
[modify] http://crrev.com/0f9e7f4c43221c205982328021138a7ea54261ef/content/renderer/render_frame_impl.h

tommycli: Do you know how we might go about including an idle check of the current tab?

Comment 26 by mtsmith@google.com, Aug 22 2015

Strobe: will this prevent background auto-nav (what we call "up next" or "the thing with the autoplay toggle") from working? That feature should definitely continue to work in the background.
dalecurtis: off the top of my head, no.

However, I know we do have an idle monitor in Chrome: https://code.google.com/p/chromium/codesearch/#chromium/src/ui/base/idle/

Maybe see if there's already an idle monitor in an accessible place like a render_frame. If not, perhaps just add one lazily. Those classes look quite lightweight.
@mtsmith: The change is on canary now, so if you have a page to test this with, you can link it here or verify it still works yourself.

In my tests I think I hit the auto-nav case and it was working. Navigations should preserve the render-frame so I expect it to still play.
Hey Dale, let me know once you implement the idle precondition for media load.

I'd like to reuse your implementation to provide the same logic for Flash plugin load.

That way, plugins and media behave consistently: both depend on tab being foregrounded + user being un-idle.

Then we will have successfully defeated this ancient bug: https://code.google.com/p/chromium/issues/detail?id=153199
Going to be a busy couple weeks and then I'm OOO for another couple, so I don't think I'll get to the idle handler soon. 
This change is so annoying for desktop users. For music I like to open with the middle click button without having to open the tab. Can this feature at least be turned off? I hate it.
Can there be a checkbox like in firefox there you can enable/disable auto loading?
I don’t this it’s annoying at all; on the contrary, I find the new behaviour very convenient.
We'll have a command line flag to disable the new behavior soon and a more accessible chrome://settings/content page design is in progress to allow more control.

Comment 35 by Deleted ...@, Dec 3 2015

Hi! Sorry for asking but does this still count as planned to be turnable? I couldn't find better place to ask.
Cc: -rleider@chromium.org
For session restore the behavior can't be changed, but if you want background tabs to autoplay on open you can toggle "disable user gesture requirement" in chrome://flags and click the restart button to get the old behavior.
Cc: dalecurtis@google.com chrisha@chromium.org
 Issue 531532  has been merged into this issue.
Status: Fixed (was: Started)
Fixed for the vast majority of cases in c#24 many versions ago.
This new behavior sucks and I can not re-enable it. 

I need background autoplay, and the flag mentioned here is no longer effective

Sign in to add a comment