Closed Bug 545312 Opened 14 years ago Closed 14 years ago

Flash game fails to load with OOPP enabled


(Core Graveyard :: Plug-ins, defect)

Not set


(Not tracked)



(Reporter: bugs, Assigned: cjones)




Shockwave Flash 10.0 r42

Hangs a lot in loading w/ OOPP enabled (could be my imagination but other tabs seem a lot slower to load while it is active too), but never gets beyond loading.

Disabling OOPP causes it to load perfectly.  Does seem to contact a bunch of remote servers, and this seems slower, don't know if that's related.
What OS?
Blocks: OOPP
x86 linux as noted in the filing, but more specifically, Ubuntu Karmic.

BTW, most flash seems to take up a lot more CPU than it used to, for example, playing an audio sample on google voice maxes out one core even after the sample is done playing, until I close the google voice tab.

Shame they don't offer <audio> tag except in their iphone version.
Assignee: nobody → jones.chris.g
On my machine, loading the applet doesn't "hang" in the sense of locking up; firefox and flash stay responsive throughout.  However, the applet stops painting after a short period of time.  Sometimes it gets further along than other times; once it loaded to the point where a button was painted, and mousing over the button worked.

Log data that looks relevant to gfx

nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1
nsPluginNativeWindowGtk2: call SetWindow with xid=0x4e001af
371206144[7fb009f12040]: NPError mozilla::plugins::PluginInstanceParent::NPP_SetWindow(const NPWindow*) (aWindow=7faff7931988)
[time:1265845702655162][PPluginInstanceParent] Sending Msg_NPP_SetWindow()
[time:1265845702655267][PPluginInstanceChild] Received Msg_NPP_SetWindow()
-1429632752[b7ded0]: virtual bool mozilla::plugins::PluginInstanceChild::AnswerNPP_SetWindow(const mozilla::plugins::NPRemoteWindow&, NPError*) (aWindow=<window: 0x4e001af, x: 0, y: 0, width: 1920, height: 906>)
-1429632752[b7ded0]: NPError mozilla::plugins::child::_getvalue(NPP_t*, NPNVariable, void*)
[time:1265845702655299][PPluginModuleChild] Sending Msg_NPN_GetValue_WithBoolReturn()
[time:1265845702655350][PPluginModuleParent] Received Msg_NPN_GetValue_WithBoolReturn()
[time:1265845702655359][PPluginModuleParent] Sending reply Reply_NPN_GetValue_WithBoolReturn()
[time:1265845702655427][PPluginModuleChild] Received reply Reply_NPN_GetValue_WithBoolReturn()

(<unknown>:28898): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed

The assertion failure is tracked in bug 539138, but I'm not sure it's relevant.  

Just before the applet stops repainting, I see

[time:1265846332124711][PBrowserStreamChild] Received Msg_NPP_Write()
-1429632752[b7ded0]: virtual bool mozilla::plugins::BrowserStreamChild::AnswerNPP_Write(const int32_t&, const mozilla::plugins::Buffer&, int32_t*) (offset=753664, data.length=11950)
[time:1265846332124866][PBrowserStreamChild] Sending reply Reply_NPP_Write()
[time:1265846332124973][PBrowserStreamParent] Received reply Reply_NPP_Write()
371206144[7fb009f12040]: NPError mozilla::plugins::PluginInstanceParent::NPP_DestroyStream(NPStream*, NPReason) (stream=7faff95f6648, reason=0)
[time:1265846332125032][PBrowserStreamParent] Sending Msg___delete__()
[time:1265846332125105][PBrowserStreamChild] Received Msg___delete__()
-1429632752[b7ded0]: void mozilla::plugins::BrowserStreamChild::NPP_DestroyStream(NPError) (reason=0)
[time:1265846332125138][PBrowserStreamChild] Sending reply Reply___delete__()
[time:1265846332125249][PBrowserStreamParent] Received reply Reply___delete__()
--DOMWINDOW == 11 (0x7faffabb7858) [serial = 24] [outer = 0x7faffdb15000] [url =]

I don't see any other information in the log that indicates what might be failing.  Two weak hypotheses: (i) the stream dtor is behaving differently than for IPP, and flash never thinks the applet has finished downloading. (ii) flash is making a platform API call that throws or returns an error, and the applet is dying because of that (like an uncaught exception in JS).  I can test (i) without too much pain, (ii) is harder.
The bug is gone in, but manifests in, according to
Karl.  So removing XPCOM from plugin processes definitely caused this.
Blocks: 516515

This ended up being the underlying issue as in bug 544882, so I'm going to DUP when I really mean RESOLVED SUBSUMED.
Closed: 14 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.