This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
This will mean that in places like the tight loop in GetTypeIndex()
we would no longer require calling strlen() on the input type argument
once per loop iteration.
Depends on D20236
Differential Revision: https://phabricator.services.mozilla.com/D20237
--HG--
extra : moz-landing-system : lando
From the following table, we can know the feature policy have no any effect for the autoplay result.
That is, if the document has been gesture activated, we want to playback, regardless of the status of the feature policy.
If the site has denied autoplay permission via feature policy, if the user gesture activates (clicks play) we still want to be able to play.
Therefore, we can remove `feature-policy` checking.
| gesture activated | autoplay feature policy status | allowed to play |
|-------------------|--------------------------------|-----------------|
| activated | allowed | true |
| not activated | not allowed | false |
| activated | not allowed | true |
| not activated | allowed | false |
Differential Revision: https://phabricator.services.mozilla.com/D18098
--HG--
extra : moz-landing-system : lando
The autoplay checking for media element has 4 different phases,
1. check whether media element itself meets the autoplay condition
2. check whethr the site is in the autoplay whitelist
3. check global autoplay setting and check wether the site is in the autoplay blacklist.
4. check whether media is allowed under current blocking model (click-to-play or user-gesture-activation)
Differential Revision: https://phabricator.services.mozilla.com/D16525
--HG--
extra : moz-landing-system : lando
We would like to have different phases checking for autoplay, the first phase is to check media element itself, so we need to move other non-related checkings out from 'IsMediaElementAllowedToPlay()'.
Differential Revision: https://phabricator.services.mozilla.com/D16523
--HG--
extra : moz-landing-system : lando
`document.autoplayPolicy` returns a enum string that can change overtime based on user session activity:
- “allowed” if autoplay is currently allowed.
- “allowed-muted” if muted video autoplay is currently allowed.
- “disallowed” is autoplay is not current allowed.
Differential Revision: https://phabricator.services.mozilla.com/D11543
--HG--
extra : moz-landing-system : lando
We're going to remove all autoplay temporary permission related codes, so we don't need to cache it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D14325
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
When talking about autoplay, video without audio track should also be controlled by the pref "media.autoplay.allow-muted".
Differential Revision: https://phabricator.services.mozilla.com/D14480
--HG--
extra : moz-landing-system : lando
In order to know whether we have temporary autoplay permission without creating a request, we need to
cache its state in the outer window so that we can get the correct returned value for AutoplayPolicy::IsAllowedToPlay().
Differential Revision: https://phabricator.services.mozilla.com/D7013
--HG--
extra : moz-landing-system : lando
After bug1476555 landed, IsMediaElementAllowedToPlay() would only return boolean, not integer. We should modify AllowAutoplayToStr() in order to log the correct result.
Differential Revision: https://phabricator.services.mozilla.com/D6864
--HG--
extra : moz-landing-system : lando
If a site had been granted persistent permissions, but hasn't accessed navigator.mediaDevices yet.
Then, we can't read the permission because MediaManager hasn't be created yet.
We should read these permissions without loading MediaManager.
In addition, I noticed that even user only requests 'screen' permission, we would also add the 'camera'
and 'microphone' permission in the nsIPermissionManager. That makes us no way to print the log to distinguish
what actually permission user granted.
Differential Revision: https://phabricator.services.mozilla.com/D6540
--HG--
extra : moz-landing-system : lando
In the ideal situation, sites should create AudioContext only when sites are going to produce
sound, so we would show doorhanger to ask users whether they want to allow autoplay.
We delay the AudioContext's state transition from `suspended` to `running` until
(1) user click 'Allow' button in doorhanger
(2) user interact with sites, and then AudioContext calls resume() again
Differential Revision: https://phabricator.services.mozilla.com/D5610
--HG--
extra : moz-landing-system : lando
We would allow media without audio track to autoplay after it had loaded the metadata.
If media hasn't loaded metadata yet, we would treat it as audible media and then block it.
Differential Revision: https://phabricator.services.mozilla.com/D3670
--HG--
extra : moz-landing-system : lando
We would allow media without audio track to autoplay after it had loaded the metadata.
If media hasn't loaded metadata yet, we would treat it as audible media and then block it.
Differential Revision: https://phabricator.services.mozilla.com/D3670
--HG--
extra : moz-landing-system : lando
Only allow top-level video document to autoplay in order to avoid autoplay from
video document which is in the iframe.
MozReview-Commit-ID: BbyjviK1BRK
--HG--
extra : rebase_source : f84421e27c6029dd3733f3c5a5d329b1755a0ee3
Add new log module which allow us to debug by using "MOZ_LOG=Autoplay:5".
MozReview-Commit-ID: 9CG5JyCw21G
--HG--
extra : rebase_source : c71c4bbed88b07a7803d93b661bfeac37cb94035
In present web extension design (both Firefox and Chrome), background script can autoplay.
We don't want to break this design, so we would always allow it to autoplay.
MozReview-Commit-ID: 9BfWgll7PNx
--HG--
extra : rebase_source : 7996daa06c31a84a2aea9008daa9bddfcde98c74
Allow autoplay for video document when user is directly viewing a video/audio by visiting
its url.
MozReview-Commit-ID: GnSxx32h6hm
--HG--
extra : rebase_source : 0890f7f3e80711b35c65a6f32d7ce960de76d20e
We'd like to add telemetry to help inform the decision as to how enabling
block autoplay will affect video playback in the wild.
Our data science team would also like some input to help them estimate the
rate at which our shield study would receive pings, and the telemetry
collected here will help them estimate that.
We'd like to collect the following, on a per session basis:
* Count of the number of top level content documents loaded, as denominator for
other stats collected here.
* Count of the number of top level content documents which contained (directly
or in a descendant document) playback of an audible media element.
* Count of the number of top level content documents which contained (directly
or in a descendant document) a muted media element that was paused by the
autoplay policy because it tried to unmute and it wasn't allowed to autoplay
audibly.
* Count of the total number of audible autoplay videos that would have not been
allowed to play if block autoplay was enabled. We'd either prompt for
permission on these videos, or block outright depending on user's settings.
* Count of the total number of audible autoplay videos that would have been
allowed to play if block autoplay was enabled.
MozReview-Commit-ID: vHWJPyqHjT
--HG--
extra : rebase_source : e1f22ec83fda8b65d78f1de9f02cf060d424019c
Pending figuring out how we want to block autoplay of WebAudio content, we
should just not block it by default for the initial release of block autoplay,
and follow up once we've figured out how to not break the web.
MozReview-Commit-ID: ClfdrHcugLs
--HG--
extra : rebase_source : 54f61b0765f1d0ed9c754c90da9c2809a7de8676
The front end code can't always guarantee to give us an allow/cancel response
to a permission request. In particular in these cases:
* if we close a tab while showing a doorhanger, or
* if we navigate a tab while showing a doorhanger, or
* if the permission prompt requested in a background tab and never shown.
Handling all of these cases is problematic; we don't get events for all of
these where it's easy and cheap to determine that we should cancel the
permission request.
Canceling the permission request is important in the autoplay-media permission
request case as there's objects waiting on the resolution of the permission
request, and they leak in ASan builds while running chrome tests if the Gecko
size of the permission request doesn't get a notification telling it to stop
waiting.
But we can however rely on the doorhanger code to drop its reference to the
nsIContentPermissionRequest object that we pass to it when the doorhanger goes
away. So we can cancel the permission request in our
nsIContentPermissionRequest's implementation's destructor in order to easily
catch all the above cases.
In order to do that, we need to split AutoplayRequest into two; one part being
the implementation of nsIContentPermissionRequest (AutoplayPermissionRequest),
and the other part being the code to own the PromiseHolder and manage the
permission request (AutoplayPermissionManager).
AutoplayPermissionRequest keeps a weak reference to AutoplayPermissionManager,
so that it can tell the AutoplayPermissionManager to reject the request promise
when it's destroyed.
This fixes the ASan leak for which I got backed out from earlier in this bug,
and also fixes the cases above.
MozReview-Commit-ID: KoVkgIqDleW
--HG--
rename : dom/html/AutoplayRequest.cpp => dom/html/AutoplayPermissionManager.cpp
rename : dom/html/AutoplayRequest.h => dom/html/AutoplayPermissionManager.h
extra : rebase_source : dbca520a93d8c416f6d64c2da027630181bb5910
Add an implementation of nsIContentPermissionRequest to encapsulate requesting
permission from the user to autoplay audible media.
All documents in the tab request permission using the top level document's
origin, so the AutoplayRequest instance for a tab is stored on the top level
content window of the tab.
AutoplayRequest ensures that there's only a single prompt shown at once.
MozReview-Commit-ID: 2u3aLnEa21z
--HG--
extra : rebase_source : a3db3a1ef87a09442b47ae1b1034b4a0143289fb
extra : source : ae572bf618155a92b136fc5f12c1f8c9ab31f89c
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
We only should do the camera/mic permission or active capture test in
the case where document gesture activation is enabled.
MozReview-Commit-ID: 9xSe8FDn5tu
--HG--
extra : rebase_source : fb19fdcc7003d7ba04f5f1ab3a7d51ce63abc3db
extra : intermediate-source : 7de5bdbef79bacbee3284d49b77de36aceb0270e
extra : source : e72b9f4dcf418d4fcd2a0698f601d42eb9b0ecc0
Kannan Vijayan
Nicholas Nethercote
Sylvestre Ledru
Dale Harvey
Andreea Pavel
Daniel Varga
Ryan Hunt
Ehsan Akhgari
Alastor Wu
Emilio Cobos Álvarez
Andrea Marchesini
Chris Pearce
Tom Schuster
Paul Adenot