Created attachment 547278 [details] [diff] [review]
Currently, there is this really strange encapsulation-breaking method whereby nsAppShellService sets the safe JS context for the main thread to the hidden window's context. mrbkap said this is stuff is from long ago and I should probably ask bz. The attached patch (which just removes it) is green on try.
SetSafeJSContext isn't thing in the world, but it certainly confounds reasoning about the context stack and safe JS contexts.
Hrm... I thought we used to have code that in fact did depend on the safe context being the hidden window (or more importantly having an associated nsIScriptContext and the like), but maybe that's gone now.
With this change, is the safe context just some synthetic jscontext?
ccing jst too, because he may know more about this than I do (which would not be hard!).
(In reply to comment #1)
> With this change, is the safe context just some synthetic jscontext?
Yes, created by XPCJSContextStack::GetSafeJSContext. It has null principals and some faked-up global object.
Comment on attachment 547278 [details] [diff] [review]
Well, let's give this a shot.
I'll have wait a bit, one of the other uses of SetSafeJSContext is dom/src/threads/nsDOMThreadService.cpp which seems to have been given reprieve for the time being.
Created attachment 548956 [details] [diff] [review]
Incidentally, this change did break new web workers. Easy fix, though. Over the shoulder r+ from Ben.