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 {, <