The `using` declarations in "Proxy.h" make it act like a second
"NamespaceImports.h", introducing names from `JS` into the `js` namespace.
Remove the `using` declarations from "Proxy.h" and then fix up the breakage by:
- Prepend `JS::` in various header files.
- Add "NamespaceImports.h" in cpp files.
- Add `PropertyDescriptor` to "NamespaceImports.h". There are many unqualified
references to `PropertyDescriptor`, making it a prime candidate for
"NamespaceImports.h".
Drive-by changes:
- Use local variables in `CheckProxyFlags()` to make the `static_assert`
conditions more readable.
Differential Revision: https://phabricator.services.mozilla.com/D92207
As part of DOM node adoption they are transplanted, and their expando chains are copied over.
This copying uses JS_CopyPropertiesFrom, which until this patch, cannot see
private fields as they are excluded from property iteration. This patch adds
property iteration for private fields, and renames JS_CopyPropertiesFrom to
JS_CopyOwnPropertiesAndPrivateFields which is more accurate.
The users of this method are all doing object manipulation in ways where
preserving the copied private field is the better default.
In addition to testing DOM nodes explicitly, this patch also adds a jit-test
which uses transplantableObject to test similar things with FakeDOMObjects.
Differential Revision: https://phabricator.services.mozilla.com/D84737
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
Instead of manually defining toStringTag we now add the toStringTag symbol to the list of properties.
This is also how we usually define toStringTag in the JS engine.
Even though this changes more code I like this approach better. Everything is centralized in the generated bindings file.
Differential Revision: https://phabricator.services.mozilla.com/D72179
So that we can update the holders table correctly we will need to remove the wrapper from its original vector and add it to the one associated with the new zone.
I tried to make SetPreservingWrapper private but there's still a use in layout/style/Rule.cpp that I couldn't see an obvious fix for.
Differential Revision: https://phabricator.services.mozilla.com/D68521
So that we can update the holders table correctly we will need to remove the wrapper from its original vector and add it to the one associated with the new zone.
I tried to make SetPreservingWrapper private but there's still a use in layout/style/Rule.cpp that I couldn't see an obvious fix for.
Differential Revision: https://phabricator.services.mozilla.com/D68521
--HG--
extra : moz-landing-system : lando
CStringArrayAppender is just a copy of StringArrayAppender with the incoming
types expanded to accept both wide and narrow strings. Later patches will
remove the wide-string variants incrementally.
Differential Revision: https://phabricator.services.mozilla.com/D65537
--HG--
extra : moz-landing-system : lando
This does not change behavior at the moment, because the only callers of
ThrowErrorMessage that pass an error number that has a context pass an empty
string for the first (context) arg. Both of those callers are changed to pass
nullptr for the context in this patch.
We want to support nullptr to mean "empty context", because that way at
callsites we can avoid having extra empty strings.
We could avoid putting this machinery in place if we hardcoded the trailing
": " at all the callsites, but that would reduce future flexibility in where the
context is placed in the message string (e.g. if we wanted to move it to the
end instead of the beginning) and increase the amount of string data we have to
cart around in the binary quite noticeably: we have a _lot_ of places in
bindings where we call ThrowErrorMessage.
Differential Revision: https://phabricator.services.mozilla.com/D64882
--HG--
extra : moz-landing-system : lando
This does not change behavior at the moment, because the only callers of
ThrowErrorMessage that pass an error number that has a context pass an empty
string for the first (context) arg. Both of those callers are changed to pass
nullptr for the context in this patch.
We want to support nullptr to mean "empty context", because that way at
callsites we can avoid having extra empty strings.
We could avoid putting this machinery in place if we hardcoded the trailing
": " at all the callsites, but that would reduce future flexibility in where the
context is placed in the message string (e.g. if we wanted to move it to the
end instead of the beginning) and increase the amount of string data we have to
cart around in the binary quite noticeably: we have a _lot_ of places in
bindings where we call ThrowErrorMessage.
Differential Revision: https://phabricator.services.mozilla.com/D64882
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--HG--
extra : moz-landing-system : lando