nsIDOMCharacterData and nsIDOMText quickstubs are not needed after bug 826703.
nsIDOMRect quickstubs haven't been needed since bug 824970 landed.
nsCSSPropertiesQS has been unused since bug 801083 at least.
The various includes being removed are either fully on WebIDL now or using WebIDL quickstubs.
The assertions in nsINode and nsWrapperCache are to eagerly catch
failures to override those methods.
The classinfo change for XULTreeBuilder is needed because one of those
is returned via an nsIXULTemplateBuilder attribute on XULElement.
Alternately, I could mark it notflattened in Bindings.conf, but Enn
said he prefers this anyway.
The change to the QI impl in BindingUtils is needed because when
XPConnect converts an IID from C++ to JS it makes is an nsJSID, not an
nsJSIID. We've run into this before, sadly.
I removed "id" from nsIDOMXULElement because it's already on Element.
I suppose I could have left it there, but this seems cleaner.
The nsJSIID::HasInstance changes are needed to support XBL-implemented
interfaces. Sadly, this does mean that if the underlying object QIs
to something but we didn't put those props on the WebIDL we'll end up
testing true for instanceof but not exposing the props. I don't see
an obviously better way. We should work on killing off uses of
"instanceof someinterface".
The browser.js change is needed to avoid throwing exceptions during
browser-chrome tests that are now getting reported because our
swapFrameLoaders is no longer an XPConnect method.
nsIDOMCharacterData and nsIDOMText quickstubs are not needed after bug 826703.
nsIDOMRect quickstubs haven't been needed since bug 824970 landed.
nsCSSPropertiesQS has been unused since bug 801083 at least.
The various includes being removed are either fully on WebIDL now or using WebIDL quickstubs.
The assertions in nsINode and nsWrapperCache are to eagerly catch
failures to override those methods.
The classinfo change for XULTreeBuilder is needed because one of those
is returned via an nsIXULTemplateBuilder attribute on XULElement.
Alternately, I could mark it notflattened in Bindings.conf, but Enn
said he prefers this anyway.
The change to the QI impl in BindingUtils is needed because when
XPConnect converts an IID from C++ to JS it makes is an nsJSID, not an
nsJSIID. We've run into this before, sadly.
I removed "id" from nsIDOMXULElement because it's already on Element.
I suppose I could have left it there, but this seems cleaner.
The nsJSIID::HasInstance changes are needed to support XBL-implemented
interfaces. Sadly, this does mean that if the underlying object QIs
to something but we didn't put those props on the WebIDL we'll end up
testing true for instanceof but not exposing the props. I don't see
an obviously better way. We should work on killing off uses of
"instanceof someinterface".
The browser.js change is needed to avoid throwing exceptions during
browser-chrome tests that are now getting reported because our
swapFrameLoaders is no longer an XPConnect method.
XPCConvert needs to convert some string types to JS strings in order to call
from C++ into JS land. Make those converted JS strings allocate the buffers
from the JS compartment memory pool, instead of making them external and
allocated from the main heap.
This improves memory reporting and may also influence memory fragmentation
and/or performance.
This bug happens when we take the !useSandbox path. Basically, when the code
throws, we can end up with garbage in *aRetValue while still returning true
from EvaluateString. It looks like the convention is for these kind of eval
functions to return success even for invalid code, so lets just make sure we
check things a bit better.
This crashtest is kind of half-baked in the sense that it doesn't actually
crash without the rest of the patch. But the testcase here involves a lot of
undefined behavior (what ends up getting left in *aRetValue) during a call
to window.open (which spins the event loop, etc). I already sunk about half
an hour into trying to make it crash, so I'm just going to go with this for
now.
We tack these onto the tests from bug 812415, adding coverage for
nsExpandedPrincipal and making sure that the waivers are deep.
We also take the opportunity to check the asymmetric security
relationship between a principal and its corresponding nsEP.
There's no reason to do this any different than we do for XOWs and such. The
only thing this might conceivably support would be certain chrome XPWNs-as-COWs.
But that would require that they forced a parent in precreate without being
flagged as DOM objects in classinfo. And it's not clear why we'd want to support
that. And we're generally moving away from COWs anyway.
wantXrays means that the sandbox wants Xray wrappers even when accessing same-
origin content. The default is true, which Blake says has something to do with
GreaseMonkey and days of old.
This flag never had an effect for chrome, because the chrome->chrome case always
short-circuited to &CrossCompartmentWrapper::singleton. But once we start
respecting the flag as a general-purpose indicator that Xrays should be applied
same-origin, we need to either add a special case in Rewrap or make the flag reflect
reality. The latter seems cleaner and more sane.
However, things are complicated by the fact that there's also a completely different,
orthogonal usage, whereby setting wantXrays to false implicitly waives Xray on the
returned sandbox _and_ on any results returned from evalInSandbox. This is just nuts.
The former can be accomplished by callers manually using .wrappedJSObject, and the
latter by having EvalInSandbox transitively apply waivers from their sandbox arguments.
I've updated the documentation on the MDN page so that it only describes the
reasonable usage. The next step is to get rid of the crazy behavior. I think the
best path of migration is to have wantXrays: false keep implicitly waiving, but
waive return values from EvalInSandbox based on whether the argument was waived. This
patch does that.
__scriptOnly__ is unused on mxr and addons-mxr. Morevoer, the current
implementation is totally broken, because we check for NNXOW, which only
happens when a random content JS object ends up in some other cross-origin
scope (via addons, presumably), whereas chrome objects use ChomeObjectWrapper.
I'm soon going to replace SCRIPT_ACCESS_ONLY with checked unwrapping, and mark
all COWs as unsafe to unwrap (see bug 821573 and bug 658909). So let's just kill
this thing here.
There's a browser-chrome test that does this, which means that _all_ subsequent
browser-chrome tests inherit it. So depending on the ordering of cases in
WrapperFactory, we might end up using a CrossCompartmentWrapper rather than an
XrayWrapper, meaning that stuff like nodePrincipal doesn't work anymore.
The semantics of UniversalXPConnect are now entirely dicatated by what makes
our test suite go green. So let's not force ourselves to bend over backwards
during wrapping to handle this case. And let's fix that stupid test while
we're at it.
This should help ensure that recursion errors found in the shell actually
represent real errors. This also attempts to account for the difference in size
between debug and optimized builds to the size of js::Interpret's stack frame.
