Adrian Reporter
	Description • 6 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180326132207

Steps to reproduce:

1. Use Firefox Nightly 61.0a1 (2018-03-26) (64-Bit)
2. Open a YouTube video
3. Pin the tab
4. Enable session restore on startup (not sure if required, it's a pinned tab)
5. Open some other tabs
6. Close the browser
7. Open the browser


Actual results:

The YouTube video in the pinned tab starts playing as soon as the page in the background loads.


Expected results:

The video should only start once you click on the tab.

This has happened in all Nightly builds since a week or so.

	Daniel_A[:daschilean] [Please contact - liviu.seplecan@softvision.ro]
	Comment 1 • 6 years ago

Hi Adrian.Tiefenbrunner, 

I reproduced this issue on Windows 10 64bit with FF 61.0a1 (2018-03-29) (64-bit) using the latest build.

	Paul Adenot (:padenot)
	Comment 2 • 6 years ago

Jean-Yves, have we changed anything recently that could have caused this?

	Jean-Yves Avenard [:jya]
	Comment 3 • 6 years ago

(In reply to Paul Adenot (:padenot) from comment #2)
> Jean-Yves, have we changed anything recently that could have caused this?

not that I'm aware of...

	Pascal Chevrel:pascalc (PTO until August 21)
	Comment 4 • 6 years ago

I tried to reproduce this bug as it annoys me as well, every restart of Firefox Nightly after an update starts my youtube pinned tab even though it wasn't playing before the restart. I've had this behaviour for a long time.

Last good revision: 5aa966279356795a7917e0563a7ec342b48f4c69
First bad revision: 36fbfac0ea9698ee8e6974a296e9903da318fa97
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5aa966279356795a7917e0563a7ec342b48f4c69&tochange=36fbfac0ea9698ee8e6974a296e9903da318fa97

Bug 1347791 caused the behaviour change for me (I did the mozregression process twice with a persistent test profile to be sure).

	Mike Taylor [:miketaylr]
	Comment 5 • 6 years ago

Nils, can you find an owner for this regression and prioritize? Thanks.

	Nils Ohlmeier [:drno]
	Comment 6 • 6 years ago

Adrian: what are the values for these user prefs (on about:config) for you:
- media.autoplay.enabled
- media.autoplay.enabled.user-gestures-needed
- media.block-autoplay-until-in-foreground

Chris: did anything new regarding autoplay landed recently which would explain this change?

	Adrian Reporter
	Comment 7 • 6 years ago

I just tried to reproduce the issue again as I haven't had pinned YouTube videos in my session since, but it doesn't happen anymore in the latest Nightly [61.0a1 (2018-04-29) (64-Bit)] on my machine.

The current values are:
- media.autoplay.enabled: true (default)
- media.autoplay.enabled.user-gestures-needed: false (default)
- media.block-autoplay-until-in-foreground: true (default)

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 8 • 6 years ago

(In reply to Pascal Chevrel:pascalc from comment #4)
> I tried to reproduce this bug as it annoys me as well, every restart of
> Firefox Nightly after an update starts my youtube pinned tab even though it
> wasn't playing before the restart. I've had this behaviour for a long time.
> 
> Last good revision: 5aa966279356795a7917e0563a7ec342b48f4c69
> First bad revision: 36fbfac0ea9698ee8e6974a296e9903da318fa97
> Pushlog:
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=5aa966279356795a7917e0563a7ec342b48f4c69&tochange=36fb
> fac0ea9698ee8e6974a296e9903da318fa97
> 
> Bug 1347791 caused the behaviour change for me (I did the mozregression
> process twice with a persistent test profile to be sure).

Bug 1347791 changed our behaviour so that we don't play until tabs have been in the foreground. So it sounds like we're getting the behaviour as designed; tabs loaded in the background won't play sound until they've received some attention from the user.

	Pascal Chevrel:pascalc (PTO until August 21)
	Comment 9 • 6 years ago

(In reply to Chris Pearce (:cpearce) from comment #8)
> (In reply to Pascal Chevrel:pascalc from comment #4)
> > I tried to reproduce this bug as it annoys me as well, every restart of
> > Firefox Nightly after an update starts my youtube pinned tab even though it
> > wasn't playing before the restart. I've had this behaviour for a long time.
> > 
> > Last good revision: 5aa966279356795a7917e0563a7ec342b48f4c69
> > First bad revision: 36fbfac0ea9698ee8e6974a296e9903da318fa97
> > Pushlog:
> > https://hg.mozilla.org/integration/autoland/
> > pushloghtml?fromchange=5aa966279356795a7917e0563a7ec342b48f4c69&tochange=36fb
> > fac0ea9698ee8e6974a296e9903da318fa97
> > 
> > Bug 1347791 caused the behaviour change for me (I did the mozregression
> > process twice with a persistent test profile to be sure).
> 
> Bug 1347791 changed our behaviour so that we don't play until tabs have been
> in the foreground. So it sounds like we're getting the behaviour as
> designed; tabs loaded in the background won't play sound until they've
> received some attention from the user.

The pinned tab is in the background since the focus is on a regulat tab. It plays sound when I restart Firefox after an update while the video was not playing before the restart. If I had 10 pinned tabs each one with a youtube video in it, does it mean that we want all of them to start playing every time the browser is restarted? Because this is the current behaviour.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 10 • 6 years ago

(In reply to Pascal Chevrel:pascalc from comment #9)
> > > Bug 1347791 caused the behaviour change for me (I did the mozregression
> > > process twice with a persistent test profile to be sure).

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1347791#c25 and https://bugzilla.mozilla.org/show_bug.cgi?id=1347791#c26 our intended behaviour upon pinning a tab is to remember whether that tab was ever foregrounded, and if it was, allow that tab to play without being foregrounded again upon session restore. Our behaviour for unpinned tabs when HTMLMediaElement.play() is called before the tab has been foregrounded is to delay making the play actually play (produce sound, advance currentTime etc) until the tab has been foregrounded.

So yes, you're seeing the behaviour as the developers intended.

This feature was designed for the case of gmail/slack/irccloud/etc notifications. Upon restart, we reload pinned tabs, and it is desirable for those tabs to be able to play a sound when they want to send notifications about new messages etc. Unfortunately, that conflicts with other uses of pinning like what you're doing with YouTube tabs.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 11 • 6 years ago

As part of the work to ship a supported block autoplay on desktop, we decided to revert the behaviour of pinned tabs remembering whether they'd been "unblocked" in session restore. This work is being done in bug 1458383. I'm going to land it in 62, rather than making this behaviour change gated on us enabling our officially supported block autoplay implementation, which hopefully will ship in 62 as well, but we'll see...

So you should see pinned tabs not starting autoplaying when coming out of session restore in Nightly in the next few days.

Thanks for reporting this bug and your patience while we worked through it.