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
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 978a3fecf87e1ac4414ec0ea93335796bc24951a
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 5852093c015844cf3cc49dcd7fe71c9ea881eef9
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 9679d42cc9df899e2208a3cb72e14fdaabbcad8c
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
The cycle collecter should make sure the cycle here gets collected and
clearing it causes us to fail a wpt test.
MozReview-Commit-ID: 4kL69h0AR9q
--HG--
extra : rebase_source : 7af54e6d4a1c909e09d5893dbff3d3efc7c90b79
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
