166596 - Crash saving page with border padding issues [@ nsStyleContext::GetBorderPaddingFor]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P1)

Description

[greer]

Trunk and N7.0 both show limited numbers of this crash. 

I was able to reproduce the crash with the following steps (in N7.0):
1) Go to http://www.uww.edu/index4.html
2) Select File | Edit Page
(Now in composer. If this is indeed a border padding issue size of the window
may be significant, mine is a little larger than a quarter of the screen.)
3) Select File | Save as...
4) Save the file.
5) Crash.

This is producing the same crash that SusieW saw earlier today trying to forward
an email, cc'ing her.

Incident #10363179
--------------------
Product ID  Gecko1.0
Build ID 2002082310
Operating System Windows NT 5.0 build 2195

Stack Trace
nsStyleContext::GetBorderPaddingFor
[d:\builds\seamonkey\mozilla\content\base\src\nsStyleContext.cpp, line 364]
nsFrame::CalcBorderPadding
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp, line 514]
nsComboboxControlFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\forms\src\nsComboboxControlFrame.cpp,
line 1601]
nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1070]
nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3650]
nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3524]
nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3449]
nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3394]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2507]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
nsTableCellFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 949]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
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 1457]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
nsTableRowGroupFrame::ReflowChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 448]
nsTableRowGroupFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1212]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
nsTableFrame::ReflowChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 3294]
nsTableFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2004]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
nsTableOuterFrame::OuterReflowChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1028]
nsTableOuterFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1613]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
571]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
349]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
571]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
349]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
571]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
349]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
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 887]
nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 628]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1062]
nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp, line 395]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1062]
nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 650]
nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1082]
nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1241]
nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1090]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1062]
nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1001]
nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 780]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833]
ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 603]
IncrementalReflow::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 893]
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6482]
ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6330]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 530]

Comment 1

[Kevin McCluskey (gone)]

-> Kin

Comment 2

[Andrew Schultz]

also get this with linux trunk build 20020929

Comment 3

[Andrew Schultz]

Attachment: linux stacktrace

the stack is different, but is still in the stylesystem.

(gdb) frame 6
#6  nsCachedStyleData::GetStyleData (this=0x8af21d4, aSID=@0xbfffd774)
    at ../../../dist/include/content/nsRuleNode.h:218
218	      data = *NS_REINTERPRET_CAST(nsStyleStruct**, dataSlot);
(gdb) info locals
dataSlot = 0xfffffffc <Address 0xfffffffc out of bounds>
aSID = (nsStyleStructID &) @0xfffffffc: Cannot access memory at address
0xfffffffc
(gdb) frame 7
#7  0x40d9f72c in nsRuleNode::GetStyleData (this=0x8af21c4,
aSID=eStyleStruct_Border, 
    aContext=0x8af21f0, aComputeData=1) at nsRuleNode.cpp:4709
4709	  const nsStyleStruct* cachedData = mStyleData.GetStyleData(aSID);
(gdb) p mStyleData
$11 = {static gInfo = 0x40e2ca60, mInheritedData = 0xdddddddd, mResetData =
0xdddddddd}
(gdb) p aSID
$12 = eStyleStruct_Border

Comment 4

[kinmoz]

In the debugger, it looks like the mStyleContext for the combobox block frame
has destroyed data in it. I'm wondering if this is related some how to bug
123049, though that bug has an entirely different stack trace.

Comment 5

[kinmoz]

Attachment: CSS file with bogus rule in it. (to be used with crash test case)

Comment 6

[kinmoz]

Attachment: Test Case (Load this in composer and save it out to see the crash)

Comment 7

[kinmoz]

Ok it looks like we crash because the combobox frame's anonymous child block
frame, which strangely has a text node as it's mContent, is never really removed
by a call to |ContentRemoved()| because there is code in |ContentRemoved()| that
throws an error if you are removing a child of a combobox frame.


nsCSSFrameConstructor::ContentRemoved() line 9617
nsCSSFrameConstructor::RecreateFramesForContent() line 12017 + 35 bytes
nsCSSFrameConstructor::ProcessRestyledFrames() line 10262
PresShell::ReconstructStyleData() line 5522
PresShell::StyleSheetRemoved() line 5559
nsDocument::RemoveStyleSheet() line 1565
nsStyleLinkElement::UpdateStyleSheet() line 207
nsHTMLLinkElement::SetAttr() line 150
nsGenericHTMLElement::SetAttr() line 1751 + 36 bytes
nsHTMLLinkElement::SetAttr() line 155 + 21 bytes
nsDOMAttribute::SetValue() line 150 + 36 bytes
nsDOMAttribute::SetNodeValue() line 218
nsWebBrowserPersist::FixupNodeAttribute() line 2882
nsWebBrowserPersist::CloneNodeWithFixedUpURIAttributes() line 2673 + 22 bytes
nsEncoderNodeFixup::FixupNode() line 3275 + 19 bytes
nsDocumentEncoder::SerializeNodeStart() line 300 + 66 bytes
nsDocumentEncoder::SerializeToStringRecursive() line 381 + 20 bytes
nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes
nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes
nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes
nsDocumentEncoder::EncodeToString() line 954 + 21 bytes
nsDocumentEncoder::EncodeToStream() line 994 + 19 bytes
nsWebBrowserPersist::SaveDocumentWithFixup() line 3076 + 44 bytes
nsWebBrowserPersist::SaveDocuments() line 1521 + 87 bytes
nsWebBrowserPersist::OnStopRequest() line 664 + 11 bytes
nsFileChannel::OnStopRequest() line 595
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent() line 116
PL_HandleEvent() line 646 + 10 bytes
PL_ProcessPendingEvents() line 576 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents() line 388 + 12 bytes
nsWindow::DispatchPendingEvents() line 3609
nsWindow::ProcessMessage() line 3844
nsWindow::WindowProc() line 1308 + 27 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e183f1()
nsAppShellService::Run() line 472
main1() line 1522 + 32 bytes
main() line 1883 + 37 bytes
mainCRTStartup() line 338 + 17 bytes



This leaves frames in the frame tree, with mStyleContexts that point to
mRuleNodes that get blown away when the stack unwinds back to
|ReconstructStyleData()|:



nsRuleNode::~nsRuleNode line 447
nsRuleNode::`scalar deleting destructor' + 15 bytes
nsRuleNode::Destroy line 415
nsRuleList::~nsRuleList line 73
nsRuleList::`scalar deleting destructor' + 15 bytes
nsRuleList::Destroy line 87
nsRuleList::~nsRuleList line 75
nsRuleList::`scalar deleting destructor' + 15 bytes
nsRuleList::Destroy line 87
nsRuleList::~nsRuleList line 75
nsRuleList::`scalar deleting destructor' + 15 bytes
nsRuleList::Destroy line 87
nsRuleList::~nsRuleList line 75
nsRuleList::`scalar deleting destructor' + 15 bytes
nsRuleList::Destroy line 87
nsRuleNode::~nsRuleNode line 456
nsRuleNode::`scalar deleting destructor' + 15 bytes
nsRuleNode::Destroy line 415
StyleSetImpl::EndRuleTreeReconstruct line 1325
PresShell::ReconstructStyleData line 5531
PresShell::StyleSheetRemoved line 5559
nsDocument::RemoveStyleSheet line 1565
nsStyleLinkElement::UpdateStyleSheet line 207
nsHTMLLinkElement::SetAttr line 150
nsGenericHTMLElement::SetAttr line 1751 + 36 bytes
nsHTMLLinkElement::SetAttr line 155 + 21 bytes
nsDOMAttribute::SetValue line 150 + 36 bytes
nsDOMAttribute::SetNodeValue line 218
nsWebBrowserPersist::FixupNodeAttribute line 2882
nsWebBrowserPersist::CloneNodeWithFixedUpURIAttributes line 2673 + 22 bytes
nsEncoderNodeFixup::FixupNode line 3275 + 19 bytes
nsDocumentEncoder::SerializeNodeStart line 300 + 66 bytes
nsDocumentEncoder::SerializeToStringRecursive line 381 + 20 bytes
nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes
nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes
nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes
nsDocumentEncoder::EncodeToString line 954 + 21 bytes
nsDocumentEncoder::EncodeToStream line 994 + 19 bytes
nsWebBrowserPersist::SaveDocumentWithFixup line 3076 + 44 bytes
nsWebBrowserPersist::SaveDocuments line 1521 + 87 bytes
nsWebBrowserPersist::OnStopRequest line 664 + 11 bytes
nsFileChannel::OnStopRequest line 595
nsOnStopRequestEvent::HandleEvent line 213
nsARequestObserverEvent::HandlePLEvent line 116
PL_HandleEvent line 646 + 10 bytes
PL_ProcessPendingEvents line 576 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents line 388 + 12 bytes
nsWindow::DispatchPendingEvents line 3609
nsWindow::ProcessMessage line 3844
nsWindow::WindowProc line 1308 + 27 bytes
USER32! 77e11b60
USER32! 77e11cca
USER32! 77e183f1
nsAppShellService::Run line 472
main1 line 1522 + 32 bytes
main line 1883 + 37 bytes
mainCRTStartup line 338 + 17 bytes


Another interesting tidbit, is that a strategically placed breakpoint at the
point where we create the combobox frame's anonymous child block frame can
adjust timing so that both the combobox frame and the child block frame have the
same styleContexts ... and instead of the anonymous child block frame ending up
in the change list in |ReconstructStyleData()|, the combobox frame itself ends
up in the change list, and everything works just fine.

This is sort of similar to what I was seeing when trying to create the test case
attatched to the bug. Sometimes things worked, but most of the times things crashed.

Another thing I should mention, is that I know when this bug will occur because
I see this warning message twice in the console:


frame: Block(-1) (039BDA40) style: 039BDABC :-moz-display-comboboxcontrol-frame {}
Wrong parent style context:  style: 039BD32C {}
should be using:  style: 039C06A0 {}


I don't see it in the console when things work fine.

Comment 8

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

Yet another reason why we need XBL form controls as soon as possible.

Comment 9

[Rick Ju]

i have spent more than one week on this. 
really made some progresses but still not find its root.

kin is right. 
an error occured in
  nsCSSFrameConstructor::ContentRemoved() line 9617 

at this point, it is reconstructing a stylechanged Frame which is
nsComboboxControl::mDisplayFrame.

pls read PresShell::ReconstructStyleData(...)
  {
      ...
    <A> FrameManager::ComputeStyleChangeFor(...aChangeList...)
      ....
    <B> FrameManager::ProcessReStyledFrames(...aChangeList...)
      ....
   } 

that frame is added to aChangeList in <A>, indicating its style has changed
(because new stylesheet was added).
so in <B>, we try to reconstruct the frame and get a error in ContentRemoved.

the point is  the Frame should not be added to aChangeList at all since no style
change for it.

Deep in why it is added( i.e find what change between its old stylecontext and
new resolved sytlecontext), i find that the new stylecontext for the frame has a
wrong nsStyleUserInput data which is NS_STYLE_USER_INPUT_AUTO instead of
NS_STYLE_USER_INPUT_NONE. (note that the frame,
nsComboboxControlFrame::mDisplayFrame is nsBlockFrame which is parent of
mTextFrame which is used to display combobox's content )

This new styleContext is created at:

   FrameManager::ReResolveStyleContext {    
        ...

+1741  aPresContext->ResovePseudoStyleContextForNonElement(...)
        ...
   }


i have tried my best to clarify what i have get :) i really hope what i said can
be understood. :) if u can or can't, tell me please.

it will be very appreciated if some CSS guy  can give some hints. 


--> take it

Comment 10

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

(Another thought:  why are we adding and removing stylesheets in order to
serialize a document?  It shouldn't crash when we do, but why bother?)

Comment 11

[Rick Ju]

y. i wondered why we do it also when i began.i don't know much about it so
assumed it should be ok. 
Even we shouldn'd add/remove when serializing a document, finding the root why
it crash here is still needed.

Comment 12

[kinmoz]

> (Another thought:  why are we adding and removing stylesheets in order to
> serialize a document?  It shouldn't crash when we do, but why bother?)

Comment #7 illustrates what's happening ... the document encoder is replacing
the url to the stylesheet on the net, with a url to the local saved version.

Comment 13

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

But why does the document need to be hooked up to a pres shell while that happens?

Comment 14

[kinmoz]

I guess it's because we're serializing directly off the set of dom nodes
currently being edited and displayed on screen. Are you suggesting that we blow
away the presShell/frames just for a save, and then recreate them when we are
done? I think the only modifications the encoder makes is mapping urls used in
the doc to local urls.

----

Rick, have you tried tracking down the timing issue I pointed out in comment #7?

I thought it was a bit strange that we don't end up with the same set of style
contexts all the time, so there may be bug on the load side of things.

Comment 15

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

Sorry, I was thinking of webbrowserpersist saving, rather than editor saving
(where you edit a remote URL and then save it locally).

Comment 16

[Boris Zbarsky [:bzbarsky]]

> Are you suggesting that we blow away the presShell/frames just for a save

Well.. if we have stylesheets in the doc we're doing that _anyway_, as we change
the urls, right?  Once per stylesheet.

Comment 17

[Rick Ju]

----
>Rick, have you tried tracking down the timing issue I pointed out in comment #7?
>
>I thought it was a bit strange that we don't end up with the same set of style
>contexts all the time, so there may be bug on the load side of things.

yes, i really saw that happen, but very very seldomly, only once or twice . 

i think we maybe know more the strange thing if we find why we
ResolvePesudoStyleContext a (nsBlockFrame*)mDisplayFrame which has a
nsStyleUserInput ==NS_STYLE_USER_INPUT_AUTO instead of _NONE.

another thing:
    this error( the frame has been added to aChangeList and frame-reconstructing
 failed in ContentRemoved, after this, the frame own a invalid RuleNode
destroyed already) _has_ _happened_ when you click 'Edit Page' ! and is exposed
 when "Save As" or in other time. 


    

Comment 18

[Rick Ju]

very sorry, pls igore the last one #17, some typo in it

----
>Rick, have you tried tracking down the timing issue I pointed out in comment #7?
>
>I thought it was a bit strange that we don't end up with the same set of style
>contexts all the time, so there may be bug on the load side of things.

yes, i really saw that happen, but very very seldomly, only once or twice . 

i think we maybe know more about the strange thing if we find why we
ResolvePesudoStyleContext a (nsBlockFrame*)mDisplayFrame which has a
nsStyleUserInput==NS_STYLE_USER_INPUT_AUTO instead of _NONE.

another thing:
    this error( the frame has been added to aChangeList and frame-reconstructing
 failed in ContentRemoved, after this, the frame own a invalid RuleNode
destroyed already) _will_ _happen_ when you click 'Edit Page' ! and is exposed
 when "Save As" or in other time. 

Comment 19

[Boris Zbarsky [:bzbarsky]]

The patch in bug 197942 may fix this -- with that patch, the combobox itself and
the anonymos block will have the same mContent, so an attempt to reframe it will
reframe the whole combobox.

I'll test for sure tonight.

Comment 20

[Boris Zbarsky [:bzbarsky]]

I'm not seeing a crash with a current nightly..... (without my patch).

Comment 21

[Boris Zbarsky [:bzbarsky]]

Is this still crashing now that bug 197942 is fixed?

Comment 22

[Andreas Kunz]

bz:
I also cannot reproduce it (1.6 on Win2k, URL and testcase tested), so you
probably want to mark this fixed or WFM.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Yeah, marking so.