This needs to be on the compartment to prevent creating duplicate wrapped natives.
We now also allocate these objects in the compartment's first global for
consistency and to prevent leaks.
XPCWrappedNativeScope also stores the content XBL scope. I considered moving
this to RealmPrivate, but given the fate of in-content XBL I went with the
simpler option of keeping it on XPCWrappedNativeScope and release-asserting we
have a single realm in the XBL case.
Because XPCWrappedNativeScope no longer stores a global object, we no longer
need XPCWrappedNativeScope::TraceSelf, XPCWrappedNativeProto::TraceInside and
XPC_WN_Proto_Trace.
Differential Revision: https://phabricator.services.mozilla.com/D14849
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
This code dates back to when we had a concept of parent as distinct from the
concept of global. It was comparing compartments back then because in the
same-compartment case it would just JS_SetParent and return. When we got rid of
the concept of parents, the code was left as-is, even though at that point we
could just as easily compare the two globals.
I believe that in the same-compartment-different-globals case this is safe,
because in that case JS_TransplantObject will just keep using the original
object allocation but JSObject::swap it with the new object, so that it will
pick up the new global.
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a straight backout of (in that order) bug 1505468, bug 1503664, bug
1501479, bug 1499150, bug 1496805, and the second part of bug 1493849. The
first part of bug 1493849 was a backout of earlier instrumentation, and that
should stay.
At this point we know we're hitting OOM inside the JS engine while trying to
define properties on Document.prototype, so all this MOZ_CRASH instrumentation
is no longer needed.
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
Rather than adding a native type for nsID objects in WebIDL, this patch just
takes the approach of switching consumers over to using 'any' and calling the
APIs defined in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2283
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This means that our binary does not need to include concatenated strings such
as "set CanvasRenderingContext2D.fillStyle". It only needs to contain the
individual strings "CanvasRenderingContext2D" and "fillStyle" which are most
likely already present in the binary.
This change reduces the binary size on macOS x64 by around 200KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build. This change makes us generate slightly more code, which is
very much offset by the reduction in the amount of strings we ship.
@@ -15,22 +15,23 @@
movl 0x10(%rbx), %r12d
cmpl (%rbx), %r12d
jae loc_xxxxx
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
- leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
+ leaq aAttr, %rdx ; "Attr"
movq %rdx, (%rax,%rcx)
- movq $0x0, 0x8(%rax,%rcx)
+ leaq aSpecified, %rdx ; "specified"
+ movq %rdx, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x71, 0x1c(%rax,%rcx)
+ movl $0x3a1, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
orq %rax, %rcx
Depends on D9204
Differential Revision: https://phabricator.services.mozilla.com/D9205
--HG--
extra : moz-landing-system : lando
This means that our binary does not need to include concatenated strings such
as "set CanvasRenderingContext2D.fillStyle". It only needs to contain the
individual strings "CanvasRenderingContext2D" and "fillStyle" which are most
likely already present in the binary.
This change reduces the binary size on macOS x64 by around 200KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build. This change makes us generate slightly more code, which is
very much offset by the reduction in the amount of strings we ship.
@@ -15,22 +15,23 @@
movl 0x10(%rbx), %r12d
cmpl (%rbx), %r12d
jae loc_xxxxx
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
- leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
+ leaq aAttr, %rdx ; "Attr"
movq %rdx, (%rax,%rcx)
- movq $0x0, 0x8(%rax,%rcx)
+ leaq aSpecified, %rdx ; "specified"
+ movq %rdx, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x71, 0x1c(%rax,%rcx)
+ movl $0x3a1, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
orq %rax, %rcx
Depends on D9204
Differential Revision: https://phabricator.services.mozilla.com/D9205
--HG--
extra : moz-landing-system : lando
This means that our binary does not need to include concatenated strings such
as "set CanvasRenderingContext2D.fillStyle". It only needs to contain the
individual strings "CanvasRenderingContext2D" and "fillStyle" which are most
likely already present in the binary.
This change reduces the binary size on macOS x64 by around 200KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build. This change makes us generate slightly more code, which is
very much offset by the reduction in the amount of strings we ship.
@@ -15,22 +15,23 @@
movl 0x10(%rbx), %r12d
cmpl (%rbx), %r12d
jae loc_xxxxx
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
- leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
+ leaq aAttr, %rdx ; "Attr"
movq %rdx, (%rax,%rcx)
- movq $0x0, 0x8(%rax,%rcx)
+ leaq aSpecified, %rdx ; "specified"
+ movq %rdx, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x71, 0x1c(%rax,%rcx)
+ movl $0x3a1, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
orq %rax, %rcx
Depends on D9204
Differential Revision: https://phabricator.services.mozilla.com/D9205
--HG--
extra : moz-landing-system : lando
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
extra : intermediate-source : 28a19b7290ab288a1cb2cbf6d49f905cecc9682b
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
longsonr
Boris Zbarsky
Jan de Mooij
Razvan Maries
Andrew McCreight
Peter Van der Beken
Andreea Pavel
Cosmin Sabou
Sylvestre Ledru
Ciure Andrei
Diego Pino Garcia
Andrea Marchesini
Steve Fink
Jon Coppeard
Tooru Fujisawa
Benjamin Bouvier
Jeff Walden
Ehsan Akhgari
inspiro
Nika Layzell
arthur.iakab
Timothy Guan-tin Chien
Markus Stange
Brindusan Cristian
Narcis Beleuzu
Kris Maglione