678365 - nsFrameMessageManager suffers ASSERTION: Non-global object has the wrong flags

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Alon Zakai (:azakai)]

With the patches in bug 669240, which make it so InstallTrigger is an nsIDOMGlobalPropertyInitializer, and consequently we pass around messageManagers through xpconnect more frequently, we hit

###!!! ASSERTION: Non-global object has the wrong flags: '!(jsclazz->flags & JSCLASS_IS_GLOBAL)', file ../../../../../js/src/xpconnect/src/xpcwrappednative.cpp, line 1148

in some tests, for example content/base/crashtests/642022-1.htm and the toolkit/mozapps/extensions mochitests.

Debugging with mrbkap and dougt initially led to the suspicion that the nsFrameMessageManager doesn't initialize its global object early enough, however further tests imply that it does, so there is no known workaround for this.

Further investigation showed that when we hit this assertion we run through a codepath that includes this comment in xpcconvert.cpp:

// XXX The OBJ_IS_NOT_GLOBAL here is not really right.

which seems to imply the xpconnect code knows it is doing the wrong thing (the assertion is thrown because of that flag being set to that value).

It looks like the difference between before the patches in bug 669240 and after is that before, when we need the wrapper we find it in the cache. After, we don't find it, so we create one, which leads us to that assertion. In other words, it looks like we would have hit that assertion before those patches, but we were somehow lucky enough not to.

In bug 669240 we will need to make content/base/crashtests/642022-1.htm tolerate this assertion for now. When we resolve this bug we should undo that.

Comment 1

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.