nemo Reporter
	Description • 15 years ago

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.

	Benjamin Smedberg
	Comment 1 • 15 years ago

What OS?

	nemo Reporter
	Comment 2 • 15 years ago

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.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Assignee
	Comment 3 • 15 years ago

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 = http://www.freewebarcade2.info/media/ricochet-kills.swf]


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.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Assignee
	Comment 4 • 15 years ago

The bug is gone in
http://hg.mozilla.org/projects/electrolysis/rev/482029a3e147, but manifests in
http://hg.mozilla.org/projects/electrolysis/rev/1be234301318, according to
Karl.  So removing XPCOM from plugin processes definitely caused this.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Assignee
	Comment 5 • 15 years ago

Pushed http://hg.mozilla.org/projects/electrolysis/rev/e5c03e24fe58

This ended up being the underlying issue as in bug 544882, so I'm going to DUP when I really mean RESOLVED SUBSUMED.

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 6 • 15 years ago

Verified duplicate.