Closed Bug 1497582 Opened 6 years ago Closed 6 years ago

Video auto-plays when autoplay is disabled

Categories

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

63 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: lists, Unassigned, NeedInfo)

References

Details

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

Steps to reproduce:

https://www.bloomberg.com/news/articles/2018-10-09/new-evidence-of-hacked-supermicro-hardware-found-in-u-s-telecom
Video is not muted either.  Autoplay disabled should not allow any videos to play 


Actual results:

Video in page played.


Expected results:

Video in page should NOT have played
The developers are currently working on the autoplay block feature, see bug 1376321
The new block works in Firefox64 nightly but it could be disabled in Firefox63.

moving to Audio/video:playback because i'm unsure about the current state of the autoblock feature.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Autoplay is blocked on the linked page for me testing with nightly (Firefox 64). As noted in comment #1, this is something we're actively working on, so we can expect a lot of changes between releases.

lists, which settings are you using to enable block autoplay? While I'd expect the feature to work best in nigthly, it is also the case that we've changed some of the prefs involved over time.
Flags: needinfo?(lists)
Lists: I just tested it again. When I open the page after a few seconds I get the door hanger drop down. If I then select "don't allow" the video at the top of the page does not start to play. If I then revisit the page again Firefox remembers by default that I don't want bloomberg.com to play audible videos. And again the video doesn't start to play.

Now one scenario where the video starts to play is: if I visit the page and Firefox (with no previous block auto play decision remembered) and then I click on one of the links on the page, for example the subscription or login button at the bottom, before the video starts playing then the video will start to play with audio. The reason is that you have interacted with the page before play() got called on the video. This works as designed.

I'm going to close this as it appears to work as designed. Feel free to re-open if you have new information or if I haven't the scenario which you think isn't working as it should.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
(In reply to Nils Ohlmeier [:drno] from comment #3)
> I'm going to close this as it appears to work as designed. Feel free to
> re-open if you have new information or if I haven't the scenario which you
> think isn't working as it should.

In that case, I'll ask again. Should I open a separate bug over the issue of YouTube starting playing immediately on the tab receiving first focus with media.autoplay.enabled=false when it used to force a "user must interact with the player widget" requirement?

Steps to Reproduce:
1. Set media.autoplay.enabled=false (then restart Firefox if you think that's necessary. I tried it to no effect.)
2. Formulate a YouTube search like "where the hell is matt" and middle-click a bunch of videos
3. Switch to one of the tabs

Observed misbehaviour:
Tabs are blocked from autoplaying until they receive focus (indicating that YouTube hasn't managed to completely circumvent Firefox's autoplay suppression) but start autoplaying as soon as they receive focus (indicating that Firefox isn't properly applying media.autoplay.enabled=false)

This causes a cacaphony when I use Ctrl+Tab/Ctrl+Shift+Tab to cycle past some YouTube tabs that were opened via middle-click or move a bunch of YouTube e-mails from Thunderbird into my "Videos to Watch" bookmarks folder because externally opened tabs start in a "focused at least once" state.

(Fundamentally, I see this conflation of "change view" and "interact with displayed content" as similar to badly-designed GTK+ applications which treat "Which tab is active?" as if it were a radio button input or web interfaces which assign significance to which pane of an accordion widget was expanded when the user clicked Submit... and, yes, I've encountered both of those.)
You need to log in before you can comment on or make changes to this bug.