83155 - Browser crashes when trying to load html parameter test on mac

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[shrirang khanzode]

win 0529

Tests on this page do not load flash movies. Only text loads.

Comment 1

[shrirang khanzode]

ok, just tested on mac 0529 and this does crash trying to load the above page. 
Changing sunnary, OS.stack trace coming....

Comment 2

[shrirang khanzode]

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]

Comment 3

[karnaze (gone)]

I'm not seeing this on Win2K. Moving to m0.9.3.

Comment 4

[basic]

Changing platform

Comment 5

[Peter Lubczynski]

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

Comment 6

[Brian Nesse (gone)]

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.

Comment 7

[Peter Lubczynski]

I think replacing that code in Paint() with a call to FixUpPluginWindow() may work.

Comment 8

[Peter Lubczynski]

Attachment: patch to fix crash, v.1

Comment 9

[Peter Lubczynski]

This patch cleans things up a bit by having Paint() also go through
FixUpPluginWindow() and therefore prevent the crash. I'm seeking reviews.

Comment 10

[Peter Lubczynski]

Note: The testcase still does not work (on ANY platform) due to STYLE="POSITION:
relative;" on the EMBED. I think this is bug 71813.

Comment 11

[Brian Nesse (gone)]

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?

Comment 12

[Peter Lubczynski]

Attachment: much better patch (making testcase work) v.2

Comment 13

[Peter Lubczynski]

I think that last patch fixes the root of the problem with mWidget as Brian
described.

Comment 14

[Brian Nesse (gone)]

Yes, much better. Let's land this ASAP.
r=bnesse.

Comment 15

[Chris Waterson]

sr=waterson

Comment 16

[Peter Lubczynski]

Patch checked into the trunk, marking FIXED.

Comment 17

[shrirang khanzode]

yeah..verif fixed on trunk 0821. no crash.

Comment 18

[Jeff Hooker]

per eclient triage removing nsenterprise keyword