Closed Bug 1277813 Opened 8 years ago Closed 8 years ago

When media.autoplay.enabled is set to FALSE, some embedded youtube videos won't play even if clicked.

Categories

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

46 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
platform-rel --- ?
firefox50 --- fixed

People

(Reporter: the_adb, Assigned: cpearce)

References

Details

(Whiteboard: [platform-rel-Youtube])

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

1. Set media.autoplay.enabled to false
2. Click to play an embedded youtube video on Facebook
3. Video does not play but shows "If video playabck doesn't begin shortly restart your  


Actual results:

If the time bar is clicked on the youtube video again at position after 0:01, the video  starts playing. 


Expected results:

Embedded videos should start playing when play button is clicked by the user, even if media.autoplay.enabled is set to FALSE.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
New firefox update 47.0, the same issue. No fix.
platform-rel: --- → ?
Whiteboard: [platform-rel-Youtube]
Perhaps you don't want to use media.autoplay.enabled=false on desktop.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> Perhaps you don't want to use media.autoplay.enabled=false on desktop.

This makes no sense. Sorry. Why wouldn't one want to use a very sensible feature on desktop? And how does it make sense to allow any website play whatever **** they think you want to see or hear without user confirmation? No matter what device you're using browser on.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> Perhaps you don't want to use media.autoplay.enabled=false on desktop.

Why wouldn't I want this on desktop ? I occasionally need to access websites that aggresively autoplay things. I think the idea behind the function is very good. Problem is I can't use it! because it's buggy.

(Sorry if I misspelled words. I am not from an english speaking country and I don't have auto-correct)
(In reply to the_adb from comment #4)
> (Sorry if I misspelled words. I am not from an english speaking country and
> I don't have auto-correct)
Do you speak Chinese? If yes, you can explain it in Chinese. Some of us can read Chinese. :-)

Farmer, 
Could you help have a look?
Flags: needinfo?(fatseng)
Many videos on vimeo can't start playing for me on FF46 on linux. On youtube I click a few times on the play buttin and they play. But on vimeo I'm more often than not unable to play no matter what I do. Once the setting is disabled, they start playing.

IMO it should be handled like plug-ins. One need to be able to see a list of media on page and allow it. Or white list a page to allow auto-play.
I will check embedded youtube video on Facebook.
Flags: needinfo?(fatseng)
On mobile Chrome and Safari, where videos are click-to-play, YouTube are calling HTMLMediaElement.load() whenever the user interacts with the site to cause the video to be authorized to play.

We could also consider a load() called in a user generated event handler as user intent to play. That may fix the YouTube case at least.
On youtube:
If you click video content to start playing, it doesn't work.(abnormal case)
If you click play button on control bar, it works.(normal case)

While playing video, the code use "sUserInputEventDepth" variable to determine if it is handling user input.
In abnormal case, while HTMLMediaElement::PlayInternal() was called, the sUserInputEventDepth is zero.
Here is log of abnormal case.

HandleEventInternal++
sUserInputEventDepth++
timeout:1000000000, TimeDuration:0, now-start:14379851
timeout:1000000000, TimeDuration:0, now-start:14400053
timeout:1000000000, TimeDuration:0, now-start:14404355
DispatchEventToDOM
sUserInputEventDepth--
HandleEventInternal--

HandleEventInternal++
sUserInputEventDepth++
DispatchEventToDOM
HandleEventInternal++
timeout:1000000000, TimeDuration:0, now-start:21197190
timeout:1000000000, TimeDuration:0, now-start:21220152
timeout:1000000000, TimeDuration:0, now-start:21223094
timeout:1000000000, TimeDuration:0, now-start:21226528
timeout:1000000000, TimeDuration:0, now-start:21230318
timeout:1000000000, TimeDuration:0, now-start:21233118
timeout:1000000000, TimeDuration:0, now-start:21236556
timeout:1000000000, TimeDuration:0, now-start:21240958
timeout:1000000000, TimeDuration:0, now-start:21468172
timeout:1000000000, TimeDuration:0, now-start:21479374
timeout:1000000000, TimeDuration:0, now-start:22009211
timeout:1000000000, TimeDuration:0, now-start:22023480
timeout:1000000000, TimeDuration:0, now-start:22027831
timeout:1000000000, TimeDuration:0, now-start:22032891
timeout:1000000000, TimeDuration:0, now-start:22037453
timeout:1000000000, TimeDuration:0, now-start:22041685
timeout:1000000000, TimeDuration:0, now-start:22046410
timeout:1000000000, TimeDuration:0, now-start:22050914
timeout:1000000000, TimeDuration:0, now-start:24035681
timeout:1000000000, TimeDuration:0, now-start:24053529
timeout:1000000000, TimeDuration:0, now-start:26345096
timeout:1000000000, TimeDuration:0, now-start:31965946
timeout:1000000000, TimeDuration:0, now-start:31986274
timeout:1000000000, TimeDuration:0, now-start:31989314
timeout:1000000000, TimeDuration:0, now-start:31995078
DispatchEventToDOM
HandleEventInternal--
sUserInputEventDepth--
HandleEventInternal--

HandleEventInternal++
DispatchEventToDOM
HandleEventInternal--

HandleEventInternal++
HandleEventInternal--

HandleEventInternal++
DispatchEventToDOM
HandleEventInternal--

HTMLMediaElement::Play
userInteraction:FALSE, autoplay:FALSE, UserInput:FALSE, IsChrome:FALSE ======= 
Don't Allow To Play ===
HTMLMediaElement::Play
userInteraction:FALSE, autoplay:FALSE, UserInput:FALSE, IsChrome:FALSE =======
Don't Allow To Play ===

In normal case (click play button on control bar), while HTMLMediaElement::PlayInternal() was called, the sUserInputEventDepth is NOT zero.
Here is log of normal case.

HandleEventInternal++
HandleEventInternal--


HandleEventInternal++
sUserInputEventDepth++
DispatchEventToDOM
sUserInputEventDepth--
HandleEventInternal--


HandleEventInternal++
sUserInputEventDepth++
DispatchEventToDOM
HandleEventInternal++
HTMLMediaElement::Play
timeout:1000000000, TimeDuration:0, now-start:25868885
userInteraction:FALSE, autoplay:FALSE, UserInput:TRUE, IsChrome:FALSE =======
timeout:1000000000, TimeDuration:0, now-start:25875701
Allow To Play === 
DispatchEventToDOM
HandleEventInternal--
aIsHandlingNativeEvent
sUserInputEventDepth--
HandleEventInternal--
Assignee: nobody → cpearce
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to Chris Pearce (:cpearce) from comment #10)
> Created attachment 8770366 [details] [diff] [review]
> Consider HTMLMediaElement.load() in user generated event handler to allow
> autoplay
> 
> MozReview-Commit-ID: KzjNcn3s6od

This doesn't quite fix YouTube. If you load YouTube.com, and click on a video to play, the load() calls are not done in a user generated event handler. So we're still not able to play automatically. I'd have thought clicking on the link to open a video would have also started a load() in the click handler, but it does not appear to.
Assignee: cpearce → nobody
Status: ASSIGNED → NEW
See Also: → 659285
I found this code history, bug 659285.
(In reply to Chris Pearce (:cpearce) from comment #11)
> (In reply to Chris Pearce (:cpearce) from comment #10)
> > Created attachment 8770366 [details] [diff] [review]
> > Consider HTMLMediaElement.load() in user generated event handler to allow
> > autoplay
> > 
> > MozReview-Commit-ID: KzjNcn3s6od
> 
> This doesn't quite fix YouTube. If you load YouTube.com, and click on a
> video to play, the load() calls are not done in a user generated event
> handler. So we're still not able to play automatically. I'd have thought
> clicking on the link to open a video would have also started a load() in the
> click handler, but it does not appear to.

Yes, in youtube, the load() is called after a user generated event handler.
in https://vimeo.com/, the Play() is also called after a user generated event handler, even though you click play from control bar.
I have asked YouTube if they can move their load() call to the click handler, to capture user intent to play on a video element. We should try to get the above patch landed, so that YouTube at least can work in this case.
This is so that if media autoplay is disabled, a site can capture user intent
to play in their click handlers by calling load() on an empty video element to
"bless" the video element with the ability to play later when the video has
loaded.

Large video sites typically have a catalog view of videos to chose from on
their main page, and when the user clicks on one, with this patch, the site can
bless a video element so that it will play by beginning the load of that video
in the click handler. Often these sites do a bunch of asynchronous things
before they actually get around to playing the video, they don't call play in
the click handler, so we need another way to bless the videos so they can play.

We allow seeks in a click handler to capture user intent to play, so I don't
see why we should not also allow a load() to capture user intent.

Review commit: https://reviewboard.mozilla.org/r/64096/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/64096/
Attachment #8770717 - Flags: review?(kinetik)
Attachment #8770366 - Attachment is obsolete: true
Assignee: nobody → cpearce
Attachment #8770717 - Flags: review?(kinetik) → review+
Comment on attachment 8770717 [details]
Bug 1277813 - Consider HTMLMediaElement.load() in user generated event handler to allow autoplay.

https://reviewboard.mozilla.org/r/64096/#review61114
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3f2f938f67a9
Consider HTMLMediaElement.load() in user generated event handler to allow autoplay. r=kinetik
https://hg.mozilla.org/mozilla-central/rev/3f2f938f67a9
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Ok. So I understand the problem I have highlighted when I posted this has been fixed? I have no programming knowledge, so I just want to thank everybody that was involved in the procces and ask what action must I take ? Is there a patch or this will come as an update in the next version of firefox ?
(In reply to the_adb from comment #19)
> Ok. So I understand the problem I have highlighted when I posted this has
> been fixed? I have no programming knowledge, so I just want to thank
> everybody that was involved in the procces and ask what action must I take ?
> Is there a patch or this will come as an update in the next version of
> firefox ?

This is now fixed on what will become Firefox 50. If this hits lots of people and don't have the risk of causing other bugs, they will fix Firefox 49 and maybe 48 as well.
(In reply to Guilherme Lima from comment #20)
> (In reply to the_adb from comment #19)
> > Ok. So I understand the problem I have highlighted when I posted this has
> > been fixed? I have no programming knowledge, so I just want to thank
> > everybody that was involved in the procces and ask what action must I take ?
> > Is there a patch or this will come as an update in the next version of
> > firefox ?
> 
> This is now fixed on what will become Firefox 50. If this hits lots of
> people and don't have the risk of causing other bugs, they will fix Firefox
> 49 and maybe 48 as well.

Oh...ok. Thank you for the clarification.
(In reply to the_adb from comment #19)
> Ok. So I understand the problem I have highlighted when I posted this has
> been fixed?

Almost. I've landed a change in the upcoming Firefox 50 that will make it possible for YouTube to fix this. And YouTube have told me they'll make a change to take advantage of the fix and make it work soon. So hopefully, we'll see this resolved by the time Firefox 50 hits release.
The new LegacyIsCallerOrNativeCode callsites weren't reviewed by either me or bholley (or any DOM peer, in fact, but the comments on that method explicitly say to get review from me or bholley)...
Up until Bug 1072150 those used to be IsCallerChrome(), and were there to ensure the video controls were able to start playback. The video controls now don't have chrome privileges, so we can probably just remove all of them from HTMLMediaElement.cpp.
I've filed Bug 1316758 to remove the IsCallerChrome*() calls from HTMLMediaElement.
(In reply to Chris Pearce (:cpearce) from comment #15)
> Large video sites typically have a catalog view of videos to chose from on
> their main page, and when the user clicks on one, with this patch, the site
> can
> bless a video element so that it will play by beginning the load of that
> video in the click handler.

When I click on a link on the main page of youtube, I do not express the intent of watching the video; I express the intent of viewing the web page that contains that video, for example to read its description. I feel that having the video start automatically when media.autoplay.enabled is set to false defeats the purpose of that option.

This is not a theoretical view as I do not ever want the youtube player to start playing; I use an addon (watch with mpv) to play the videos in a better player.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: