Closed
Bug 1464930
Opened 6 years ago
Closed 6 years ago
Move AutoplayPolicy Camera/Mic permission test to after gesturs-needed pref check
Categories
(Core :: Audio/Video: Playback, enhancement, P2)
Core
Audio/Video: Playback
Tracking
()
RESOLVED
FIXED
mozilla62
Tracking | Status | |
---|---|---|
firefox62 | --- | fixed |
People
(Reporter: cpearce, Assigned: cpearce)
References
Details
Attachments
(1 file)
In AutoplayPolicy::IsMediaElementAllowedToPlay() the provision for origins with camera/mic access to be able to autoplay should happen after the check of pref "media.autoplay.enabled.user-gestures-needed", as the provision should only apply to the new block autoplay mode, not the old mode.
Comment hidden (mozreview-request) |
Could you please expand on the case this is covering, and the new and old modes mentioned above?
Do I understand correctly that this makes the policy slightly more restrictive? Prior to the change all capture pages were allowed to play, now the if `media.autoplay.enabled.user-gestures-needed` is false, then an unblessed element may be denied the ability to play?
Flags: needinfo?(cpearce)
Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Bryce Van Dyk (:bryce) from comment #2)
> Could you please expand on the case this is covering, and the new and old
> modes mentioned above?
The old mode is media.autoplay.enabled true or false. On desktop this is unsupported. On mobile we do support this mode. This mode controls the "bless" behaviour, where if a media element has load() or play() called in a user generated event handler, we bless it and allow it to autoplay.
The new mode is being developed behind the media.autoplay.enabled.user-gestures-needed pref. This is the block autoplay mode we intend to ship and support on desktop and mobile.
This clause to allow pages with capture permission should really only be included in the new mode, and it was a mistake to make this change to the legacy block-autoplay behaviour, instead of only including it in the new block-autoplay behaviour.
> Do I understand correctly that this makes the policy slightly more
> restrictive?
Yes. I made this change in February in bug 1182329, intending it to be part of the broader block autoplay rework, but if it's not behind the media.autoplay.enabled.user-gestures-needed pref, then it's changing the old behaviour, and not the new behaviour.
> Prior to the change all capture pages were allowed to play, now
> the if `media.autoplay.enabled.user-gestures-needed` is false, then an
> unblessed element may be denied the ability to play?
My patch here moves our suppored behaviour back to the behaviour we had prior to February; pages which want to autoplay when media.autoplay.enabled=false will need a blessed element. Once we're ready to pref on the "gestures-needed" approach, this provision for capture/webrtc pages will take affect.
Flags: needinfo?(cpearce)
Appreciate the explanation. Thank you.
Comment 5•6 years ago
|
||
mozreview-review |
Comment on attachment 8981275 [details]
Bug 1464930 - Move AutoplayPolicy Camera/Mic permission test to after gestures-needed pref check.
https://reviewboard.mozilla.org/r/247374/#review253742
::: commit-message-94b7d:1
(Diff revision 1)
> +Bug 1464930 - Move AutoplayPolicy Camera/Mic permission test to after gesturs-needed pref check. r?bryce
'gesturs-needed' typo.
Attachment #8981275 -
Flags: review?(bvandyk) → review+
Comment hidden (mozreview-request) |
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1ffb42b4beac
Move AutoplayPolicy Camera/Mic permission test to after gestures-needed pref check. r=bryce
Comment 8•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox62:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in
before you can comment on or make changes to this bug.
Description
•