Open Bug 1647779 Opened 4 years ago Updated 2 years ago

Even After Granting Autoplay Permissions Videos Don't Always Autoplay

Categories

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

79 Branch
Unspecified
All
defect

Tracking

()

People

(Reporter: ekager, Unassigned)

References

Details

STR:

  1. Set Fenix setting to "block audio and video on cellular data only"
  2. Have wifi on
  3. Go to https://bmw.com/en/innovation/the-development-of-self-driving-cars.html
  4. Videos on top of page won't autoplay

I put logs in AC and can see we are granting the content permission request for PERMISSION_AUTOPLAY_AUDIBLE and PERMISSION_AUTOPLAY_INAUDIBLE so I'm assuming this bug should be filed here, but correct me if I'm missing something!

I can also repro on https://www.nytimes.com/interactive/2018/11/27/style/what-is-inside-this-internet-rabbit-hole.html

Fenix issues:
https://github.com/mozilla-mobile/fenix/issues/4002
https://github.com/mozilla-mobile/fenix/issues/8678

Sent link to Gecko AutoPlay doc to kbrosnan.
We figure that it's worth testing this in GVE as well.

Flags: needinfo?(kbrosnan)

So testing a few other pages with simple autoplay examples this works. Ex the autoplay examples in https://videojs.github.io/autoplay-tests/ there is a more subtle bug here.

Flags: needinfo?(kbrosnan)
Component: General → Audio/Video: Playback
Product: GeckoView → Core

This is because at the time media is requesting play, we haven't got the response from GeckoView about if we can allow inaudible media, so we reject that play.

I don't have a good way to fix that because everytime play request happens we have to response it immediately, the only way to fix it is that embedded application should save its permission into Gecko to allow us to know the result beforehand, which was discussed before but didn't fit the GV team's request.

Severity: -- → S3
Flags: needinfo?(snorp)

(In reply to Alastor Wu [:alwu] from comment #3)

This is because at the time media is requesting play, we haven't got the response from GeckoView about if we can allow inaudible media, so we reject that play.

I don't have a good way to fix that because everytime play request happens we have to response it immediately, the only way to fix it is that embedded application should save its permission into Gecko to allow us to know the result beforehand, which was discussed before but didn't fit the GV team's request.

I thought we had discussed playing the video if an autoplay had been attempted when the permission response was received?

We're changing the permission system to be more like what Gecko expects, so I guess this will improve at that point if we can't figure something out short-term.

Flags: needinfo?(snorp)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #4)

I thought we had discussed playing the video if an autoplay had been attempted when the permission response was received?

Yes, but this case is that, media requested play before Gecko receives response from GV, so it got blocked. And it didn't request play again since then.

We're changing the permission system to be more like what Gecko expects, so I guess this will improve at that point if we can't figure something out short-term.

OK, so let's wait those change to see if they can help.

Is there any update on the bug? I'm able to simulate the same issue with both pages on GeckoView example app.

Per comment3, this issue was caused by "website requests autoplay before Gecko receive the response from GeckoView". Current design is that, Gecko would ask GeckoView (asynchrously) if the autoplay is allowed, then Gecko would use GeckoView's response to deal with any new coming requests. If it's allowed, then all future requests would be resolved. If it's not, then we will check the blocking policy (click-to-play/user activation) to determine if we should resolve or block the requests.

The issue happened BEFORE Gecko receives the response from GeckoView. Every autoplay request which happens before that would be blocked. So the problem is not "website can't play after granting autoplay permission", if the website requests play again later after Gecko receives the response from GeckoView, then the website will be able to start media.

when you said "simulate the same issue", did you try to request play again later? because the response from GeckoView to Gecko is async, you probably requested to play too early.

Flags: needinfo?(amejiamarmol)

We don't control when permissions are requested by websites, is there any way to re request the permission via js?
I know there are some efforts going on trying to unify GeckoView and Gecko permission https://bugzilla.mozilla.org/show_bug.cgi?id=1654832 not sure if that will help.

Flags: needinfo?(amejiamarmol)

Sorry I missed the bug mail, so I forgot to reply on this. Yes, I think bug 1654832 would definitely help on this situation, because once Gecko needs to wait for the response from the GeckoView, then this issue would keep existing. Only when Gecko can fully control the permission without asking GeckoView, then we can solve this issue gracefullly.

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