We now have the invariant that any in-use cx must be pushed onto the JSContext
stack with one of our stack-scoped automatic nsCxPusher classes. These classes
hold a strong ref to the nsIScriptContext associated with the JSContext they
push (if any). This means that, if this cx is in use, we will always have at
least one strong reference to the nsJSContext coming from the stack, meaning
that neither the destructor nor the Unlink() implementation will be called.
So we don't need to do any deferred destruction of the cx anymore.
The primary consumer of this is the whole inner/outer DOM window setup, which
uses the default global to track the current inner. But there are few other
random ones as well.
We use this as an opportunity to convert a bunch of consumers from the two-step
GetNativeContext() -> JS_GetGlobalObject() into just |GetNativeGlobal()|. This
will make things much easier to convert when we start tracking the current inner
explicitly.
There are still a handful that either are used with other runtimes, or that
happen very early/late in cx the lifetime of various things where it doesn't
necessarily make sense to have a cx on the stack. This should definitely ensure
that we're not doing double-duty with the nsCxPusher change, though.
I also replaced some uses of mJSContext with AutoJSContext upon auditing that
they're only ever called by other nsJSContext functions that just pushed. This
makes the code much easier to audit because we know that we're just inheriting
the caller's cx (which is stack-top) rather than injecting a potentially-
unrelated cx.
This patch is bigger than I'd like it to be, but there are a lot of interlocked
dependencies and I eventually decided it was easier to just lump it together.
The semantics of |showModalDialog|/|window.dialogArguments| (an web-exposed
HTML5 feature) and |openDialog|/|window.arguments| (a XUL-proprietary feature)
are quite different. The former is essentially a security-checked JSVal, while
the latter gets converted into an array. We handled them together in the old
world, which led to a lot of confusion and muddled semantics. This patch
separates them.
This patch also eschews the roundabout resolve hook for dialogArguments in favor
of returning them directly from the XPIDL getter. This better matches the
behavior in the spec, especially because it allows dialogArguments to live on
the outer as they're supposed to, rather than the first inner that happens to
end up in the docshell. All in all, this should make this all very
straightforward to convert WebIDL when the time comes.
The current spec on the origin checks here is pretty fictional, so I've filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21932 to fix it. This patch
should more or less preserve the current security behavior.
This patch is bigger than I'd like it to be, but there are a lot of interlocked
dependencies and I eventually decided it was easier to just lump it together.
The semantics of |showModalDialog|/|window.dialogArguments| (an web-exposed
HTML5 feature) and |openDialog|/|window.arguments| (a XUL-proprietary feature)
are quite different. The former is essentially a security-checked JSVal, while
the latter gets converted into an array. We handled them together in the old
world, which led to a lot of confusion and muddled semantics. This patch
separates them.
This patch also eschews the roundabout resolve hook for dialogArguments in favor
of returning them directly from the XPIDL getter. This better matches the
behavior in the spec, especially because it allows dialogArguments to live on
the outer as they're supposed to, rather than the first inner that happens to
end up in the docshell. All in all, this should make this all very
straightforward to convert WebIDL when the time comes.
The current spec on the origin checks here is pretty fictional, so I've filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21932 to fix it. This patch
should more or less preserve the current security behavior.
