This removes the non-standard `hasInstance` proxy trap.
All objects will now use the algorithm in `JS::InstanceofOperator`. That function
uses other primitives and proxy traps already available to JS code.
As discussed in the bug, there's a minor difference in behavior: for
`xrayWrapper instanceof xrayWaiver` we used to always return false but we can now
invoke `xrayWaiver[Symbol.hasInstance]()`.
Differential Revision: https://phabricator.services.mozilla.com/D142061
Convert all JS_FRIEND_API to JS_PUBLIC_API. At this point, the JS_PUBLIC_API has
no formal curation process and in practice we add a lot of new features to
JS_FRIEND_API without giving much thought to if they should be public. The
result is that all embedders need to use the friend API in some form and the
distinction has lost meaning.
Going forward, we should continue to use the js/public/experimental directory as
a place to expose new APIs, and in general should strive for high quality of the
APIs that are exposed. If a particular API is tricky or discouraged, comments
explaining that will be more helpful that a losely applied FRIEND_API marker.
Differential Revision: https://phabricator.services.mozilla.com/D117607
Note that on 32-bit platforms, JSObject is still 8 bytes. This means we don't have
to worry about misaligned DoubleValue stores to fixed slots on ARM32/MIPS32.
Differential Revision: https://phabricator.services.mozilla.com/D106986
Note that on 32-bit platforms, JSObject is still 8 bytes. This means we don't have
to worry about misaligned DoubleValue stores to fixed slots on ARM32/MIPS32.
Differential Revision: https://phabricator.services.mozilla.com/D106986
Also replace JSClass::isProxy with isProxyObject and clarify that the flag
indicates primarily that the JSObject is of type js::ProxyObject.
In DOM binding code, prefer checks for NativeObject rather than !ProxyObject
where that is what we really meant.
Differential Revision: https://phabricator.services.mozilla.com/D105884
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
Proxy JSClasses are defined through a special macro (`PROXY_CLASS_DEF`), which
ensures all Proxy related bits are set correctly. The macro doesn't allow to
specify a ClassSpec, so we need to add a new macro which supports that
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D52666
--HG--
extra : moz-landing-system : lando
Proxy JSClasses are defined through a special macro (`PROXY_CLASS_DEF`), which
ensures all Proxy related bits are set correctly. The macro doesn't allow to
specify a ClassSpec, so we need to add a new macro which supports that
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D52666
--HG--
extra : moz-landing-system : lando
The final huge patch. This is a search-and-replace removal of js::Class followed by clang-format and removal of the alias from TypeDecls.h.
Depends on D41986
Differential Revision: https://phabricator.services.mozilla.com/D41987
--HG--
extra : moz-landing-system : lando
Another big patch. This a search-and-replace followed by mach clang-format, and removal of the js::ClassOps alias from Class.h.
Differential Revision: https://phabricator.services.mozilla.com/D41761
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
In vm/Iteration.cpp this inlines some functions because there's a single
caller now. Follow-up patches will do additional cleanup/optimization.
Differential Revision: https://phabricator.services.mozilla.com/D18926
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--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
Jan de Mooij
Matthew Gaudet
Jon Coppeard
Ted Campbell
Steve Fink
Tom Schuster
Simon Giesecke
Narcis Beleuzu
André Bargull
Jeff Walden
Butkovits Atila
Gijs Kruitbosch
Bogdan Tara
Cosmin Sabou
Andrew McCreight
Brindusan Cristian
Yoshi Cheng-Hao Huang
Tooru Fujisawa
Benjamin Bouvier
Sylvestre Ledru