The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
It a stateless wrapper around static methods in nsHTMLTags and nsHTMLElement,
and hence an unnecessary layer of indirection that just adds complexity and
slowness. This patch removes it, cutting almost 300 lines of code.
This requires making nsElementTable.h an exported header, to expose the
nsHTMLElement methods.
--HG--
extra : rebase_source : abbcb8e5001389affbf717092213b898673db07f
In the new order, it will be a compartment-level bit rather than a
realm-level bit, so it does not belong on the Scope.
--HG--
extra : rebase_source : 44aa4620f7fd7f8d253c8c7f09bf8c97c00ff061
extra : source : 5a9c01720d7929e43aa70341d3821bfaa2479592
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
The main reason to not do this would be performance (avoiding the
addref/release), but there are two main mitigating factors:
1) All calls to UnwrapReflectorToISupports that pass in a Web IDL object
already do the addref (and in fact QI). So this only affects the
XPCWrappedNative case.
2) The vast majority of the callers proceed to QI on the pointer anyway, and a
second addref is cheap; it's the first addref after a CC that can be
expensive on a cycle-collected object.
Going through the changes one by one:
* In GlobalObject::GetAsSupports, we do have a change that slightly slows down
precisely in the XPCWrappedNative global case. That's the message managers
and the backstagepass. And this really only affects calls to Web IDL statics
from those globals.
* In UnwrapArgImpl we're talking about a Web IDL method taking an "external
interface" type, and the UnwrapReflectorToISupports call is immediately
followed by QI anyway.
* In UnwrapXPConnectImpl we're talking about the case when we have a
non-WebIDL-object implementation of a Web IDL interface. Again, this is the
message manager globals, for EventTarget. And we have a QI call immediately
after the UnwrapReflectorToISupports.
* In the generated HasInstance hook for EventTarget we will be slightly slower
when the LHS of the instanceof is an XPCWrappedNative. And not much slower,
because again there's an immediate QI.
* In InstallXBLField we're never going to have an XPCWrappedNative as thisObj;
it's always an Element in practice. So this is no more expensive than before.
* In sandbox's GetPrincipalOrSOP we now have an extra addref. But it was
followed by various QIs anyway.
* In XPCConvert::JSValToXPCException we have an extra addref if someone throws
an XPCWrappedNative, which is fairly unlikely; our actual Exception objects
are on Web IDL bindings. Plus we have an immediate QI.
* In xpc::HasInstance we have an extra addred if the LHS of instanceof is an
XPCWrappedNative. But, again, there's an immediated QI after the
UnwrapReflectorToISupports.
* In xpcJSWeakReference::Init we are likely doing an extra addref, but again
immediately followed by QI.
I think it's worth making this change just to remove the footgun and that the
perf impact, if any, is pretty minimal.
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
The patch makes the following proxy changes:
* The number of slots in ProxyValueArray is now dynamic and depends on the number of reserved slots we get from the Class.
* "Extra slots" was renamed to "Reserved slots" to make this clearer.
* All proxy Classes now have 2 reserved slots, but it should be easy to change that for proxy Classes that need more than 2 slots.
* Proxies now store a pointer to these slots and this means GetReservedSlot and SetReservedSlot can be used on proxies as well. We no longer need GetReservedOrProxyPrivateSlot and SetReservedOrProxyPrivateSlot.
And some changes to make DOM Proxies work with this:
* We now store the C++ object in the first reserved slot (DOM_OBJECT_SLOT) instead of in the proxy's private slot. This is pretty nice because it matches what we do for non-proxy DOM objects.
* We now store the expando in the proxy's private slot so I removed GetDOMProxyExpandoSlot and changed the IC code to get the expando from the private slot instead.