Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : 251574d238ded31b9df32dc89852251831d55757
extra : source : c53c7b0249ad3359fbc9f144f2cf9ca3b6386c59
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : fa253abde2029ec09c724404106d83623f064875
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 0faf7d21c8868c957ddc7fede0d56809f27dc161
extra : intermediate-source : ffb9ce93b92dd6396bfe038d3f6a8bcf929ec277
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 8be131e80d95a6bf6e86c994fdfa40c14ba610eb
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
If result is zero, getPrivilegedProps() would incorrectly return null.
MozReview-Commit-ID: 57JMaFwDpGW
--HG--
extra : rebase_source : 394c73e9385d51dd891a230b648eec1992850044
extra : source : 49ef875bd65ef3776cde50c223c4d2f6d1699a09
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Kris Maglione
Brindusan Cristian
Sebastian Hengst
Cosmin Sabou
Boris Zbarsky
Csoregi Natalia
dvarga
Mark Banner
Narcis Beleuzu
Marco Castelluccio
Andrew Swan
Coroiu Cristina
Alastor Wu
Andrea Marchesini
Peter Van der Beken
Florian Quèze
Dorel Luca
Jared Wein
Gurzau Raul
Andrew McCreight