133219 - Browser crash when selecting alternate style sheet on libpr0n.com - M17x [@ GetNearestContainingBlock]

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Tet]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020415

When swithcing stylesheets on the above URL, the browser crashes.
Switch from the default Green style to Blue, and it all works fine.
However, on switching back to Green again, the browser dies.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.libpr0n.com
2. View -> Use Stylesheet -> Blue
3. View -> Use Stylesheet -> Green

Actual Results:  Browser crash

Expected Results:  No crash...

Talkback ID: TB4437493H

Comment 1

[Frederic Bezies]

Having this bug too.

Build ID : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020324

Sent Talkback ID : TB4437809Z

Comment 2

[Olivier Cahagne]

Stephen, can you retreive Talkback data please: TB4437493H or TB4437809Z ?

Comment 3

[Russell Odom]

Confirmed on W2K 2002032203. However, I'm still having problems with getting
Talkback to send the incident to the server.

Comment 4

[Artur Polaczynski]

confirm on build 2002032406
TB4440361W
Linux 

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

FindPreviousSibling()
nsCSSFrameConstructor::ContentInserted()
nsCSSFrameConstructor::RecreateFramesForContent()
nsCSSFrameConstructor::ProcessRestyledFrames()
PresShell::ReconstructStyleData()
PresShell::StyleSheetDisabledStateChanged()
nsDocument::SetStyleSheetDisabledState()
CSSStyleSheetImpl::SetDisabled()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_GetterSetter()
js_Invoke()
js_InternalInvoke()
js_SetProperty()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleDOMEventWithTarget()
nsMenuFrame::Execute()
nsMenuFrame::HandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x40361d7f)
libglib-1.2.so.0 + 0x11773 (0x40395773)
libglib-1.2.so.0 + 0x11d39 (0x40395d39)
libglib-1.2.so.0 + 0x11eec (0x40395eec)
libgtk-1.2.so.0 + 0x94333 (0x402b0333)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c507 (0x404db507) 

Comment 6

[Markus Gerstel]

Bug 134520 may or may not be related

Comment 7

[Doron Rosenberg (IBM)]

here's a differnt stack,one that I get:

ChildIterator::get [nsChildIterator.h, line 106]
nsCSSFrameConstructor::FindPreviousSibling [nsCSSFrameConstructor.cpp, line 8018]
nsCSSFrameConstructor::ContentInserted [nsCSSFrameConstructor.cpp, line 8860]
nsCSSFrameConstructor::RecreateFramesForContent [nsCSSFrameConstructor.cpp, line
12255]
nsCSSFrameConstructor::ProcessRestyledFrames [nsCSSFrameConstructor.cpp, line 10358]
PresShell::ReconstructStyleData [nsPresShell.cpp, line 5505]
PresShell::StyleSheetDisabledStateChanged [nsPresShell.cpp, line 5553]
nsDocument::SetStyleSheetDisabledState [nsDocument.cpp, line 1672]
CSSStyleSheetImpl::SetDisabled [nsCSSStyleSheet.cpp, line 2685]
XPTC_InvokeByIndex [xptcinvoke.cpp, line 106]
XPCWrappedNative::CallMethod [xpcwrappednative.cpp, line 1996]
XPC_WN_GetterSetter [xpcwrappednativejsops.cpp, line 1291]
js_Invoke [jsinterp.c, line 790]
js_InternalInvoke [jsinterp.c, line 881]
js_SetProperty [jsobj.c, line 2614]
js_Interpret [jsinterp.c, line 2586]
js_Invoke [jsinterp.c, line 806]
js_InternalInvoke [jsinterp.c, line 881]
JS_CallFunctionValue [jsapi.c, line 3426]
nsJSContext::CallEventHandler [nsJSEnvironment.cpp, line 1045]
nsJSEventListener::HandleEvent [nsJSEventListener.cpp, line 184]
nsEventListenerManager::HandleEventSubType [nsEventListenerManager.cpp, line 1222]
nsEventListenerManager::HandleEvent [nsEventListenerManager.cpp, line 2221]
nsXULElement::HandleDOMEvent [nsXULElement.cpp, line 3447]
nsXULElement::HandleDOMEvent [nsXULElement.cpp, line 3466]
nsXULElement::HandleDOMEvent [nsXULElement.cpp, line 3466]
nsXULElement::HandleDOMEvent [nsXULElement.cpp, line 3466]
nsXULElement::HandleDOMEvent [nsXULElement.cpp, line 3466]
PresShell::HandleDOMEventWithTarget [nsPresShell.cpp, line 6171]
nsMenuFrame::Execute [nsMenuFrame.cpp, line 1684]
nsMenuFrame::HandleEvent [nsMenuFrame.cpp, line 466]
PresShell::HandleEventInternal [nsPresShell.cpp, line 6140]
PresShell::HandleEvent [nsPresShell.cpp, line 6046]
nsViewManager::HandleEvent [nsViewManager.cpp, line 2076]
nsView::HandleEvent [nsView.cpp, line 306]
nsViewManager::DispatchEvent [nsViewManager.cpp, line 1887]
HandleEvent [nsView.cpp, line 83]
nsWindow::DispatchEvent [nsWindow.cpp, line 973]
nsWindow::DispatchWindowEvent [nsWindow.cpp, line 990]
nsWindow::DispatchMouseEvent [nsWindow.cpp, line 4836]
ChildWindow::DispatchMouseEvent [nsWindow.cpp, line 5091]
nsWindow::ProcessMessage [nsWindow.cpp, line 3738]
nsWindow::WindowProc [nsWindow.cpp, line 1235]
USER32.DLL + 0x1b60 (0x77e11b60)
USER32.DLL + 0x1cca (0x77e11cca)
USER32.DLL + 0x83f1 (0x77e183f1)
nsAppShellService::Run [nsAppShellService.cpp, line 451]
main1 [nsAppRunner.cpp, line 1472]
main [nsAppRunner.cpp, line 1808]
WinMain [nsAppRunner.cpp, line 1826]
WinMainCRTStartup()
KERNEL32.DLL + 0xd326 (0x77e8d326) 

Comment 8

[Jason Chambers]

I just thought i make a comment that going from green to basic, back to green
again works, but when you touch blue than green with a 10 foot poll, better run!

Comment 9

[Jan Carpenter]

Topcrash on M1RC3 & N70PR1.  
Adding M1RC3 & N70PR1 to summary for tracking, and adding topcrash+ to keywords.  
Adding a talkback folks to CC list.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack trace of assertion preceding crash

This stack trace shows an assertion preceding the crash.  The pair of iterators
in question have |mNodes| member variables that only have a range of 2 (two
nsXBLInsertionPoints in the nsAnonymousContentList, each with one element).

It seems to me that doing a seek in the child list based on the index of the
content node in the container is invalid when the child list is an anonymous
content list rather than a real content list.

Comment 11

[Chris Waterson]

Yes, that sounds right. I think hyatt and I discussed the approach here, and
there were some shortcomings with anonymous content.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This code was added for bug 84645.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: a likely fix that (surprisingly) causes regressions

I was hoping this would fix the crash.	It probably will, since it eliminates
what seems to me to be an invalid use of an index -- for indexing into an array
into which it is not an index.	I expected that this change wouldn't cause any
user-visible effects, but instead it causes the Home button on the personal
toolbar to appear on the right.  (I don't see anything else wrong with the
navigator window.)

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmm.  Now that I look more closely, the |aContainer| should be the insertion
point, not the content tree parent.  So never mind...

Comment 15

[Madhur Bhatia]

nominating for nsbeta1 , since this is reproducable on branch 

talkback incident id 7275846

Comment 16

[greer]

Summary change so that this bug shows up in the Talkback reports.

Comment 17

[Jay Patel [:jay]]

Adding testcase keyword since Madhur was able to reproduce this.

Comment 18

[Jaime Rodriguez, Jr.]

we should and fix this for 1.0.1. nsbeta1+/adt2.

any idea on how soon, we might have a patch for this one?

Comment 19

[timeless]

Attachment: simplistic patch

here's all i know:
  already_AddRefed<nsIContent> get() const {
    nsIContent* result = nsnull;
    if (mNodes) {
      nsCOMPtr<nsIDOMNode> node;
      mNodes->Item(mIndex, getter_AddRefs(node));
=>    CallQueryInterface(node, &result);
    }
    else 
      mContent->ChildAt(PRInt32(mIndex), result);
    return result;
  }

-	node	{...}
\-	nsCOMPtr_base	{...}
 \+	mRawPtr 0x00000000

synopsis of caller behavior:
  while (iter-- != first) {
    nsIFrame* prevSibling = nsnull;
=>  aPresShell->GetPrimaryFrameFor(nsCOMPtr<nsIContent>(*iter), &prevSibling);
    if (prevSibling) {
      return prevSibling;
    }
  }
  return nsnull;

my patch makes the following assertions:
1. ChildIterator::get is allowed to return null (and is even expected to do so
by some callers)
2. ChildIterator::get shouldn't crash
3. the patch itself is simple and easy to review 
4. dbaron claims this is called a lot, and suggests we fix seek() instead of
get().
5. the fix to seek would be a few more lines and would be called less often,
but based on 6 and the fact that dbaron will fix the caller eventually I think
that this patch is good enough for now (if not forever)
6. dbradley ran some numbers for me

this patch cost Less than one microsecond for the startup and launch of the
page ( w3.org/style )
44.57 microseconds before the test, 45.01 microseconds after the test
that time is across 1187 invocations of the function
Individual time for the function wasn't measurable by Quantify
You're probably talking about half a nanosecond per call increase when it takes
that path
But that increase is about 1% for the function
And of course your mileage may vary depending on platform

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 89103 [details] [diff] [review]
simplistic patch

As I said to timeless on IRC, the correct "workaround" for this crash would be
to change seek, not get.  I'll attach a patch to do that later today if I can't
make any progress on a real fix.

Comment 21

[timeless]

Attachment: what i think dbaron meant by correct workaround

i'm confused by the assert change i made. I made it because it felt correct.
Did I miss something (it's mid afternoon, so i doubt i'm asleep)

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Are there any reproducable testcases for this crash other than
http://www.libpr0n.com/ ?

Comment 23

[greer]

Updating the summary to current crashing releases. Adding alternate Linux signature.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: correct workaround

This might just move the crash elsewhere (it did on the one reproducable
testcase).  (And then the stack will be even harder to trace back to the bug.)

Comment 25

[Chris Waterson]

Comment on attachment 90394 [details] [diff] [review]
correct workaround

sr=waterson

Comment 26

[kinmoz]

Comment on attachment 90394 [details] [diff] [review]
correct workaround

r=[e-mail]

Comment 27

[Jaime Rodriguez, Jr.]

David: Should you believe this is a good and needed fix for the branch, pls add
the adt1.0.1 nomination. Thanks!

Comment 28

[Asa Dotzler [:asa]]

Comment on attachment 90394 [details] [diff] [review]
correct workaround

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 90394 [details] [diff] [review]
correct workaround

This fix checked in to trunk, 2002-07-16 07:53 PDT.

Comment 30

[Jay Patel [:jay]]

This has been a top 15 crasher for Mozilla 1.0 and Netscape 7.0 PR1, so it would
be great to get this onto the Gecko1.0 Branch.

David:  How risky is this patch?  Do we know where this crash might move to with
your checkin?  I guess we'll have to look closely at Talkback data to see what
happens...

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch is low-risk.

Comment 32

[scottputterman]

adding adt1.0.1+.  Please get drivers approval before checking into the branch.

Comment 33

[Brendan Eich [:brendan]]

dbaron, please get this fix into the branch too, as soon as you think it's ready.

/be

Comment 34

[Jacob Kjome]

Was the patch supposed to fix the crash on libpr0n?  It doesn't.

I'm using trunk build 2002071708 on win2k (sp2sr1).  The patch went in yesterday
morning so, it is pretty much guaranteed to be in the build I am testing.

Here is the talkback ID: TB8410315Z

Jake

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, it moves the crash on http://www.libpr0n.com/ elsewhere.  It may or may not
fix other reported instances of the bug.

Comment 36

[greer]

Attachment: Jake's stack for incident 8410315

signature: GetNearestContainingBlock

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 90394 [details] [diff] [review]
correct workaround

Checked in to MOZILLA_1_0_BRANCH, 2002-07-17 14:37 PDT.

I'd be interested to see the talkback data from the trunk at some point to see
if another crash popped up to replace this one.  They're not currently getting
pushed to the FTP site...

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking as fixed1.0.1, even though what landed is only a potential fix, and
doesn't really fix the one known testcase (although it does move the crash
elsewhere).

Comment 39

[Madhur Bhatia]

tested http://www.libpr0n.com on the following builds:

linux 
=====
2002-07-18-07-1.0 branch
2002-07-19-08trunk

macos10.1
=========
2002-07-19-03trunk
2002-07-19-05-1.0branch

win2000
=======
2002-07-19-08-1.0branch
2002-07-19-04trunk


for all the platforms, I changed the style sheet in the following sequence and
got the same result:-

green -> blue -> basic page style -> green [NO CRASH SEEN ]
green -> basic page style -> green [NO CRASH SEEN ]
green -> blue -> green [I GET A CRASH HERE]


incident ID 8563237

Comment 40

[Madhur Bhatia]

based on my above comment 39, i am removing the fixed1.0.1 keyword.

This bug still exists.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I know that.  See comment 38.  Removing the various +es as well.  Any ideas if
the new stack that shows up on http://www.libpr0n.com/ has shown up in talkback
top crashes as well, to replace the ChildIterator::get crashes, or whether the
workaround fixed some of the incidents?

Comment 42

[ly nguyen]

it's crashing on this now with today's trunk build:
GetNearestContainingBlock

waiting for climate to get back to me....

Comment 43

[ly nguyen]

look at comment #36 for a stack trace. looks like _this_ sig has been occuring
for a while since 6.10. i randomly chose two incidents and the stacks look very
similar (the top portion is identical while the bottom portion varies...perhaps
code changing)

Comment 44

[Andrew Schultz]

Attachment: reduced testcase

crashes linux build 20020721 going Blue->Green. same stack as the URL. 
switching Blue and Green so that Blue is default "fixes" the testcase (no crash
going Blue->Green or Green->Blue)

debug build says (for the testcase):
Wrong parent style context:  style: 0x872c850 :-moz-cell-content {}
should be using:  style: 0x877a080 :-moz-cell-content {}
###!!! ASSERTION: unsupported operation: 'PR_FALSE', file nsTableCellFrame.cpp,
line 278

Comment 45

[Jaime Rodriguez, Jr.]

cathleen: is there any one that can pick this one up, in david's absence?

Comment 46

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did anyone look to see if the new signature showed up in the talkback data with
the same frequency as the old one?

Comment 47

[ly nguyen]

Greer sent me this:
M11A (GetNearestContainingBlock):        0
 Unique Users  0
M11B (GetNearestContainingBlock):        1
 Unique Users  1
M1BR (GetNearestContainingBlock):        0
 Unique Users  0
M100 (GetNearestContainingBlock):        0
 Unique Users  0
Trunk (GetNearestContainingBlock):        2
 Unique Users  2

i found out this from today's talkback reports:
3 incidents (FindPreviousSibling) M11A on Lin
3 incidents (FindPreviousSibling) PR1 on Lin
52 incidents (get) PR1 on Win

Comment 48

[Andrew Schultz]

Attachment: stack for the assertion

###!!! ASSERTION: unsupported operation: 'PR_FALSE', file nsTableCellFrame.cpp,
line 278

Comment 49

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So I'm guessing the topcrash part is fixed, but the rest isn't?

Comment 50

[rbs]

Looks like patch in bug 123049 fixes these issues.

Comment 51

[rbs]

-> fixed

Comment 52

[Madhur Bhatia]

Tested the url mentioned -- http://www.libpr0n.com/
still getting a crash on win XP with trunk build 2003-01-27-09-trunk 

changed style sheet from 
green -> blue -> green (got  a  crash )
same scenario as mentioned in comment 39


Incident ID : 16627115

Stack Signature : gklayout.dll + 0x2596f (0x0162596f) 7369d124

re-opening bug 

Comment 53

[Olivier Cahagne]

Attachment: Stack trace Linux 20030125 (CVS)

also crashing using a debug build 20030125 on Linux:

0x40d5449c in GetNearestContainingBlock (aFrame=0x8ac548c,
    aContentArea=@0xbfff9b5c) at nsHTMLReflowState.cpp:600
600	    aFrame->GetFrameType(&frameType);

Comment 54

[Jan Carpenter]

marking topcrash+ since there's a testcase for this.

Comment 55

[Andrew Schultz]

I'm not sure how this can be a topcrash when the current stack signature
(GetNearestContainingBlock) and even the old stacks do not show up in the trunk
topcrash list:
http://ftp.mozilla.org/pub/data/crash-data/Trunk-topcrashers.html

Comment 56

[Boris Zbarsky [:bzbarsky]]

So.. I see basically the same stack as Olivier .  The relevant part is:



(gdb) frame 0
#0  0x40e8a7e2 in GetNearestContainingBlock (aFrame=0x88db078,
aContentArea=@0xbfff96a4)
    at
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsHTMLReflowState.cpp:600
600         aFrame->GetFrameType(&frameType);
(gdb) p *aFrame
$3 = {<nsISupports> = {_vptr. = 0x0}, mRect = {x = -572662307, y = -572662307, 
    width = -572662307, height = -572662307}, mContent = 0xdddddddd, 
  mStyleContext = 0xdddddddd, mParent = 0xdddddddd, mNextSibling = 0xdddddddd, 
  mState = 3722304989}

For some reason we're incrementally reflowing the kid of a deleted frame....

Comment 57

[Jan Carpenter]

There are no incident reports for nsCSSFrameConstructor::FindPreviousSibling in
talkback at all.  And only 2 old reports from this year for ChildIterator::get,
most recently in early march.  FindPreviousSibling has only 1 report from this
year (in feb.) 

Soooooo....
Marking this worksforme.

Comment 58

[Olivier Cahagne]

Maybe this is not a topcrash anymore, however I still crash using Linux Mozilla
built 5 minutes ago (CVS).

Comment 59

[Jan Carpenter]

Reopening based on Comment #58.
Marking topcrash-
(Thanks Olivier!)

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This bug has covered two problems.  It was originally filed for a crash on
http://www.libpr0n.com/ , and that is what it currently covers.  There used to
be a topcrash that had the same signature as the stack of the crash on
http://www.libpr0n.com/.  However, they were separate problems, and a patch has
been checked in that works around the problem causing the topcrash (for which no
reproducable testcases were ever known).

Do not mark this bug worksforme or fixed because the topcrash has gone away. 
This bug is about what is described in comment 0.

Comment 61

[Madhur Bhatia]

Incident ID : 19179302

Stack Signature  	GetNearestContainingBlock d71a4d5a
Operating System 	Windows NT 5.1 build 2600
Module 	                gklayout.dll
Source File Name 
c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
Trigger Line No. 	602

Stack Trace  
	
GetNearestContainingBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 602]
nsHTMLReflowState::InitAbsoluteConstraints
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 987]
nsHTMLReflowState::InitConstraints
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 1987]
nsHTMLReflowState::Init
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 338]
nsHTMLReflowState::nsHTMLReflowState
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 310]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsAbsoluteContainingBlock.cpp,
line 480]
nsAbsoluteContainingBlock::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsAbsoluteContainingBlock.cpp,
line 249]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 1105]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 943]
CanvasFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLFrame.cpp, line 589]
nsBoxToBlockAdaptor::Reflow
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 905]
nsBoxToBlockAdaptor::DoLayout
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 647]
nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1073]
nsScrollBoxFrame::DoLayout
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp, line 360]
nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1073]
nsContainerBox::LayoutChildAt
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsContainerBox.cpp, line 654]
nsGfxScrollFrameInner::LayoutBox
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1174]
nsGfxScrollFrameInner::Layout
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1333]
nsGfxScrollFrame::DoLayout
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1182]
nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1073]
nsBoxFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 902]
nsGfxScrollFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 850]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 943]
ViewportFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 263]
IncrementalReflow::Dispatch
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 911]
PresShell::ProcessReflowCommands
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6571]
PresShell::FlushPendingNotifications
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 5144]
nsDocument::FlushPendingNotifications
[c:/builds/seamonkey/mozilla/content/base/src/nsDocument.cpp, line 3848]
nsHTMLDocument::FlushPendingNotifications
[c:/builds/seamonkey/mozilla/content/html/document/src/nsHTMLDocument.cpp, line
1530]
nsDOMWindowList::GetLength
[c:/builds/seamonkey/mozilla/dom/src/base/nsDOMWindowList.cpp, line 102]
GlobalWindowImpl::GetLength
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1915]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
XPC_WN_GetterSetter
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1325]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936]
js_InternalGetOrSet [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 962]
js_GetProperty [c:/builds/seamonkey/mozilla/js/src/jsobj.c, line 2552]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2663]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1068]
nsJSEventListener::HandleEvent
[c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 183]
nsEventListenerManager::HandleEventSubType
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1192]
nsEventListenerManager::HandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
2193]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3337]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3356]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3356]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3356]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3356]
PresShell::HandleDOMEventWithTarget
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6353]
nsMenuFrame::Execute
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp, line 1721]
nsMenuFrame::HandleEvent
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsMenuFrame.cpp, line 463]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6322]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6240]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2223]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 309]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1959]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1154]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1171]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5439]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5694]

Comment 62

[Bernd]

the stack trace can be produced with attachment 115545 [details] from bug 194952 and shows
up again in the topcrashlist

Comment 63

[Bill Mason]

*** Bug 220059 has been marked as a duplicate of this bug. ***

Comment 64

[Martijn Wargers (dead)]

I alos get crashes when I switch styles to 'Orange' at: http://ln.hixie.ch/
I think that could probably be the same cause as this bug.
I've let it crash with Mozilla 1.7beta, talkback ID:TB31727025M 29-03-2004 0:45

I've managed to squeeze down Hixie's crasher to this:
<html><head>
<style title="spaced"></style>
<style title="Orange">
html { display: table;  }
body { display: table-cell;  }
h1 { position: absolute; top: 0; right: 0; }
</style>
</head>
<body>
<h1></h1>
</body></html>

Comment 65

[Anders Pedersen]

WFM. 

Accessing http://www.libpr0n.com/ and switching stylesheets doesnt crash my
browser. However, switching to "orange" at http://ln.hixie.ch/ crashes it.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040413
Firefox/0.8.0+
Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 66

[Martijn Wargers (dead)]

My fault. Sorry for the mess.
Comment 64 is obsolete (and comment 65 )  as this case is covered by bug 231776
. This was explained to me by Boris Zbarsky.
See comment 60 for a thorough explanation.

Comment 67

[Peter 'vt100' Schwindt]

*** Bug 240691 has been marked as a duplicate of this bug. ***

Comment 68

[Jay Patel [:jay]]

*** Bug 241509 has been marked as a duplicate of this bug. ***

Comment 69

[Jay Patel [:jay]]

Adding topcrash keyword and M17rc1 to summary (from duped bug 241509).  This is
a topcrasher with Mozilla 1.7 rc1.

Comment 70

[Andrew Schultz]

this bug WFM with builds back to 1.7a.  switching stylesheets on libr0n and the
testcase both work without crashing.

Comment 71

[Robert Strong (they/them - no direct email)]

I believe the following code will also create this bug. Can someone confirm if
it is the same issue? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5)
Gecko/20041025 and
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB1530921M

<HTML>
<HEAD>
</HEAD>
<BODY>
<DIV STYLE="DISPLAY:TABLE;">
Test
<DIV STYLE="HEIGHT:0; PADDING:99999999999px;">
</DIV>
<IMG STYLE="POSITION:ABSOLUTE;">
</DIV>
</BODY>
</HTML>

Comment 72

[timeless]

*** Bug 287981 has been marked as a duplicate of this bug. ***

Comment 73

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051230 Firefox/1.6a1

The attached testcase and all suggested testcases in the bug do not crash for me. Can I resolve as WFM, or have I fallen victim to not understanding this bug?

Comment 74

[Jay Patel [:jay]]

Marking WFM based on last comment.  Please reopen if anyone is able to reproduce with a recent nightly or any Firefox 1.5.x release.