This will let us answer the following questions (in a performant way):
1) What's the compartment's origin? Necessary to implement compartment-per-origin.
2) What's the origin's site? Necessary for the new Wrap() algorithm.
3) Has any realm in the compartment set document.domain? Necessary for the new Wrap() algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D5423
--HG--
extra : moz-landing-system : lando
This allows JS callers and C++ callers to both create and consumer iterators
in their preferred style, while still presenting the appropriate interfaces to
callers in the other language.
When a C++ caller requires an nsISimpleEnumerator from an XPCWrappedJS object,
if that class does not already have a QueryInterface method, it is assumed to
be a JS enumerator, and an appropriate wrapper is created. JS callers who wish
to implement nsISimpleEnumerator manually, or opt out of the automatic
conversions, may implement a QueryInterface method, which automatically opts
them out of this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D4290
--HG--
extra : rebase_source : eb61ee725a8c67e3e7f5b22d9aef9baa0cde1955
When an XPC wrapped JS object returns an object from a property or function
which is expected to return a given interface, we create a wrapper for that
interface regardless of whether the object has a QueryInterface method which
claims to support it. For the nsISimpleEnumerator enumerator case, the check
for that existing wrapper comes before the check for the nsISimpleEnumerator
special casing, which breaks automatic conversion in those cases.
This patch moves that check just before the check for the existing wrapper,
and just after the nsIPropertyBag special casing, which has similar semantics.
Differential Revision: https://phabricator.services.mozilla.com/D5335
--HG--
extra : rebase_source : 2201063455a2434cfa0c3c470f668fefa8528f4b
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
This moves all the node-specific reporting to nsIDocument.
OrphanReporter delegates all the reporting to that and then returns the sum of
all sizes, which is not ideal but was pre-existing.
Also, I moved the main mStyleSheets size reporting to DocumentOrShadowRoot for
it to be shared between document and ShadowRoot.
I'll add memory reporting for the computed stylesheet maps and such in the
ShadowRoot in a followup.
I went through all the XBL bindings, though it seems I could just use
GetBindingWithContent(), since according to:
https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/dom/xbl/nsXBLBinding.cpp#615
We don't allow multiple bindings to contribute anon content. Anyway it was the
same amount of code...
Differential Revision: https://phabricator.services.mozilla.com/D4433
--HG--
extra : moz-landing-system : lando
The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch allows us to define methods or getters/setters for any of the
current set of well-known symbols. Those are defined by adding the [symbol]
attribute to a method:
[symbol]
Iterator iterator();
which causes the method to define a property with the well-known symbol which
matches its method name (Symbol.iterator, in this case).
Due to the implementation details of the XPIDL parser, this currently does not
support defining a non-symbol function with the same name as a symbol
function:
[symbol]
Iterator iterator();
[binaryname(OtherIterator)]
Thing iterator(in nsIDRef aIID);
throws for a duplicate method name, even though there is no actual conflict.
Differential Revision: https://phabricator.services.mozilla.com/D3724
--HG--
extra : rebase_source : 1385e2da93113306730f7c087fe7385dbe668e91
extra : histedit_source : 3afd9fe38e7cbddc5576c2bd1673496dd623e489
