This can definitely happen now if the |this| object is wrong. It's possible
that we should be checking this earlier, but as the code stands this assertion
is incorrect.
The old code seems to be deciding whether we have a double-wrapped object by
checking _either_ the rv of GWNOJO _or_ the potential slim wrapper. This is
nonsensical, because double-wrapped objects are never slim wrappers.
Furthermore, that variable here is named 'proto', which further suggests
that this code is nonsensical. So let's just check for WNs.
Also, it seems pretty wack to be innerizing here before storing the jsval,
but I'm going to leave that for now.
Using JSPropertyOp means a null shape getter, whereas null means that the shape
uses the class getter. This means that stuff like window.top, which is defined
as a non-configurable |own| property in nsDOMClassInfo, was getting set up with
XPC_WN_Helper_GetProperty as its get operation. But this confused
SandboxProxyHandler, which explicitly avoids rebinding class getters/setters,
which in turn meant that our sandboxPrototype feature was relying on the crazy
prototype-climbing behavior of GetWrappedNativeOfJSObject to make stuff like
|this.top| work. We're removing this behavior, so we need to fix nsDOMClassInfo
here.
Here are some DefineProperty cases that I left with null getters/setters:
* nsDOMClassInfo::ResolveConstructor
* The child window stuff at the bottom of nsWindowSH::NewResolve
* Named item resolution in nsNamedArraySH::NewResolve
* document.all stuff (scary!)
* nsHTMLDocumentSH::NewResolve
* nsHTMLFormElementSH::NewResolve
* nsStorage2SH::NewResolve
It's not clear to me why it's done this way, but it confuses our ability to
determine during wrapper lookup whether we're doing a set or a get. This aligns
the behavior with XPC_WN_CallMethod, including passing JSID_VOID for the name
(which is safe because XPCCallContext explicitly special-cases JSID_VOID and
doesn't call SetName in that case).
This can definitely happen now if the |this| object is wrong. It's possible
that we should be checking this earlier, but as the code stands this assertion
is incorrect.
The old code seems to be deciding whether we have a double-wrapped object by
checking _either_ the rv of GWNOJO _or_ the potential slim wrapper. This is
nonsensical, because double-wrapped objects are never slim wrappers.
Furthermore, that variable here is named 'proto', which further suggests
that this code is nonsensical. So let's just check for WNs.
Also, it seems pretty wack to be innerizing here before storing the jsval,
but I'm going to leave that for now.
