Closed Bug 1588138 Opened 5 years ago Closed 5 years ago

Autoplay setting "Block Audio and Video" doesn't work when url changes without page refresh

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
71 Branch
Platform:
Desktop
Windows 10
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla73
Tracking Flags:
Tracking Status
firefox73 --- verified

People

(Reporter: sscarl24, Assigned: alwu)

References

(Regressed 1 open bug)

Details

Attachments

(1 file)

Bug 1588138 - reset blessed state when media aborting current load.
47 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

  1. Set Autoplay setting to "Block Audio and Video"

  2. Go to https://fmovies.to/film/the-x-files-2.kwzv9/2o0j9x2 notice this is 01 episode in F5-HQ server(just keep it in mind), look for a website setting below the player titled "Auto Play", activate it by ticking on it if it's not activated,

  3. Now in F5-HQ server episodes list, select/press on 02 episode and notice the autoplay is not blocked and the play button doesn't appear, inturn leading to buffering symbol.

As per the address of this page, the page is different, but the website simply replaces the address instead of causing a page load in which case the autoplay would have been blocked as seen in step 2 when we browsed to the page.

Actual results:

Autoplay didn't get blocked --

https://i.gyazo.com/10f92c25ecbdd5febb1a531b73140080.png

Expected results:

Autoplay should have been blocked like this and play button appearing --

https://i.gyazo.com/0b8e94068c9fb9bfdab19fd2a04138db.png

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

(In reply to uBlock-user from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

  1. Set Autoplay setting to "Block Audio and Video"

  2. Go to https://fmovies.to/film/the-x-files-2.kwzv9/2o0j9x2 notice this is 01 episode in F5-HQ server(just keep it in mind), look for a website setting below the player titled "Auto Play", activate it by ticking on it if it's not activated,

  3. Now in F5-HQ server episodes list, select/press on 02 episode and notice the autoplay is not blocked and the play button doesn't appear, inturn leading to buffering symbol.

As per the address of this page, the page is different, but the website simply replaces the address instead of causing a page load in which case the autoplay would have been blocked as seen in step 2 when we browsed to the 01 episode page.

Actual results:

Autoplay didn't get blocked --

https://i.gyazo.com/10f92c25ecbdd5febb1a531b73140080.png

Expected results:

Autoplay should have been blocked like this and play button appearing --

https://i.gyazo.com/0b8e94068c9fb9bfdab19fd2a04138db.png

when we browsed to the page.

By page here I meant the 01 episode page FYI

OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop

I'm not sure what the intended behaviour is in this case. I'll needinfo Alastor about this, but he's currently away.

Flags: needinfo?(alwu)

The intended behaviour is that Autoplay should be blocked even when address is changed without page load, thought this was obvious based on the title of the bug.

The setting value "Block Audio and Video" means that we would block both video and audio before the site is activated by user gesture, once the site has been activated, we would allow media to autoplay.

In your case, when you click any episode on the page, the clicking you have done acutally activates the site, which allows it to autoplay afterward.

This model is what we call user-gesture-activation autoplay model, which is used by Chrome as well. If you want to play video only when you click something, you can set the pref media.autoplay.enabled.user-gestures-needed to false, which would switch our autoplay policy to click-to-play model. However, this model is not compatible with some sites due to some technical issues from user interaction event flag handling.

Hope it can help you.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(alwu)
Resolution: --- → WONTFIX

If you want to play video only when you click something, you can set the pref media.autoplay.enabled.user-gestures-needed to false, which would switch our autoplay policy to click-to-play model.

Yes that's what I'm looking for. Didn't know that setting existed, thanks that works for the issue I have.

This model is what we call user-gesture-activation autoplay model, which is used by Chrome as well.

Chrome's block autoplay no longer works, no matter what I do the autoplay always happens there, they even removed the setting from chrome://flags.

On Youtube even though I have both of these settings set, autoplay bypasses when I'm playing one video and then I click on another video to play. Why is this happening ?

Flags: needinfo?(alwu)

Hi,

Do you mind to paste all your pref media.autoplay.* here? And describe reproducible steps in order to let me see if I can reproduce the issue as well?

Thank you.

Flags: needinfo?(alwu) → needinfo?(sscarl24)

media.autoplay.* prefs -- https://i.gyazo.com/d175a4c763a953a8266f008f56e1e46a.png

I'm on Nightly fyi.

STR --

Make sure to set those prefs in the aformentioned screenshot as I did before you try to reproduce.

Flags: needinfo?(sscarl24)
Flags: needinfo?(alwu)

What we actually check is whether the play invocation is called within user input callbacks. If site calls media.play() within an user input call back, eg. onclick(), then we would allow this invocation. So basically it's not specifically check the certain media element.

As it's possible to stop propagating click event in the DOM tree, it's meaningless to check whether the certain element is being clicked. For example, if site creates a transparent layer covered above the media element, when users think they are clicking the media element, but they actually click on the a transparent element. And site has a ability to stop propagating the click event to the media element.

In addition, according to the spec [1], user activation is going to be changed to being active within a certain timeframe, that means if you click somewhere (even if it's unrelated with the media interface) and then site can call media.play() successfully within a certain timeframe, even if it's not called from an user input callback.

Therefore, based on these background, I would still keep this bug as WONTFIX.

[1] https://html.spec.whatwg.org/#transient-activation

Flags: needinfo?(alwu)

So how do I deal with this autoplay bypass ? What are they doing to bypass autoplay check ?

OK, I can have a quick fix for this situation, but I would like to emphasize that the site can actually start any media inside the user input callback.

Assignee: nobody → alwu
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---

This patch is used to change the blessed state for media element under click-to-play blocking autoplay policy, which only allows play invocation called from user input handler, eg. onclick.

When media aborts current load, we should regard it as a new media. One example is on Youtube they always reuse same media element but replace its url for different video. Therefore, we should reset media's blessed state so that the media with new url can be blocked again.

Thank you very much, I understood what you were saying upto some extent but I rather have a fix for this in the browser instead of living on a workaround.

When media aborts current load, we should regard it as a new media. One example is on Youtube they always reuse same media element but replace its url for different video. Therefore, we should reset media's blessed state so that the media with new url can be blocked again.

That's becoming the norm for the sake of performance and I fear other video hosting sites will soon or may have already adopted this methodology for jumping to another video and faster playback without causing a new page load.

When will this patch land in Nightly ?

Now my patch is waiting for a review, once it passes review then I'll land it. I would probably say couples days depending on the review speed.

Priority: -- → P2
Pushed by alwu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e928d6001344 reset blessed state when media aborting current load. r=bryce

https://hg.mozilla.org/mozilla-central/rev/e928d6001344

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
status-firefox73: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla73

Is the Nightly build avilable available for me to test ?

Not sure when this change will be exactly included in the official Nightly, it usually takes a day or so. But if you build you own Nightly from the latest codebase, then you will see this change on it.

I updated to the latest Nightly and I can't reproduce autoplay bypass on Youtube anymore, so it's in it I believe so.

Hello! Reproduced the issue using Firefox 71.0a1 (20191011215012)on windows 10x64 and STR from comment 10.
The issue is verified fixed with Firefox 73.0b5 (20200115020958) on Windows 10x64, macOS 10.15 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
status-firefox73: fixed → verified
Flags: qe-verify+

Autoplay is getting bypassed again at -- http://www.animemobile.com/watch/zoids/episode-4

I'm on Nightly v74.

Set media.autoplay.default to 5; media.autoplay.enabled.user-gestures-needed to false respectively in about:config

STR --

Browse to http://www.animemobile.com/watch/zoids/episode-4
Click on the Close and Continue button under the ad-banner.
Observer that video player appear and video starts playing even though we haven't clicked on the play button.

Flags: needinfo?(alwu)

From the log, the website calls video.play() when you're clicking the "Close and Continue" button. So from this perpective, that button is equal to play button, so that is caused by website's bad design.

Flags: needinfo?(alwu)
Regressions: 1630220

Issue is back on youtube and autoplay is no longer being blocked since yesterday's Nightly. What changed ?

media.autoplay.enabled.user-gestures-needed is no longer present in about:config, removed ???

Flags: needinfo?(alwu)

It seems https://hg.mozilla.org/mozilla-central/rev/95805db3a142 broke the fix.

Setting media.autoplay.blocking_policy=2 [1] can fallback to the old policy, we're trying to see if the transient user gesture can replace our old policy.

[1] https://searchfox.org/mozilla-central/rev/3ce874dc2703831af3e5ef3a1d216ffd08057fa5/modules/libpref/init/StaticPrefList.yaml#6353-6360

Flags: needinfo?(alwu)

Thank you for reaching out to me so quickly, I made some comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1509933 (last two), please respond there and offer some clarification.

Seems Autoplay is not getting blocked while skimming through media on Twitter.

STR --

Video starts playing automatically.

Did something break with autoplay ?

Flags: needinfo?(alwu)

So the thing is that, the video was requested to play in the handler of click (when you click on the right arrow button) so it was allowed to start. So the blocking autoplay still works, but the design of website flow made that right arrow button as the play button for the next video.

Flags: needinfo?(alwu)

Sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1588138#c25, so sites can bypass autoplay like this, wow!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: