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
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
Audio context would be allowed to start if
(1) its document has been activated by user gesture
(2) it's a offline audio context, because it won't directly output sound to audio
devices
In addition, all resume promises would be pending until audio context has been
allowed and user calls resume() again.
MozReview-Commit-ID: G6RV8dDM6vQ
--HG--
extra : rebase_source : bc1d2ad0594ad1f54c05ade06495918aaee14911
extra : source : 5031770d70fd643230cb4caf6a5106616adaf0fd
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4a974aba0533bfbd5e9bb4c4c11d77d17a81db6d
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4d9afdec0caa4a82b53bedfd645f259a5c760e4d
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 83e53a0035d72984494948f131a5d6e516baa577
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 97315d90fa46a16289135ac7490bd0dab651d682
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : fa8d1bfd2fb667e974dbe499d7f8215273d4fa10
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
