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
The patch in the next part will need a handle to the object in
TryPreserveWrapper.
Differential Revision: https://phabricator.services.mozilla.com/D6197
--HG--
extra : moz-landing-system : lando
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
When a custom element is defined we can check whether its class is an instance
of XULElement or HTMLElement and tag the defintion with a namespace accordingly.
This allows us to know the correct namespace for the custom element when
created.
Differential Revision: https://phabricator.services.mozilla.com/D2680
--HG--
extra : moz-landing-system : lando
The problem we're solving here: getting/entering the realm/global of a cross-compartment wrapper doesn't make sense once there are multiple realms in a compartment and the CCW will be shared by all of them. Because nsXPCWrappedJS can store a CCW, we will no longer be able to use this JSObject to enter the target realm.
What this patch does: we pass a JSContext* to nsXPCWrappedJS::GetNewOrUsed and we use this to store a global object in nsXPCWrappedJS (with the invariant that the object and global stored in nsXPCWrappedJS are same-compartment). Then when we want to enter the nsXPCWrappedJS's target realm, we use this global object instead of the maybe-CCW object. Because we currently still have one realm per compartment and the objects are same-compartment, this is guaranteed to preserve behavior for now.
nsXPCWrappedJS has some code to deal with weak pointers. Fortunately this applies only to root wrappers and root wrappers always store an unwrapped JSObject, so the extra global we store is guaranteed to be marked by the GC in that case (a global object is never collected when there are live JSObjects belonging to the same realm).
This patch enables us to specify a custom element type with |is| attribute
or property when creating a XUL element. Because non-dashed names are valid
custom element names in XUL (bug 1446247), other checks has to modified
accordingly.
The checks I am settling with are
1) Forbids the custom built-in element names to be a non-dashed name.
2) Forbids the custom built-in element to extend a dashed built-in element name.
This also ensures the custom built-in element types don't take on the same
name as the element name it extends.
MozReview-Commit-ID: GCQ9RnfvvrC
--HG--
extra : rebase_source : 2fa13742525d2107580d50872ff5b0fc42539498
extra : source : 2dc5513660d78a4de4801109140743ffc9297f71
Without this, we will start including mozMemory in performance.toJSON() even if
the pref for it is not set, once 'object' becomes a JSON type.
This changes behavior in the following observable ways:
1) We stop exposing PerformanceResourceTiming's .serverTiming in the JSON
serialization in insecure contexts.
2) We stop exposing PerformanceTiming's timeToNonBlankPaint and
timeToDOMContentFlushed in the JSON serialization unless the relevant
preferences are turned on.
Andrea Marchesini
Boris Zbarsky
Nika Layzell
Alexander Surkov
Andrew McCreight
Emma Malysz
Jan de Mooij
Edgar Chen
Jeff Walden
Henri Sivonen
Dave Townsend
Narcis Beleuzu
Andreea Pavel
Bogdan Tara
Andi-Bogdan Postelnicu
Neil Deakin
Arnaud Bienner
André Bargull
Ben Kelly
Jeff Gilbert
Peter Van der Beken
Timothy Guan-tin Chien
Sebastian Hengst