Cross-origin objects are supposed to have null prototypes, and throw when
attempting to set the prototype to any value other than null. Ordinary
cross-origin objects handle this correctly. RemoteObjectProxy has hooks which
are meant to give them the same behavior, but which are never actually
triggered, because the proxy objects are missing the required lazy prototype
flags.
Simply using the built-in prototype slot and setting it to immutable triggers
the desired behavior with much less implementation overhead.
Differential Revision: https://phabricator.services.mozilla.com/D46735
--HG--
extra : moz-landing-system : lando
Object.hasOwnProperty called on a cross-origin object needs to return true for
any property returned by its property enumerator or get hook, and throw a
security error for anything else. Ordinary cross-origin objects currently
behave correctly, but RemoteObjectProxy objects return false for indexed
frame getters, and never throw security exceptions for inaccessible
properties.
This patch fixes both of those issues by removing the `hasOwn` hook and
falling back to the BaseProxyHandler implementation, which defers to the
`getOwnPropertyDescriptor` hook. This is slightly more expensive, since it
requires reifying property descriptors for every check, but it should be a
relatively uncommon operation on cross-origin objects, and should not be
particularly expensive for any properties of a RemoteObjectProxy.
Differential Revision: https://phabricator.services.mozilla.com/D46734
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
Tom Schuster
Sylvestre Ledru
Butkovits Atila
Jeff Walden
Simon Giesecke
Kris Maglione
Jon Coppeard
Andrew McCreight
Noemi Erli
Yoshi Cheng-Hao Huang
Peter Van der Beken
Boris Zbarsky