win 0529 Tests on this page do not load flash movies. Only text loads.
ok, just tested on mac 0529 and this does crash trying to load the above page. Changing sunnary, OS.stack trace coming....
OS: Windows NT → Mac System 9.x
Summary: flash movies don't load from HTML parameter test suite → Browser crashes load from HTML parameter test suite
stack : Call Stack: (Signature = 0x7c0802a4 a3e922e1) 0x7c0802a4 nsPluginInstanceOwner::Paint() [nsObjectFrame.cpp, line 2856] nsObjectFrame::Paint() [nsObjectFrame.cpp, line 1350] PresShell::Paint() [nsPresShell.cpp, line 5245] VIEW_DLL + 0x6d6c (0x1575372c) VIEW_DLL + 0x16394 (0x15762d54) VIEW_DLL + 0x16100 (0x15762ac0) VIEW_DLL + 0x14c3c (0x157615fc) VIEW_DLL + 0x17d04 (0x157646c4) VIEW_DLL + 0x6510 (0x15752ed0) nsWindow::DispatchEvent() [nsWindow.cpp, line 1959] nsWindow::DispatchWindowEvent() [nsWindow.cpp, line 1980] nsWindow::UpdateWidget() [nsWindow.cpp, line 1631]
Summary: Browser crashes load from HTML parameter test suite → Browser crashes when trying to load html parameter test on mac
I'm not seeing this on Win2K. Moving to m0.9.3.
Target Milestone: --- → mozilla0.9.3
Hardware: PC → Macintosh
Shrirang, Is this still happening? I haven't seen it on talkback. adding qawanted. Anyway, I'm probably not going to get to this today, so moving to mozilla0.9.4
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → mozilla0.9.4
This is currently on the top crash list for NS 6.1 Mac. Talkback incident is 33903022. URL http://www.whirlgirl.com/html/index.html The problem is that when nsPluginInstanceOwner::CreateWidget() gets called to create the plugin widget, the nsObjectFrame already has a nsIView. This causes it to skip the code which allocates the plugin widget. This causes it to crash in nsPluginInstanceOwner::Paint() when it calls GetWidgetPositionAndClip() which relies on mWidget being vaild. Peter believes this is due to the use of "document.write" to create the plugin (Flash in this case) instance.
Keywords: crash → nsenterprise, topcrash
I think replacing that code in Paint() with a call to FixUpPluginWindow() may work.
This patch cleans things up a bit by having Paint() also go through FixUpPluginWindow() and therefore prevent the crash. I'm seeking reviews.
Priority: -- → P1
Whiteboard: [seeking reviews]
Note: The testcase still does not work (on ANY platform) due to STYLE="POSITION: relative;" on the EMBED. I think this is bug 71813.
Not that I disagree with the patch (I've thought about suggesting the same thing a dozen times), but it will simply eliminate the crash by never determining where the object should be placed. I'm not sure that's the right approach here. Can the plugin even work without mWidget being valid?
I think that last patch fixes the root of the problem with mWidget as Brian described.
Yes, much better. Let's land this ASAP. r=bnesse.
Patch checked into the trunk, marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
yeah..verif fixed on trunk 0821. no crash.
Status: RESOLVED → VERIFIED
per eclient triage removing nsenterprise keyword
You need to log in before you can comment on or make changes to this bug.