popupset crashes N610 [@ nsPopupSetFrame::DoLayout] when wrong kind of frame is placed underneath it

RESOLVED FIXED in mozilla1.1alpha

Status

()

Core
XUL
--
critical
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: Joseph Elwell, Assigned: David Hyatt)

Tracking

({crash, regression, topcrash})

Trunk
mozilla1.1alpha
x86
All
crash, regression, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
I've got a tooltip that is post-populated. up until tuesday it was working fine.
Now it crashes.

Steps to reproduce:
1) Launch commercial.
1) Login to AIM sidebar
2) Move mouse over an online buddy in the Online tab.
3) wait for tooltip.

Actual Results:
crash

Expected Results:
tooltip should popup.

Here's the stack:

#0  0x41cb8b7e in nsPopupSetFrame::DoLayout (this=0x8b384d0,
    aState=@0xbffff134) at nsPopupSetFrame.cpp:241
#1  0x41c8857c in nsBox::Layout (this=0x8b38508, aState=@0xbffff134)
    at nsBox.cpp:987
#2  0x41c8f8ac in nsSprocketLayout::Layout (this=0x8269b28, aBox=0x8b38254,
    aState=@0xbffff134) at nsSprocketLayout.cpp:405
#3  0x41c8e06c in nsContainerBox::DoLayout (this=0x8b38254, aState=@0xbffff134)
    at nsContainerBox.cpp:551
#4  0x41c9d8a9 in nsBoxFrame::DoLayout (this=0x8b3821c, aState=@0xbffff134)
    at nsBoxFrame.cpp:978
#5  0x41c8857c in nsBox::Layout (this=0x8b38254, aState=@0xbffff134)
    at nsBox.cpp:987
#6  0x41c92917 in nsStackLayout::Layout (this=0x8627770, aBox=0x8b381c4,
    aState=@0xbffff134) at nsStackLayout.cpp:255
#7  0x41c8e06c in nsContainerBox::DoLayout (this=0x8b381c4, aState=@0xbffff134)
    at nsContainerBox.cpp:551
#8  0x41c9d8a9 in nsBoxFrame::DoLayout (this=0x8b3818c, aState=@0xbffff134)
    at nsBoxFrame.cpp:978
#9  0x41c8857c in nsBox::Layout (this=0x8b381c4, aState=@0xbffff134)
    at nsBox.cpp:987
#10 0x41c9d2af in nsBoxFrame::Reflow (this=0x8b3818c, aPresContext=0x87ef620,
    aDesiredSize=@0xbffff2a8, aReflowState=@0xbffff1f0, aStatus=@0xbffff404)
    at nsBoxFrame.cpp:778
#11 0x41c86262 in nsRootBoxFrame::Reflow (this=0x8b3818c, 
    aPresContext=0x87ef620, aDesiredSize=@0xbffff2a8, 
    aReflowState=@0xbffff1f0, aStatus=@0xbffff404) at nsRootBoxFrame.cpp:208
#12 0x41b65d05 in nsContainerFrame::ReflowChild (this=0x8b38150, 
    aKidFrame=0x8b3818c, aPresContext=0x87ef620, aDesiredSize=@0xbffff2a8, 
    aReflowState=@0xbffff1f0, aX=0, aY=0, aFlags=0, aStatus=@0xbffff404)
    at nsContainerFrame.cpp:695
#13 0x41bc7b87 in ViewportFrame::Reflow (this=0x8b38150, 
    aPresContext=0x87ef620, aDesiredSize=@0xbffff4cc, 
    aReflowState=@0xbffff354, aStatus=@0xbffff404) at nsViewportFrame.cpp:543
#14 0x41b7f615 in nsHTMLReflowCommand::Dispatch (this=0x8be19d0, 
    aPresContext=0x87ef620, aDesiredSize=@0xbffff4cc, aMaxSize=@0xbffff4bc, 
    aRendContext=@0x8bdabf8) at nsHTMLReflowCommand.cpp:144
#15 0x41bad5cb in PresShell::ProcessReflowCommand (this=0x8804f28, 
    aQueue=@0x8804f74, aAccumulateTime=1, aDesiredSize=@0xbffff4cc, 
    aMaxSize=@0xbffff4bc, aRenderingContext=@0x8bdabf8) at nsPresShell.cpp:5247
#16 0x41bad861 in PresShell::ProcessReflowCommands (this=0x8804f28, 
    aInterruptible=1) at nsPresShell.cpp:5302
#17 0x41d02629 in ReflowEvent::HandleEvent (this=0x8be1a08)
    at nsPresShell.cpp:5158
#18 0x41bad311 in HandlePLEvent (aEvent=0x8be1a08) at nsPresShell.cpp:5174
#19 0x4012c51b in PL_HandleEvent (self=0x8be1a08) at plevent.c:586
#20 0x4012c32c in PL_ProcessPendingEvents (self=0x80b1208) at plevent.c:516
#21 0x4012e4b9 in nsEventQueueImpl::ProcessPendingEvents (this=0x80b11e0)
    at nsEventQueue.cpp:361
#22 0x408062f4 in event_processor_callback (data=0x80b11e0, source=8,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:168
#23 0x40805edf in our_gdk_io_invoke (source=0x820e710, condition=G_IO_IN,
    data=0x82255d0) at nsAppShell.cpp:61
 #24 0x409d34ba in g_io_unix_dispatch (source_data=0x820e728,
    current_time=0xbffff694, user_data=0x82255d0) at giounix.c:135
#25 0x409d49f6 in g_main_dispatch (dispatch_time=0xbffff694) at gmain.c:656
#26 0x409d4fb1 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#27 0x409d5129 in g_main_run (loop=0x8226068) at gmain.c:935
#28 0x408fcd69 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#29 0x408069ea in nsAppShell::Run (this=0x80b9f28) at nsAppShell.cpp:360
#30 0x405dc114 in ?? () from /builds/ns/dist/bin/components/libnsappshell.so
#31 0x8056dab in main1 (argc=1, argv=0xbffff954, nativeApp=0x0)
    at nsAppRunner.cpp:1004
#32 0x8057a9a in main (argc=1, argv=0xbffff954) at nsAppRunner.cpp:1298
#33 0x403889cb in __libc_start_main (main=0x80578ac <main>, argc=1,
    argv=0xbffff954, init=0x8051920 <_init>, fini=0x80661ac <_fini>,
    rtld_fini=0x4000aea0 <_dl_fini>, stack_end=0xbffff94c)
    at ../sysdeps/generic/libc-start.c:92
(Reporter)

Comment 1

17 years ago
this is a stop ship bug. sprinkling with keywords.
Keywords: crash, mozilla0.8.1, mozilla0.9, nsbeta1, nsCatFood, nsdogfood, regression
(Reporter)

Comment 2

17 years ago
Hyatt: here is a good reason you should be adhereing to the Netscape rules of
checkin and development. If you're not running the full product, and merely a
subset - then the product as a whole suffers. Try to make a stronger effort to
run the netscape client - that which you are paid to do. If you want any help, I
will certainly help you - and I mean no ill will. I *really* would like to help.
I want our product to succeed.

The line of code that causes this crash is:
this.mTooltip.setAttribute("style", "display: block");
Assignee: trudelle → hyatt
(Reporter)

Comment 3

17 years ago
I have a patch for the workaround, which is to use the new visibility: visible
Keywords: mozilla0.8.1, mozilla0.9, nsbeta1, nsCatFood, nsdogfood
(Assignee)

Updated

17 years ago
Assignee: hyatt → jelwell
(Assignee)

Comment 4

17 years ago
The offending line in question is completely bizarre.  What are you even trying
to do with this line?  Why are you using display types to manipulate a tooltip's
visibility?

Popups now have a display type of -moz-xul-popup.  You should never have needed
to refer to a popup's specific display type in your code, and to do so was
really odd in the first place.

The attributes "hidden" and "collapsed" are available to toggle between display:
none and visibility: collapsed respectively.  They should be used rather than
setting an inline style attribute that manipulates display directly.  Everyone
else does this correctly (with one exception in wallet, which was equally bad),
and so they weren't victimized by my checkin.

While I'm all for running the commercial product, it is AIM's arcane and quirky
use of CSS and XUL that continually makes it a victim.  The toolkit admittedly
shouldn't crash when subjected to oddities like a block frame inside a popupset,
but these crashes are usually signs that something bizarre or incorrect has been
done in the CSS or XUL.

Reassigning to AIM, who should correct their code to not use display types. 
If/when you've made this correction, we can then look at the popupset's crash
when the wrong kind of frame is placed underneath it.

(Reporter)

Comment 5

17 years ago
i've already got a patch to change the code to use visibility: hidden. Let's
look at why this regression crash occurs.

In AIM's defense Joe Hewitt wrote the line of code that used display: block -
fairly recently, but before the change to -moz-xul-popup.
Assignee: jelwell → hyatt
Summary: tooltips crashing → popupset crashes when wrong kind of frame is placed underneath it
you never addressed hyatt's original question: why are you doing this at all? 
what about the toolkit is deficient to the point where you have to go hacking? if 
we better understood that, this bug wouldn't be here at all.
(Assignee)

Comment 7

17 years ago
Moving to 1.1.  Popupset is slated for elimination, which in the end will make
this bug irrelevant.

Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1

Comment 8

17 years ago
Adding topcrash keyword and N610 [@ nsPopupSetFrame::DoLayout] to summary since
Talkback data shows this as topcrasher for Netscape 6.10 RTM.  Here is some N610
data:

nsPopupSetFrame::DoLayout   208 
     First BBID :33795456
     Last BBID  :34027791
     Min Runtime :5
     Max Runtime :3972
     First Appearance Date : 2001-08-06
     Last Appearance Date : 2001-08-12
     First BuildID : 2001072700
     Last BuildID : 2001072700

Stack Trace: 

	 nsPopupSetFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsPopupSetFrame.cpp  line 242]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 985]
	 nsSprocketLayout::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp  line 421]
	 nsContainerBox::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 553]
	 nsBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 979]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 985]
	 nsStackLayout::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsStackLayout.cpp  line 256]
	 nsContainerBox::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 553]
	 nsBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 979]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 985]
	 nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 781]
	 nsRootBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsRootBoxFrame.cpp  line 215]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 747]
	 ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 538]
	 nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp  line 145]
	 PresShell::ProcessReflowCommand
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5767]
	 PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5822]
	 ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5680]
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 591]
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 524]
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1072]
	 nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 426]
	 netscp6.exe + 0x16f0 (0x004016f0)
	 netscp6.exe + 0x11b8 (0x004011b8)
	 netscp6.exe + 0x3397 (0x00403397)
	 KERNEL32.DLL + 0x7903 (0x77e87903)
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsPopupSetFrame.cpp
line : 242

A lot of the comments mention a startup crash, but there are a lot of user
comments and urls, too many to list here, so I'm going to attach them.  Looking
at the OS breakdown, this seems to be mostly an issue with Win2k:

116 Windows NT  5.0 build 2195
57 Windows NT  4.0 build 1381
2 Windows NT  5.1 build 2463
1 Windows NT  5.1 build 2509
1 Windows NT  5.1 build 2505
Keywords: topcrash
Summary: popupset crashes when wrong kind of frame is placed underneath it → popupset crashes N610 [@ nsPopupSetFrame::DoLayout] when wrong kind of frame is placed underneath it

Comment 9

17 years ago
Created attachment 46010 [details]
user comments and urls for nsPopupSetFrame::DoLayout crashes with N610
(Assignee)

Comment 10

17 years ago
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsPopupSetFrame::DoLayout]
You need to log in before you can comment on or make changes to this bug.