This restriction was put in place back when we automatically added
QueryInterface to all rootmost non-abstract interfaces. At the time, we needed
to make sure it did NOT end up on EventTarget, because then webidl quickstubs
would replace the QI impl on non-webidl EventTargets with the WebIDL one, which
would not work for them.
Since then, we have removed WebIDL quickstubs and we now explicitly list which
interfaces get QueryInterface, so this check is no longer needed.
MozReview-Commit-ID: 5B13ymdyLp3
When defining WebIDL constants in C++, we may need to undefine some
constant names that conflict with windows.h preprocessor defines.
Doing this in the binding header is far easier than tracking down the
include orders that may cause conflicts.
MozReview-Commit-ID: A0UoYezIQs5
--HG--
extra : rebase_source : d9100af2ccdb5c6e6468542ac68f74b2e4f9050c
Generate C++ const definitions for WebIDL interface members with
primitive types.
MozReview-Commit-ID: 4fLtteWZUWA
--HG--
extra : rebase_source : bf45427c6b0e4acfa32ed3431a3cf385972950a0
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
Now that Gecko controls error reporting and the JS engine is no longer doing
JS_IsRunning checks, we should consistently have exceptions here.
MozReview-Commit-ID: IqBe5ArJc2l
Remove following outdated comment from Codegen.py
# We don't enforce this for chrome in realease builds to avoid the addon
# compat fallout of making that change. See bug 916644.
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
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.
Most of these changes are just replacements of GetNativeOfWrapper with
UnwrapReflectorToISupports, which is all it did under the hood.
The other changes are as follows:
* In nsDOMClassInfo, we really care whether we have a window, so we can just
UNWRAP_OBJECT to the Window interface, since Window is always on Web IDL
bindings now. Also, the weird compartment check hasn't been needed ever since
GetNativeOfWrapper stopped returning things off the passed-in object's
prototype chain (Firefox 22, bug 658909).
* The only use of do_QueryWrapper was to get a Window in nsDocument; again we
can UNWRAP_OBJECT.
* In XPCJSRuntime, we again just want to check for a Window, so UNWRAP_OBJECT.
The idea is that CastableObjectUnwrapper will want to have a MutableHandle for
the thing it's unwrapping whenever its target is a raw pointer. Since we have
convenient MutableHandle<Value> in most cases, it's easier to switch
CastableObjectUnwrapper to working with MutableHandle<Value> or Handle<Value>
instead of trying to get MutableHandle<JSObject*> in the right places.
There are basically two changes here:
1) Make CastableObjectUnwrapper work with at thing that looks like a Value.
2) Change various callsites to pass in MutableHandle<Value>, in addition to a
Handle<Value>, into the JS-to-C++ conversion templates. The
MutableHandle<Value> is passed as ${maybeMutableVal}. It may not actually
end up being a MutableHandle in some cases.
The reason for passing both a Handle and a MutableHandle is that when the thing
we actually have is a Rooted named "foo" the Handle will be "foo" but the
MutableHandle is most naturally written as "&foo". This is not a problem if
you're just passing it through, but if you want to test whether it's an object,
say, you have a problem. Writing "foo.isObject()" is ok, but "&foo.isObject()"
is not, and neither is "(&foo).isObject()". This could be worked around by
passing the MutableHandle as "JS::MutableHandle<JS::Value>(&foo)" or something,
and then "JS::MutableHandle<JS::Value>(&foo).isObject()" does work. But it
makes the code very hard to read.
So we just pass both things along; ${val} should be used for readonly access and
${maybeMutableVal} any time you really want a MutableHandle.
Current codegen list the methods for clearing cached attribute values in both
chrome only unforgeable methods and chrome only normal methods, but they should
exist only in the normal ones.
MozReview-Commit-ID: Il2JvCLZ2v3
--HG--
extra : rebase_source : 21b9c715c921c4ac7f6ed4c235ee79a3628162bd
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
Dave Townsend
Edgar Chen
Boris Zbarsky
Sylvestre Ledru
Kyle Machulis
Tom Schuster
Peter Van der Beken
Jan de Mooij
Kris Maglione
Jon Coppeard
Eden Chuang
Valentin Gosu
Andrew McCreight
Benjamin Bouvier
John Dai
Andrea Marchesini
Ting-Yu Chou
Mats Palmgren