I was running mochitests locally with a trunk build on Mac OS X and I saw this for test_NPNVdocumentOrigin.html: ###!!! ASSERTION: Shouldn't be calling InstantiatePluginInstance in an inactive document: 'Error', file /Users/josh/src/mozilla/ff_trunk_debug_x86_64/content/base/src/nsObjectLoadingContent.cpp, line 656 nsObjectLoadingContent::InstantiatePluginInstance(char const*, nsIURI*)+0x00000274 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009C3814] nsObjectLoadingContent::SyncStartPluginInstance()+0x00000103 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009CB4E3] nsAsyncInstantiateEvent::Run()+0x00000054 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009C0B64] nsThread::ProcessNextEvent(bool, bool*)+0x00000653 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x02361A33] NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x0000009D [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x022CB0AD] nsBaseAppShell::NativeEventCallback()+0x000000D1 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01F33291] nsAppShell::ProcessGeckoEvents(void*)+0x000001BD [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC851D] __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x00000011 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x000124F1] __CFRunLoopDoSources0+0x000000FD [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00011D5D] __CFRunLoopRun+0x00000389 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038B49] CFRunLoopRunSpecific+0x000000E6 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038486] RunCurrentEventLoopInMode+0x00000115 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000024D3] ReceiveNextEventCommon+0x000000B5 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000096D3] BlockUntilNextEventMatchingListInMode+0x0000003E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x0000960E] _DPSNextEvent+0x00000293 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00008E31] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000087 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00008735] -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000077 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC6BF7] -[NSApplication run]+0x000001D6 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00005071] nsAppShell::Run()+0x0000008C [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC901C] nsAppStartup::Run()+0x00000096 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01B150F6] XREMain::XRE_mainRun()+0x000016DC [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x0001181C] XREMain::XRE_main(int, char**, nsXREAppData const*)+0x000002F0 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00012060] XRE_main+0x00000046 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x000124B6] _ZL7do_mainiPPc+0x000003B7 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x00001B87] main+0x000002C9 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x00001459]

My theory... The test ("test_NPNVdocumentOrigin.html") runs quite quickly and instantiates a plugin late. In the process of instantiating the plugin we create extra (unnecessary) async instantiation events and one of them is getting run after the plugin has already instantiated successfully and the test finished. So the document is inactive because the test is done, yet we still have an outstanding async instantiate event. John Schoenick is planning to resolve the issue with the extra async instantiate events as part of his efforts in bug 745030. Assigning this to him.

Fixes a few cases where we can reach instantiation when not in an active document. We were previously checking IsInDoc() and OwnerDoc()->IsActive() in several places, but rarely both...

I should note, this lands on top of bug 745030

That doesn't look right to me at first glance. Shouldn't the following work? var obj = document.createElement("object"); obj.data = "some.gif"

Hmm. I guess it didn't use to before the refactoring either....

(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #6) > That doesn't look right to me at first glance. Shouldn't the following work? > > var obj = document.createElement("object"); > obj.data = "some.gif" What do you mean by work, in this case? nsHTMLObjectElement will fire LoadObject() after it binds to the tree. If you mean it should immediately begin loading the resource prior to being in-doc, that has never worked. In the case of plugins, it shouldn't/can't load; I'm not sure if it's desirable in other cases.

(In reply to John Schoenick [:johns] from comment #8) > If you mean it should immediately begin loading the resource prior to being > in-doc, that has never worked. In the case of plugins, it shouldn't/can't > load; I'm not sure if it's desirable in other cases. Note that with the refactoring, I don't think there's anything from stopping us from adding | || mType != eType_Plugin | to a few spots in-doc-check spots to obtain this behavior, however

> If you mean it should immediately begin loading the resource prior to being in-doc That's what I meant (for the non-plugin cases), but you're right that it never worked before, indeed.

Comment on attachment 639553 [details] [diff] [review] Don't try to instantiate plugins while not bound to tree Review of attachment 639553 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/base/src/nsObjectLoadingContent.cpp @@ +101,5 @@ > + if (!aContent->IsInDoc()) { > + return false; > + } > + nsIDocument *doc = aContent->OwnerDoc(); > + return (doc && doc->IsActive()); This null check is pointless; as its name indicates, OwnerDoc() never returns null.

Survived try: https://tbpl.mozilla.org/?tree=Try&rev=02f602af452c Pushed to m-i: http://hg.mozilla.org/integration/mozilla-inbound/rev/c20b340b1922

Comment on attachment 639553 [details] [diff] [review] Don't try to instantiate plugins while not bound to tree >+ // Sanity check >+ if (!InActiveDocument(thisContent)) { >+ NS_NOTREACHED("LoadObject called while not bound to an active document"); >+ return NS_ERROR_UNEXPECTED; >+ } So, I hit this while browsing. If I hit it again, should I file a bug? If so, what information would you like me to capture? Unfortunately all I can remember is that HttpAsyncAborter was on the stack.

Or you could wait for bug 791524 to be fixed and see if the fuzzer hits it again.