Autoplay blocking consistently fails on yahoo.com
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox87 | --- | affected |
People
(Reporter: starbrite_poggio, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
Go to yahoo.com and click on links with videos. A subdomain like news.yahoo.com tends to have lots of videos in their articles
Actual results:
The block autoplay feature consistently fails to work.
Expected results:
The videos should always be blocked from autoplaying. However on yahoo there is a high chance that it will fail.
|
||
Comment 1•6 years ago
|
||
Do the videos in question play without sound? If so, enter about:config into the address bar and set the media.autoplay.allow-muted preference to false.
|
||
Comment 2•6 years ago
|
||
According to the description in comment0, clicking the link activates the document which would allow a site to autoplay. We only block autoplay before user gesture activates the docuement.
If you would like to disable user-gesture model, try to set the pref media.autoplay.enabled.user-gestures-needed=false, which would use click-to-play to block autoplay, but it won't work for all websites.
(In reply to Gingerbread Man from comment #1)
Do the videos in question play without sound? If so, enter
about:configinto the address bar and set the media.autoplay.allow-muted preference to false.
They play with sound. (I'm aware the new autoplay blocking doesn't work on muted videos). I already had media.autoplay.allow-muted preference set to false and media.autoplay.default set to 1.
(In reply to Alastor Wu [:alwu] from comment #2)
According to the description in comment0, clicking the link activates the document which would allow a site to autoplay. We only block autoplay before user gesture activates the docuement.
If you would like to disable
user-gesturemodel, try to set the prefmedia.autoplay.enabled.user-gestures-needed=false, which would useclick-to-playto block autoplay, but it won't work for all websites.
This seems to work. I haven't gotten an autoplaying video on yahoo so far. However I think the pref media.autoplay.enabled.user-gestures-needed should be set to false by default because the average user who wants to block autoplay will expect the settings in Options > Privacy & Security > "Block websites from automatically playing sound"(i.e. media.autoplay.default=1) to simply block the autoplay. It looks like yahoo has a found a way around this setting by making their videos activate through user gestures, e.g. mouse scrolling.
sry didn't mean mouse scrolling activated the videos. I thought it did at first. Simply clicking the link and not moving my mouse the video would still autoplay.
|
|
||
Comment 5•6 years ago
|
||
(In reply to Alastor Wu [:alwu] from comment #2)
According to the description in comment0, clicking the link activates the document which would allow a site to autoplay. We only block autoplay before user gesture activates the docuement.
It's my expectation that autoplay is allowed if the page received a click. It doesn't make sense to allow autoplay on one page because the previous page was clicked.
|
|
||
Comment 6•6 years ago
|
||
(In reply to Gingerbread Man from comment #5)
It's my expectation that autoplay is allowed if the page received a click. It doesn't make sense to allow autoplay on one page because the previous page was clicked.
The url changed doesn't matter, because what we activate is the document, which could be the same one even a site are navigating to different page.
|
||
Comment 7•6 years ago
|
||
Reported the same in 1536686 - I think it is still not an expected behavior that just because the site loads a new page in the same document that that subsequent gestures acts as if it is the same page.
While this may be technically correct, it still doesn't reflect what I expect the behavior to be, so it would be nice if Mozilla would take a closer look at pages like these, because it feels like the site here are "cheating" the browser here and subverting user intent.
If users like this behavior, they can easily whitelist the site, but aside from flags in about:config, there is no built in way in Firefox to do the expected thing as advertised in blog posts and product release pages.
This can't possibly be working as designed
- The urlbar still shows the play-blocked icon
- The argument about document activation is a legalistic loophole that completely violates the spirit of this feature
- this click is effectively a navigation to a new page with a new url
- the fact that it does so in-place is an implementation detail the user should not be expected to know or understand
- from the user perspective this is a loading of a new page, the urlbar shows playback is blocked, the user expects playback to be blocked
- but it's not
- so a clear bug
Same goes for clicking on the fullscreen icon. This causes videos to strobe for a few seconds, which is a hazard, and then autoplay.
media.autoplay.enabled.user-gestures-needed = false
Seems to prevent this, but it isn't intuitive.
example of a affected video:
|
||
Comment 10•4 years ago
|
||
Why has this issue been marked as resolved? Nothing has been resolved. No auto play is being blocked. It is only blocked if you directly open an URL from external source, by typing one in the address bar, or by selecting bookmark. Whenever you open a website through a link, the 99.99% case for most users, this feature does block exactly nothing. This feature is among the most useless features ever. I expect that an autoplay block features blocks every video from autoplay unless I tell it otherwise. Compare that to the pop-up blocking features. It blocks all pop-ups, doesn't it? It blocks them even when I click on a link and a new sub page loads, right? Of course it does, as it would be completely useless if it wouldn't work that way. It is absolutely reasonable to expect a autoplay blocker to work exactly like the pop-up blocker does and that this is possible is proven by addons which are able to block any autoplay. If you cannot fix it, please remove it but don't pretend that Firefox can block autoplay as currently it simply cannot and then at least people will know that they require to install an add-on if they desire this feature.
|
|
||
Comment 11•4 years ago
|
||
Proof of concept:
https://addons.mozilla.org/en-US/firefox/addon/disableautoplay
|
|
||
Comment 12•4 years ago
•
|
||
Sorry, I still need to close this bug. If you really need to click-to-play mode then you can change your setting to do that, see details here.
So for autoplay, I agree that the ideal situation should be click-to-play that only plays the media when users do action on it (eg. click). However, that requires to propagate a flag to the element in order to know if the play invocation is really triggered by users. However, the spec of that flag propagation has some long existing defects and finally all vendors agreed to abandon that and used a new spec instead, which is sticky/transient user activation.
Currently Firefox uses sticky as the default policy for blocking autoplay, and also provides the option of switching to transient activation and the oldest implementation (click-to-play). The reason we don't use click-to-play as a default option is because it exists some spec issue, and won't work for every sites. (Some sites would be never allowed to start playing because the flag propagation failed) And transient activation also didn't work for every sites, because each website has different response time to play media.
Anyway, you can change your blocking autoplay to different policy by modifying the pref. And the click-to-play is the one you're looking for, which is also the oldest blocking autoplay implementation on Firefox, but we don't guarantee that that policy works for every site.
|
||
Comment 13•4 years ago
|
||
Migraine warning for the Google Docs link. See bug 1676532.
There need to be safe, accessible ways to find out how to configure Firefox for safety and accessibility. When users are sensitive to flashing and animation, we need to be able to block autoplay without going through instructions which fire more animation.
|
|
||
Comment 14•4 years ago
|
||
Created a wikipage for that.
|
|
||
Comment 15•4 years ago
|
||
(In reply to Alastor Wu [:alwu] from comment #14)
Created a wikipage for that.
What is the definition of "page'? For me, a web page is the result of a HTTP GET request. So when I click a link on a page and that causes the browser to load a new main document with another HTTP GET request, that would be a new page. Yet according to behavior, you seem to talk about site, as that sticky flag seems to apply to everything loaded from the same domain and I think that is what most people bugs here. The click on a link, a new page loads, the URL in the address bar changes and autoplay is not blocked anymore. If it really was about "pages", nobody would have probably complained... well, except those who don't allow persistent cookies and activate the page every time by clicking on a cookie banner and here even policy 1 will hardly help as even when set to 100 ms autoplay will start.
Description
•