Created attachment 824773[details]
main.jsp
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Steps to reproduce:
As of Firefox 24, we've noticed that observers are not notified when loading an overlay using document.loadOverlay. Note that this is a remote XUL site that I am testing from localhost. We've been using the remote XUL manager add on for some time to enable remote XUL for our domains. See the attached files for a simple example that illustrates the problem
Actual results:
The overlay is loaded, but the observe() method is not called. The error console shows "Error: Permission denied for <http://localhost> to create wrapper for object of class UnnamedClass"
Expected results:
The observe method should have been called.

(In reply to Boris Zbarsky [:bz] from comment #3)
> Sounds like some of those callers were relying on CallerTypeIsJavaScript()
> testing false and hence security checks being skipped, no?
Yeah, probably. It's only a coincidence that it ever worked, really.

(In reply to Boris Zbarsky [:bz] from comment #7)
> Well, what's failing exactly? Are we running security checks when we
> actually shouldn't somehow?
The remote XUL page defines an observer and passes it to document.loadOverlay. When the observer is invoked, it's invoked with various XPCOM-y argument types (without the DOM bit in classinfo) for which we're never supposed to allow reflectors in unprivileged scopes. So we fail.

(In reply to Boris Zbarsky [:bz] from comment #9)
> So in the old world we'd pass in an nsIURI object to the unprivileged
> observer but it just couldn't do anything with it?
Why couldn't it do anything with it?

I thought XPConnect did security checks on every access. And nsScriptSecurityManager::CheckPropertyAccessImpl when it fails to find a security policy will default to SCRIPT_SECURITY_NO_ACCESS if there is no classinfo claiming IsDOMClass().

Anyway. _If_ that used to be the case, how about we check whether caller is chrome in LoadOverlay(), and if not set a flag on our observer entry that will make us just pass a null URI to the observer? Seems like it would get us to a state that's no worth than before, right?

(In reply to Boris Zbarsky [:bz] from comment #13)
> Anyway. _If_ that used to be the case, how about we check whether caller is
> chrome in LoadOverlay(), and if not set a flag on our observer entry that
> will make us just pass a null URI to the observer? Seems like it would get
> us to a state that's no worth than before, right?
Well, it's kind of gross, and there's no guarantee that this is the only case that people are going to run into. It's kind of a crapshoot.
The other option is to disable CanCreateWrapper checks (or at least some subset of them) for remote XUL.

Comment on attachment 832332[details][diff][review]
Exempt Remote XUL from CanCreateWrapper checks. v1
We should get this on aurora (soon to be beta) and esr24. ESR24 is especially important, I think, because that's where a lot of our remote XUL consumers are, and they're all switching over from esr17. We should get this into tuesday's release if possible, but I don't know how possible that is.
This approval request also covers the patch in bug 943152, which is an automation patch that prevents the tests for this bug from turning the tree orange.
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 877478
User impact if declined: Breakage in remote XUL pages
Testing completed (on m-c, etc.): Just landed to m-c.
Risk to taking this patch (and alternatives if risky): Low-risk.
String or IDL/UUID changes made by this patch: None

Comment on attachment 832332[details][diff][review]
Exempt Remote XUL from CanCreateWrapper checks. v1
Approving on aurora at this time as its a low risk uplift. For current esr, we have already gone to build, so unfortunately this will have to land for the next round

Given in-testsuite coverage this fix will not be manually verified by QA. If you believe this warrants extra QA attention please nominate for testing by removing this whiteboard tag and adding the verifyme keyword. Please also provide any details you have that may inform our testing.