When running tests, we can build a WebIDL environment with no interfaces
exposed on the primary global. Unfortunately, due to the perfecthash.py logic
not handling empty tables, this causes an assertion to be raised.
We can work around this by generating some dummy code for that situation, as we
will never try to build it.
Differential Revision: https://phabricator.services.mozilla.com/D9407
This strategy allows us to dodge dynamic allocations in WebIDLGlobalNameHash.
This removes the Init() and Shutdown() methods, as well as Register. The
RegisterBindings.cpp file now only contains static data and one method
declaration for the WebIDLGlobalNameHash class.
This should also be faster by making the hashtable lookup infallible.
Differential Revision: https://phabricator.services.mozilla.com/D9406
A C++ object that is exposed to JS can have its reflector used as a
key in a weak map. Because a weak map does not keep its keys alive,
this means that the reflector can be discarded if it has no other
references aside from the C++ object, which will in turn remove its
weak map entry. If the C++ object can be accessed again later from JS,
it will get a new reflector which will have no weak map entry. This is
bad because it means some internal implementation detail has resulted
in data loss that is visible to JS. (Side note: this is also an issue
for cross compartment wrappers, which is handled by another
mechanism.)
To fix this, we can preserve the wrapper of any DOM reflector used as
a weak map key. This ensures that the reflector and its C++ object
have the same lifetime. If a WebIDL object is not wrapper cached, that
means that it cannot be accessed via C++, so we don't need to preserve
the wrapper. This is currently implemented for nsISupports classes,
but not other classes. For non-nsISupports classes, it would throw an
error rather than silently fail.
My patch adds support for non-nsISupports cycle collected objects. It
turns out that the existing addProperty hook just does wrapper
preservation, so we just call it for cycle collected classes. This
does mean that if addProperty changes in the future to do something
else, this code will need to be changed.
I verified that this test fails if TryPreserveWrapper is changed to do
nothing besides return true in the non-nsISuports case.
Depends on D6197
Differential Revision: https://phabricator.services.mozilla.com/D6198
--HG--
extra : moz-landing-system : lando
We need the isDOMClass() checks in the Compartment code to pass tests, because
some of the jsapi tests explicitly test those failure codepaths. But not with
DOM objects, which is what we're interested in here.
Differential Revision: https://phabricator.services.mozilla.com/D6047
--HG--
extra : moz-landing-system : lando
We need the isDOMClass() checks in the Compartment code to pass tests, because
some of the jsapi tests explicitly test those failure codepaths. But not with
DOM objects, which is what we're interested in here.
Differential Revision: https://phabricator.services.mozilla.com/D6047
--HG--
extra : moz-landing-system : lando
We want to be able to enter the Realm we were in when the callback was created
before calling it, but if the callback stores a cross-compartment wrapper we
don't really have a good way to find that Realm. So we store it explicitly by
storing a global when the callback is created.
The changes to the constructor signatures to use JSObject* instead of
JS::Handle<JSObject*> are so we can avoid having to root the global for these
calls. These changes make two of the constructors ambiguous when nullptr is
being passed for the first arg; this patch adds casts to disambiguate.
The IterableIterator helper currently only supports iterator methods which
return types which are supported by ToJSValue, but do not need a JSContext* to
construct them. That means that getters which need to return native JS objects
or values can't do so safely, or without resorting to hacks.
This patch adds templated helpers which will call a JSContext-accepting,
JS::Value-returning version of the getter methods if they exist, and fall back
to the simpler versions if they don't.
MozReview-Commit-ID: hedZOc3lqR
--HG--
extra : rebase_source : b92cdc3900b3c9bee41836af4d4b9f4e65f3d5f6
We want to have some class names with spaces in them, but everything assumes
that an interface identifier is in fact an identifier (e.g. uses it in C++
identifiers like namespace names).