content-document-global-created is called not just on content windows, but also ChromeWindows. For code that encounters this problem, see https://bug550936.bugzilla.mozilla.org/attachment.cgi?id=459609
There are two separate notifications: "content-document-global-created" and "chrome-document-global-created". These are differentiated by permissions, not by docshell type. See bug 549539 comment 0, which explicitly talks about this. If you want to differentiate by docshell type, then you probably need to register for both notifications (for the moment) and check whether it's an nsIDOMChromeWindow (though using instanceof would be less code than try/catch/QI).
And the point is, that it's not "chrome-global-created" it's "content-document-global-created" (that is, a global for a content document, which is any non-chrome document).
Wait, so are we running non-system-principal code in ChromeWindows?
We can be, if someone goes and loads it there... Usually that's a security hole, of course, so maybe we should figure out where this is coming from here.
Alon, under what conditions did you get this notification for a ChromeWindow? What was the window's location?
(In reply to comment #5) > Alon, under what conditions did you get this notification for a ChromeWindow? > What was the window's location? I noticed that ChromeWindows were being called when running the relevant (installtrigger) automated tests. The location of those windows was about:blank. I can run the tests again if there is a way to get additional information to help with this. (Meanwhile for other reasons we switched to listening to the DOMWindowCreated event, btw, so later versions of the patch linked to above are different.)
Oh, right. We don't inherit the system principal into about:blank iframes in a chrome context, as I recall. That's not a security issue.
So maybe we shouldn't send the content-document-global-created notification in that situation. I.e. when we have a content document inside a chrome window. And not send any notification in that case.