115919 - [RR]Crash when applying theme on certain web pages [@ nsLineLayout::IsPercentageUnitSides]

Status: VERIFIED FIXED

(Core Graveyard :: Skinability, defect)

Description

[Steve Chapel]

Reproducible: Always

Steps to reproduce:
1. Go to http://java.sun.com/
2. Apply the Modern theme (or Classic theme). It doesn't matter if you apply the
current theme or a different theme.

Expected results: The theme changes immediately.

Actual results: Crash.

These Talkback reports were generated from the builds of 20011218: TB645909K,
TB645887G, TB645867K, TB645813X, TB635909Q, TB635887K.

Comment 1

[Pete Boyd]

I've seen similar the first time I ran a build with the re-introduced dynamic
theme switching and switched between classic and modern. 
os:Windows 2000; build ID:2001-12-18-03; Talkback Incident ID:TB649283Z

Comment 2

[Pete Boyd]

and another crash. talkback: TB650183X

crashed whilst on a Bugzilla page.  a wildly hazarded guess...atleast for my
crashes, I doubt its anything to do with the page itself

Comment 3

[greer]

The stack trace in the talkback incidents listed above matches that of one of 
today's topcrashes on the Trunk. The conditions are similar to those in bugs 
116038 and 106596 but those bug have multiple signatures associated with the 
crashes.

Here are the stack and comments:
Crash data range: 2001-12-18 to 2001-12-19
Build ID range: 2001121721 to 2001121814

Stack Trace: 

         nsLineLayout::IsPercentageUnitSides
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp  line 1767]
         IsPercentageAwareChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp
line 1139]
         nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3697]
         nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3586]
         nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3511]
         nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3456]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2528]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2180]
         nsBlockFrame::Reflow   
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp
line 847]
         nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line 
581]
         nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line 
359]
         nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3200]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2407]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2180]
         nsBlockFrame::Reflow   
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp
line 847]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 
766]
         CanvasFrame::Reflow    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp
line 567]
         nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 
843]
         nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 
606]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 396]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 654]
         nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 
1059]
         nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 
1170]
         nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 
1067]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsBoxFrame::Reflow     
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp
line 953]
         nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 
776]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 
766]
         ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 574]
         PresShell::ResizeReflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 2833]
         PresShell::ResizeReflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6087]
         nsViewManager::SetWindowDimensions
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp  line 571]
         nsViewManager::DispatchEvent   
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp
line 1817]
         HandleEvent    [d:\builds\seamonkey\mozilla\view\src\nsView.cpp  line 
83]
         nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 850]
         nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 867]
         nsWindow::OnResize     
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line
4279]
         nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 3582]
         nsWindow::WindowProc   
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line
1112]
         USER32.dll + 0x1303 (0x77e71303)
         USER32.dll + 0x2fa2 (0x77e72fa2)
         ntdll.dll + 0x163ef (0x77f763ef)
         DocumentViewerImpl::SetBounds
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1529]
         nsDocShell::SetPositionAndSize 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp
line 2571]
         nsWebShell::SetPositionAndSize 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp
line 1472]
         nsHTMLFrameInnerFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp  line 
1465]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 
766]
         nsHTMLFrameOuterFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp  line 
528]
         nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 
843]
         nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 
606]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsStackLayout::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsStackLayout.cpp
line 331]
         nsContainerBox::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 612]
         nsBoxFrame::DoLayout   
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp
line 1151]
         nsDeckFrame::DoLayout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsDeckFrame.cpp
line 402]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsSprocketLayout::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp  line 529]
         nsContainerBox::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 612]
         nsBoxFrame::DoLayout   
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp
line 1151]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1056]
         nsStackLayout::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsStackLayout.cpp
line 331]
         nsContainerBox::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 612]
 
        Source File : 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsLineL
ayout.cpp line :
1767
     (671248)   Comments: Changing from modern to classic theme from Prefs 
dialog
     (666081)   URL: http://news.bbc.co.uk
     (664550)   URL: themes.org
     (662802)   URL: www.fileplanet.com
     (651925)   URL: www.multimap.co.uk
     (651925)   Comments: I had a window open at www.planetrecruit.co.uk  one at 
www.jobserve.co.uk and one at www.multimap.co.uk.  I had just registered with 
multimap.co.uk and logged in.  Then windows gave me a dialogue box about the 
fatal error.
     (646317)   URL: http://java.sun.com/
     (646317)   Comments: I applied the Classic theme.
     (645887)   URL: http://java.sun.com/
     (645887)   Comments: I applied the Modern theme.
     (635887)   Comments: I tried to apply the Modern theme while I was using 
the Classic theme.

Comment 4

[greer]

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

Comment 5

[greer]

Bug 116244 shows a crash with the same stack happening on Solaris. Further 
looks at Talkback data show incidents happening on Linux, Win98, Win2000 and 
XP. OS -> All Platform -> All

Comment 6

[Joe Hewitt (gone)]

all yours Hyatt

Comment 7

[greer]

Attachment: User comments

Any movement on this one? It's still a big problem on the Trunk. Judging from
user comments this one seems to be easily reproducible with the Little Mozilla
theme. ( http://www.geocities.com/alfredkayser/mozilla/themes.htm )

Comment 8

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

Although I don't see the crash anymore (I used to), I do see style context
parentage warnings that make me think this is the same problem as bug 116022.  I
added some additional debugging code that shows all the warnings are because the
style contexts are in entirely different style context trees.

Comment 9

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

Attachment: simplified testcase that leads to mis-parented style context on skin switch

Comment 10

[Olav Vitters]

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

Comment 11

[greer]

Can this one still make M098?

Comment 12

[Olav Vitters]

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

Comment 13

[Julien Cegarra]

Could someone check if that one is a dupe:
- go to http://design4use.net/themewrap/ download any file (Win32/ThemeWrap.zip 
for me);
- while downloading change theme.

Mozilla crash (BuildID: 2002 01 16 04)

/jc

Comment 14

[greer]

Tried the crash in comment #13, same signature, same stack, same bug.

Comment 15

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

Just bringing up the download dialog by clicking
http://design4use.net/themewrap/win32/ThemeWrap.zip and then changing theme is
enough to cause the crash.

Comment 16

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

Removing *all* of the don't-do-this-if-it's-a-FRAMECHANGE checks in
ReResolveStyleContext fixes this.  Perhaps we're not doing a FRAMECHANGE
correctly when generated content is involved?

Comment 17

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

Attachment: patch that hides the crash (plus performance hit)

This explains what I meant in my previous comment.

Comment 18

[Patty Mac]

I can reproduce the crash on windows 98 when switching themes in preferences 
dialog (commercial build: 2002-01-17-09-trunk).

Steps to reproduce:
1. Go to http://java.sun.com/
2. Apply the Modern theme (or Classic theme). It doesn't matter if you apply the
current theme or a different theme. This works fine, no crash!

NOTE: If you switch themes from Preferences dialog, it crash!

I have the same stacktrace like comment#3:

Stack traces on windows 98 (commercial build: 2002-01-17-09-trunk):


nsLineLayout::IsPercentageUnitSides [d:\builds\seamonkey\mozilla\layout\html\
base\src\nsLineLayout.cpp, line 1767] 
IsPercentageAwareChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 1138] 
nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockFrame.cpp, line 3727] 
nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockFrame.cpp, line 3616] 
nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\
base\src\nsBlockFrame.cpp, line 3541] 
nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockFrame.cpp, line 3486] 
nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2601] 
nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2279] 
nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 846] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableCellFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableCellFrame.cpp, line 943] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableRowFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\table\
src\nsTableRowFrame.cpp, line 1039] 
nsTableRowFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableRowFrame.cpp, line 1427] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableRowGroupFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableRowGroupFrame.cpp, line 453] 
nsTableRowGroupFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableRowGroupFrame.cpp, line 1155] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableFrame.cpp, line 3137] 
nsTableFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableFrame.cpp, line 1934] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableOuterFrame::OuterReflowChild [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 979] 
nsTableOuterFrame::IR_InnerTableReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 1296] 
nsTableOuterFrame::IR_TargetIsMe [d:\builds\seamonkey\mozilla\layout\html\table\
src\nsTableOuterFrame.cpp, line 1245] 
nsTableOuterFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 1029] 
nsTableOuterFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableOuterFrame.cpp, line 1531] 
nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\
base\src\nsBlockReflowContext.cpp, line 581] 
nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockReflowContext.cpp, line 359] 
nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 3230] 
nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2506] 
nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2279] 
nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 846] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableCellFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableCellFrame.cpp, line 943] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableRowFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\table\
src\nsTableRowFrame.cpp, line 1261] 
nsTableRowFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableRowFrame.cpp, line 1156] 
nsTableRowFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableRowFrame.cpp, line 1431] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableRowGroupFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableRowGroupFrame.cpp, line 1555] 
nsTableRowGroupFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableRowGroupFrame.cpp, line 1232] 
nsTableRowGroupFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableRowGroupFrame.cpp, line 1142] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\table\
src\nsTableFrame.cpp, line 2856] 
nsTableFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\table\
src\nsTableFrame.cpp, line 2695] 
nsTableFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableFrame.cpp, line 1950] 
nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsContainerFrame.cpp, line 771] 
nsTableOuterFrame::OuterReflowChild [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 979] 
nsTableOuterFrame::IR_InnerTableReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 1296] 
nsTableOuterFrame::IR_TargetIsInnerTableFrame [d:\builds\seamonkey\mozilla\
layout\html\table\src\nsTableOuterFrame.cpp, line 1085] 
nsTableOuterFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 1075] 
nsTableOuterFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\
table\src\nsTableOuterFrame.cpp, line 1038] 
nsTableOuterFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\
nsTableOuterFrame.cpp, line 1531] 
nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\
base\src\nsBlockReflowContext.cpp, line 581] 
nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockReflowContext.cpp, line 359] 
nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 3230] 
nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2506] 
nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2279] 
nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 846] 
nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\
base\src\nsBlockReflowContext.cpp, line 581] 
nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\
src\nsBlockReflowContext.cpp, line 359] 
nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 3230] 
nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2506] 
nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\
nsBlockFrame.cpp, line 2279]

Comment 19

[Olav Vitters]

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

Comment 20

[Patty Mac]

It's weird. Looks like I sometimes can reproduce the problem which is similar 
to bug# 117080 (windows 98: 2002-01-17-09-trunk).While switching themes by 
selecting View > Apply themes...continuously for serveral time, the navigation
toolbar is in classic skin mixing with the menu bar in modern skin. Screen shot 
is coming...
It also occurs on linux and Mac OS 10.1 (2002-01-18-08-trunk) as well while 
switching themes, the composer toolbar is not correct, missing spell or image 
icons, etc...

Comment 21

[Patty Mac]

Attachment: Screenshot shows the problem on navigation toolbar

Comment 22

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

Many of these "wrong parent style context" warnings should be bogus, since the
framechange hasn't happened yet when VerifyStyleTree is called.  However, the
root cause of this bug seems to be that the framechange *isn't* happening, so
we're stuck with orphaned style contexts.  Still have to figure out why that
happens, though.

Comment 23

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

The basic causes of this problem are both related to our rather bizarre (despite
agreement with the incorrect examples in the CSS2 spec) handling of :before and
:after generated content on leaf frames (which we *use* for HR elements).  We
put the :before and :after as siblings of the frame, rather than first and last
child.

In this case we generate three FRAMECHANGE hints for the HR -- one for its
:before, one for the HR itself, and one for its :after.  (I'm not exactly sure
*why* -- there really shouldn't be any change.)

This led me to discover that nsStyleChangeList::AppendChange collapses multiple
changes for the same content node.  At first, I thought this was the real problem.

However, I think the real problem is that handling of a FRAMECHANGE hint calls
RecreateFramesForContent on the content node, which calls GetPrimaryFrameFor to
get the primary frame, and somehow manages not to destroy the old generated
:before and :after content.  Now I have to figure out why *that* happens.

Comment 24

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

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

Comment 25

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

Attachment: real fix #1 (diff -u)

This patch fixes the crash, and is a real fix for a real problem.  However,
there's a second real problem lurking, which is that we're getting FRAMECHANGE
hints when we shouldn't be.  I believe that's because quirks.css is being
removed on a theme change, which is a bug in itself and is why I'm calling this
#1.

What was happening is that rules for hr:before and hr:after were being removed.
 However, RemoveGeneratedContentFrameSiblings checked for the presence of
:before and :after pseudos with ProbePseudoStyleContext before attempting to
remove generated content frames.  This is (1) an invalid optimization since (as
in this case) if the pseudo-element rules are *removed* we end up with a
framechange notification that requires that we remove the frames and (2) an
"optimization" that probably (IMO) makes things slower, since poking around in
the frame tree should usually usually faster than doing selector matching.

This version is for testing, the diff -uw will be much clearer for review.  I
un-indented a good bit of code.

Comment 26

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

Attachment: real fix #1 (diff -uw)

Diff ignoring un-indenting, for review.

Comment 27

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

A little debugging code that I stuck in CaptureChange to print out the rules
matched by the old style context and the new one for any hr:before style context
showed that the old contexts are matching the hr:before rule in quirk.css and
the new contexts are not.  I have no idea why quirk.css was being applied before
the change, though.  (mQuirkStyleSheet->GetEnabled shows that it's not, although
maybe I didn't call it soon enough)

Comment 28

[David Hyatt]

Well, we shouldn't have any <hr> in XUL.  We should be using <separator/>
instead, so you could switch over to that to work around the crash.  Still it's
crazy that quirks would be applying to XUL at all.

Comment 29

[basic]

maybe "quirks mode" needs its own namespace?

Comment 30

[David Hyatt]

Ok, got it, and - well - if I understand it correctly, the implications are 
quite astonishing.  It appears that whether or not to apply the quirks 
stylesheets is essentially a *global* variable across all documents.  I'm not 
kidding.

Every style set (for each document) gets the user agent style sheet inserted 
into its set of agent sheets.  That ua.css sheet is *the same sheet*.  It 
imports quirks.css, which is also *the same sheet* across every style set.

When one style set is told to enable the quirks sheet, it goes and looks up 
the sheet and sets its disabled state.  When it does this, it has effectively 
just changed the state for all other current open documents (XUL/HTML/XML) in 
all other windows)!

This leads to the possibility that the quirks mode can be incorrectly applied 
whenever multiple windows are loading and resolving style concurrently.

Comment 31

[David Hyatt]

Attachment: Ensure every doc viewer receives a unique agent sheet.

My fix for this problem is to Clone the user agent style sheet, so that each
doc viewer receives its own clone of the sheet.  Since disabled state is held
outside of the shared portion, there is no fault.

This could spike page load though by a few ms, depending on how expensive
cloning a sheet is.

Comment 32

[Brendan Eich [:brendan]]

One would hope that cloning takes microseconds (dozens to hundreds of
instructions), not milliseconds.

/be

Comment 33

[Brendan Eich [:brendan]]

I say get r= and sr= on attachment 65808 [details] [diff] [review], and I'll a= it for checkin to the
0.9.8 trunk.  We can monitor pageload perf and take action only if needed --
let's optimize here.

/be

Comment 34

[David Hyatt]

I'd like to get some agreement that my theory is correct first before landing.

Comment 35

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

It doesn't seem to fix the removal of the quirk.css rules.  I also needed an
additonal patch to nsContentDLF.{h,cpp} to get the browser to start up, since it
was passing in a null UA stylesheet in some cases.

Comment 36

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

Attachment: patch to nsContentDLF that I needed to use attachment 65808 without crashing on startup

Comment 37

[David Hyatt]

Attachment: A simpler way to avoid the crash?

Seems like this patch might be simpler.

Comment 38

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

That would work, but I think it's wrong that some documents aren't getting a UA
stylesheet and it also doesn't solve the problem that the patch doesn't fix the
quirk.css problem (assuming I tested it right).

Comment 39

[David Hyatt]

A couple of questions:
(1) How are you getting a null stylesheet?  Just starting up normally?  I 
don't see that on Win32.
(2) What are your steps to reproduce the case where quirks.css is being 
removed?  Which of these crashing test cases are you using?

Comment 40

[David Hyatt]

Ok, so we basically have three patches, all of which should land for this bug 
I think.  I have un-obsoleted the DLF patch to make that clear.

Comment 41

[David Hyatt]

Comment on attachment 65848 [details] [diff] [review]
patch to nsContentDLF that I needed to use attachment 65808 [details] [diff] [review] without crashing on startup

r=hyatt on dbaron's patches.

Comment 42

[David Hyatt]

Comment on attachment 65799 [details] [diff] [review]
real fix #1 (diff -uw)

r=hyatt

Comment 43

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

I'm not sure whether we want the null-check or not, although if we want it, we
probably want to ensure that mUAStyleSheet is null if the null check fails.  I
noted review for both versions, though (attachment 65808 [details] [diff] [review] and attachment 65850 [details] [diff] [review]).

Comment 44

[David Hyatt]

Brendan, care to sr all patches?

Comment 45

[Brendan Eich [:brendan]]

Comment on attachment 65799 [details] [diff] [review]
real fix #1 (diff -uw)

sr=[e-mail]

Comment 46

[Brendan Eich [:brendan]]

Comment on attachment 65848 [details] [diff] [review]
patch to nsContentDLF that I needed to use attachment 65808 [details] [diff] [review] without crashing on startup

why nsresult rather than void EnsureUAStyleSheet, if the r.v. is always
ignored?  Either way, sr=[e-mail].

/be

Comment 47

[Brendan Eich [:brendan]]

Comment on attachment 65850 [details] [diff] [review]
A simpler way to avoid the crash?

Ok, I sr'd all three patches.  I can probably take the risk of lack of driver
peer review by a='ing too, as asa would rubber-stamp-a=, and dbaron is a driver
too.

a=[e-mail] for all three patches to get into the frozen 0.9.8 trunk.

/be

Comment 48

[David Hyatt]

All patches checked in.

Comment 49

[Patty Mac]

Verified the patch. Also, no crash occurs on windows 98, linux redhat 6.2, and 
Mac OS 9.2(2002-01-24-08-trunk)