Closed Bug 133219 Opened 22 years ago Closed 19 years ago

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

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: tet, Assigned: dbaron)

References

()

Details

(Keywords: crash, testcase, Whiteboard: READ COMMENTS 60 AND 66 BEFORE COMMENTING)

Crash Data

Attachments

(5 files, 4 obsolete files)

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
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
Stephen, can you retreive Talkback data please: TB4437493H or TB4437809Z ?
Keywords: crash, stackwanted
OS: Linux → All
Hardware: PC → All
Confirmed on W2K 2002032203. However, I'm still having problems with getting
Talkback to send the incident to the server.
Status: UNCONFIRMED → NEW
Ever confirmed: true
confirm on build 2002032406
TB4440361W
Linux 
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) 
Bug 134520 may or may not be related
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) 
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!
Summary: Browser crash when selecting alternate style sheet → Browser crash when selecting alternate style sheet [@ ChildIterator::get][@ FindPreviousSibling()]
Topcrash on M1RC3 & N70PR1.  
Adding M1RC3 & N70PR1 to summary for tracking, and adding topcrash+ to keywords.  
Adding a talkback folks to CC list.
Keywords: topcrash+
Summary: Browser crash when selecting alternate style sheet [@ ChildIterator::get][@ FindPreviousSibling()] → Browser crash when selecting alternate style sheet; M1RC3, N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()]
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.
Yes, that sounds right. I think hyatt and I discussed the approach here, and
there were some shortcomings with anonymous content.
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.)
Hmm.  Now that I look more closely, the |aContainer| should be the insertion
point, not the content tree parent.  So never mind...
nominating for nsbeta1 , since this is reproducable on branch 

talkback incident id 7275846
Keywords: nsbeta1
Summary change so that this bug shows up in the Talkback reports.
Summary: Browser crash when selecting alternate style sheet; M1RC3, N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()] → Browser crash when selecting alternate style sheet; M1RC3 N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()]
Adding testcase keyword since Madhur was able to reproduce this.
Keywords: testcase
we should and fix this for 1.0.1. nsbeta1+/adt2.

any idea on how soon, we might have a patch for this one?
Blocks: 143047
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2 RTM] [ETA needed]
Attached patch simplistic patch (obsolete) — Splinter Review
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 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.
Attachment #89103 - Flags: needs-work+
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)
Attachment #89103 - Attachment is obsolete: true
Are there any reproducable testcases for this crash other than
http://www.libpr0n.com/ ?
Updating the summary to current crashing releases. Adding alternate Linux signature.
Summary: Browser crash when selecting alternate style sheet; M1RC3 N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()] → Browser crash when selecting alternate style sheet; M11A M1BR Trunk N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()][@ nsCSSFrameConstructor::FindPreviousSibling]
Attached patch correct workaround (obsolete) — Splinter Review
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.)
Attachment #86771 - Attachment is obsolete: true
Attachment #89118 - Attachment is obsolete: true
Comment on attachment 90394 [details] [diff] [review]
correct workaround

sr=waterson
Attachment #90394 - Flags: superreview+
Whiteboard: [adt2 RTM] [ETA needed] → [adt2 RTM] [ETA needed][patch]
Comment on attachment 90394 [details] [diff] [review]
correct workaround

r=kin@netscape.com
Attachment #90394 - Flags: review+
David: Should you believe this is a good and needed fix for the branch, pls add
the adt1.0.1 nomination. Thanks!
Whiteboard: [adt2 RTM] [ETA needed][patch] → [adt2 RTM] [ETA 07/16]
Whiteboard: [adt2 RTM] [ETA 07/16] → [adt2 RTM] [ETA 07/16][open1.0.1]
Whiteboard: [adt2 RTM] [ETA 07/16][open1.0.1] → [adt2 RTM] [ETA 07/16][open1.0.1][patch]
Comment on attachment 90394 [details] [diff] [review]
correct workaround

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #90394 - Flags: approval+
Comment on attachment 90394 [details] [diff] [review]
correct workaround

This fix checked in to trunk, 2002-07-16 07:53 PDT.
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...
Keywords: adt1.0.1
This patch is low-risk.
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
dbaron, please get this fix into the branch too, as soon as you think it's ready.

/be
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
No, it moves the crash on http://www.libpr0n.com/ elsewhere.  It may or may not
fix other reported instances of the bug.
signature: GetNearestContainingBlock
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...
Attachment #90394 - Attachment is obsolete: true
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).
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
based on my above comment 39, i am removing the fixed1.0.1 keyword.

This bug still exists.
Keywords: fixed1.0.1
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?
Keywords: adt1.0.1+
Whiteboard: [adt2 RTM] [ETA 07/16][open1.0.1][patch] → [adt2 RTM] [ETA 07/16][patch]
it's crashing on this now with today's trunk build:
GetNearestContainingBlock

waiting for climate to get back to me....
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)
Attached file 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
cathleen: is there any one that can pick this one up, in david's absence?
Whiteboard: [adt2 RTM] [ETA 07/16][patch] → [adt2 RTM] [ETA 08/01] [patch]
Target Milestone: --- → mozilla1.0.1
Did anyone look to see if the new signature showed up in the talkback data with
the same frequency as the old one?
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
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
###!!! ASSERTION: unsupported operation: 'PR_FALSE', file nsTableCellFrame.cpp,
line 278
So I'm guessing the topcrash part is fixed, but the rest isn't?
Status: NEW → ASSIGNED
Keywords: topcrash+topcrash
Whiteboard: [adt2 RTM] [ETA 08/01] [patch] → [adt2 RTM] [ETA 08/01]
Target Milestone: mozilla1.2alpha → Future
Looks like patch in bug 123049 fixes these issues.
Depends on: 123049
-> fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
also crashing using a debug build 20030125 on Linux:

0x40d5449c in GetNearestContainingBlock (aFrame=0x8ac548c,
    aContentArea=@0xbfff9b5c) at nsHTMLReflowState.cpp:600
600	    aFrame->GetFrameType(&frameType);
Status: REOPENED → ASSIGNED
No longer depends on: 123049
marking topcrash+ since there's a testcase for this.
Keywords: topcrashtopcrash+
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
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....
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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → WORKSFORME
Maybe this is not a topcrash anymore, however I still crash using Linux Mozilla
built 5 minutes ago (CVS).
Reopening based on Comment #58.
Marking topcrash-
(Thanks Olivier!)
Status: RESOLVED → REOPENED
Keywords: topcrash+topcrash-
Resolution: WORKSFORME → ---
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.
Status: REOPENED → ASSIGNED
Keywords: nsbeta1+, topcrash-
Summary: Browser crash when selecting alternate style sheet; M11A M1BR Trunk N70PR1 [@ ChildIterator::get][@ FindPreviousSibling()][@ nsCSSFrameConstructor::FindPreviousSibling] → Browser crash when selecting alternate style sheet on libpr0n.com
Whiteboard: [adt2 RTM] [ETA 08/01] → READ COMMENT 60 BEFORE COMMENTING
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]
Summary: Browser crash when selecting alternate style sheet on libpr0n.com → Browser crash when selecting alternate style sheet on libpr0n.com [@ GetNearestContainingBlock]
the stack trace can be produced with attachment 115545 [details] from bug 194952 and shows
up again in the topcrashlist
*** Bug 220059 has been marked as a duplicate of this bug. ***
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>
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
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.
Whiteboard: READ COMMENT 60 BEFORE COMMENTING → READ COMMENTS 60 AND 66 BEFORE COMMENTING
*** Bug 240691 has been marked as a duplicate of this bug. ***
Blocks: 241509
*** Bug 241509 has been marked as a duplicate of this bug. ***
Adding topcrash keyword and M17rc1 to summary (from duped bug 241509).  This is
a topcrasher with Mozilla 1.7 rc1.
Keywords: topcrash
Summary: Browser crash when selecting alternate style sheet on libpr0n.com [@ GetNearestContainingBlock] → Browser crash when selecting alternate style sheet on libpr0n.com - M17rc1 [@ GetNearestContainingBlock]
Summary: Browser crash when selecting alternate style sheet on libpr0n.com - M17rc1 [@ GetNearestContainingBlock] → Browser crash when selecting alternate style sheet on libpr0n.com - M17rc2 [@ GetNearestContainingBlock]
this bug WFM with builds back to 1.7a.  switching stylesheets on libr0n and the
testcase both work without crashing.
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>
Summary: Browser crash when selecting alternate style sheet on libpr0n.com - M17rc2 [@ GetNearestContainingBlock] → Browser crash when selecting alternate style sheet on libpr0n.com - M17x [@ GetNearestContainingBlock]
*** Bug 287981 has been marked as a duplicate of this bug. ***
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?

Keywords: topcrash
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ GetNearestContainingBlock]
You need to log in before you can comment on or make changes to this bug.