266015 - Mozilla crashes with exception in gklayout.dll [@ nsHTMLReflowState::Init]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Pavel Penaz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041025 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041025

Mozilla and Firefox crash on invalid HTML generated by mangle.cgi script. I'll
attach a testcase in a minute.

Reproducible: Always
Steps to Reproduce:
1. Clean install of Mozilla with new profile
2. Click on the testcase
Actual Results:  
Mozilla/Firefox crashes

Expected Results:  
Mozilla/Firefox should not crash

Comment 1

[Pavel Penaz]

Attachment: testcase (crashes Mozilla/Firefox)

Crashes Mozilla with exception in gklayout.dll

Comment 2

[Pavel Penaz]

Attachment: testcase (text/plain)

Comment 3

[Pavel Penaz]

Comment on attachment 163350 [details]
testcase (text/plain)

I tried to reduce the testcase a bit but without success. Whenever I removed  a
single tag Mozilla stopped crashing. Also for some reason I cannot get talkback
to work :(

Comment 4

[Jacek Piskozub]

Confirming with yesterday's Mozilla 1.7.x and brand new CVS trunk build on
Windows ME

Crash talkback:
TB1516935H

Comment 5

[Daniel Veditz [:dveditz]]

Talkback has been throttled back to only install on some random percentage of
windows installs (10 or 20%) in preparation of the release, to cut down on the
expected massive server load. If you pick the "custom" install option you will
always get talkback installed if it's explicitly selected. (after the release
developer nightlies will go back to 100% talkback installs)

The crash is in nsIFrame::GetStyleData. It dies on a null pointer in the
assertion, somehow "this" is null.

gklayout.dll!nsIFrame::GetStyleData()  Line 611
gklayout.dll!nsHTMLReflowState::Init()  Line 317
gklayout.dll!nsHTMLReflowState::nsHTMLReflowState()  Line 207
gklayout.dll!nsTableCellFrame::Reflow()  Line 838
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!nsTableRowFrame::IR_TargetIsChild()  Line 1220
gklayout.dll!nsTableRowFrame::IncrementalReflow()  Line 1104 + 0x22
gklayout.dll!nsTableRowFrame::Reflow()  Line 1403
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!nsTableRowGroupFrame::IR_TargetIsChild()  Line 1631 + 0x20
gklayout.dll!nsTableRowGroupFrame::IncrementalReflow()  Line 1309 + 0x1f
gklayout.dll!nsTableRowGroupFrame::Reflow()  Line 1215 + 0x14
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!nsTableFrame::IR_TargetIsChild()  Line 2966 + 0x22
gklayout.dll!nsTableFrame::IncrementalReflow()  Line 2675 + 0x1f
gklayout.dll!nsTableFrame::Reflow()  Line 1940 + 0x10
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!nsTableOuterFrame::OuterReflowChild()  Line 1329
gklayout.dll!nsTableOuterFrame::IR_InnerTableReflow()  Line 1689
gklayout.dll!nsTableOuterFrame::IR_TargetIsInnerTableFrame()  Line 1443
gklayout.dll!nsTableOuterFrame::IR_TargetIsChild()  Line 1425 + 0x15
gklayout.dll!nsTableOuterFrame::IncrementalReflow()  Line 1394 + 0x1f
gklayout.dll!nsTableOuterFrame::Reflow()  Line 1951 + 0x11
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsBlockReflowContext::ReflowBlock()  Line 544
gklayout.dll!nsBlockFrame::ReflowBlockFrame()  Line 3203 + 0x34
gklayout.dll!nsBlockFrame::ReflowLine()  Line 2456
gklayout.dll!nsBlockFrame::ReflowDirtyLines()  Line 2112
gklayout.dll!nsBlockFrame::Reflow()  Line 827
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!CanvasFrame::Reflow()  Line 551
gklayout.dll!nsFrame::BoxReflow()  Line 5257
gklayout.dll!nsFrame::DoLayout()  Line 5001
gklayout.dll!nsIFrame::Layout()  Line 799
gklayout.dll!nsScrollBoxFrame::DoLayout()  Line 339
gklayout.dll!nsIFrame::Layout()  Line 799
gklayout.dll!nsBoxFrame::LayoutChildAt()  Line 2689 + 0x8
gklayout.dll!nsGfxScrollFrameInner::LayoutBox()  Line 1668 + 0x11
gklayout.dll!nsGfxScrollFrameInner::Layout()  Line 1811
gklayout.dll!nsHTMLScrollFrame::DoLayout()  Line 579
gklayout.dll!nsIFrame::Layout()  Line 799
gklayout.dll!nsBoxFrame::Reflow()  Line 854
gklayout.dll!nsHTMLScrollFrame::Reflow()  Line 514
gklayout.dll!nsContainerFrame::ReflowChild()  Line 989
gklayout.dll!ViewportFrame::Reflow()  Line 249
gklayout.dll!IncrementalReflow::Dispatch()  Line 907
gklayout.dll!PresShell::ProcessReflowCommands()  Line 6296
gklayout.dll!ReflowEvent::HandleEvent()  Line 6125
xpcom.dll!PL_HandleEvent()  Line 693
xpcom.dll!PL_ProcessPendingEvents()  Line 628
xpcom.dll!_md_EventReceiverProc()  Line 1434
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d70494()
user32.dll!77d489a5()
user32.dll!77d493df()
user32.dll!77d70494()
user32.dll!77d489e8()
gkwidget.dll!nsAppShell::Run()  Line 159
appshell.dll!nsAppShellService::Run()  Line 483 + 0x30
mozilla.exe!main1()  Line 1323
mozilla.exe!main()  Line 1799 + 0x16
mozilla.exe!mainCRTStartup()  Line 338 + 0x11
kernel32.dll!7c816d4f()
kernel32.dll!7c8399f3()

Comment 6

[basic]

Attachment: check for firstKid == null

seems like firstKid is null for some reason, added the null check and I can't
cause crash anymore, I doubt this is the right fix though...

Comment 7

[basic]

Attachment: (not much) smaller testcase

got rid of the popup about unknown protocol. I suspect it's some kind of
overflow. If I cut it down further I can't get it to crash most of the time
anymore, have to reload un-numbered amount of times to get a crash, and it
still crash at the same place.

Comment 8

[basic]

Attachment: screenshot of dom tree

Here's a screenshot of the dom tree of attachment 163829 [details] in dom inspector I
used the patch in attachment 163727 [details] [diff] [review] to prevent the crash.

Comment 9

[basic]

Attachment: (larger but) less junk testcase

tried to remove as much junk as I could (while getting the crash).

Comment 10

[Boris Zbarsky [:bzbarsky]]

Somehow the table cell frame is not ending up with a block and isn't getting
dropped altogether.  I thought I'd stomped all the occurences of that.....  If
someone can reasonably reduce the testcase, that would help a great deal...

Comment 11

[basic]

Attachment: simpler (but won't crash on first load) testcase

ok, here's a simpler testcase, but it won't crash on first load, or second, or
third... so I added a <META HTTP-EQUIV=Refresh CONTENT="1"> and it crashes
eventually after a few reloads. (tried CONTENT=0 but that didn't seem to
trigger the crash)
The basic tags are
<TABLE><COL><0><MAP><BASE><MULTICOL><TITLE><OPTION>
and then after that I added lots of spaces and newlines (can't seem to crash it
without these).
I tried removing some tags but it either takes longer to cause the crash or
does not seem to crash at all. The DOM tree looks something like this (loaded
in dom inspector without the spaces and newlines)
HTML
  HEAD
    BASE
    TITLE
  BODY
    <0>   <--- text node
    TABLE
      COL
      MAP
	MULTICOL
my guess is that the MAP tag under the TABLE tag (bug 147446?) + the COL tag is
the main cause. But it would seem to need some other thing to trigger the
crash.

Comment 12

[basic]

ok so far I've been testing on the trunk. I just tried testing in firefox 0.10.1
and it seems to be harder to (or does not) crash with the testcases I posted.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Trunk is what we should be testing on, imo.

Comment 14

[basic]

forgot to mention that I get a "Weird parent in ConstructTableForeignFrame"
assertion, I suppose this means the <map>? The smallest I've been able to reduce
the testcase and still get the assertion so far is this:
<TABLE><COL><MAP>

It does not assert on the first load though, had to reload it for the assert.
DOM looks something like this:
HTML
  HEAD
  BODY
    TABLE
      COL
      MAP

No crash (so far) though.

Comment 15

[basic]

tried making the same changes as the patch in bug 147446 does. No more assert,
No more crash (so far).

Comment 16

[basic]

okay, I tried creating the equiv of <TABLE><COL><MAP> in xhtml, came up with
<table xmlns="http://www.w3.org/1999/xhtml"><col/><map/></table>, and got the
same assertion as in comment #14, not sure if it will cause any problems though
since xml doesn't do incremental reflow (yet) ?

Comment 17

[basic]

ok, I think I figured it out, though I'm not 100%. It's like this
nsPseudoFrames::IsEmpty checks mLowestType and mColGroup and
nsCSSFrameConstructor::GetPseudoCellFrame uses nsPseudoFrames::IsEmpty to check
if there are any of mTableInner, mRowGroup, mRow or mCellOuter are in the
nsPseudoFrames. The problem comes when only mColGroup is there and the others
are not.

I changed the IsEmpty check to !mLowestType and no more crash or "Weird parent
in ConstructTableForeignFrame" assertions. There is another assertion
for attachment 163349 [details] (expected only one child frame:
'!aFrameList->GetNextSibling()') in nsTableFrame.cpp. Not sure if this new
assertion means I got things wrong, but if I got it right, I'd expect that the
other IsEmpty calls need to be checked as well.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Bernd, do you know what that code is trying to do?

Comment 19

[Bernd]

table frame constructions (crash) --> me

Comment 20

[Bernd]

<table><col><map> should translate into the following structure:

<outer table pseudo>
 <table>
  <colgroup pseudo>
   <col>
  <row group pseudo>
   <row pseudo>
    <outer cell pseudo>
     <inner cell pseudo>
      <map>

Comment 21

[basic]

Attachment: patch

after taking a look at the dom of attachment 163349 [details] I think my changes has
nothing to do with the "expected only one child frame:
'!aFrameList->GetNextSibling()'" assertion.

here's the patch, what it does is make GetPseudoCellFrame ignore the pseudo
colgroup frame when checking if there are pseudo frames.

Comment 22

[basic]

ok, I did some more tests, it seems sometimes ConstructTableForeignFrame is
never called (even though map is under table in DOM). So without my patch, it
would seem that I was always getting:
<table>
  <colgroup pseudo>
   <col>
for <table><col><map>. If it called ConstructTableForeignFrame it will fail with
an assertion "Weird Parent". Not sure about <outer table pseudo>. I'm still not
sure what causes the crash in the test cases attached here. Though with my patch
I can't seem to get it to crash. I suspect something else is wrong here, for one
ConstructTableForeignFrame should always be called no?

Comment 23

[Bernd]

Attachment: parser safe testcase

Comment 24

[basic]

(In reply to comment #23)
> Created an attachment (id=164306)
> parser safe testcase
> 

should this:
<div id="table">
  <div id="col">
    <div>this text should be visible</div>
  </div>
</div>
 be rather:
<div id="table">
  <div id="col"></div>
  <div>this text should be visible</div>
</div>

Comment 25

[basic]

with my modification of attachment 164306 [details] in comment 24
ConstructTableForeignFrame is always called. Without my patch, the text is never
visible and I get the "weird parent" assertion. With my patch, the text is
visible and I do not get any assertions.

Comment 26

[basic]

Attachment: parser safe testcase v2

attachment 164306 [details] with changes mentioned in comment 24

With this testcase, I used layout debugger to dump the frames, this is part of
what I got.
Without patch (attachment 164151 [details] [diff] [review])
		TableOuter(div)(1)@0x874eb6c {0,0,0,0} [state=00010004]
[content=0x874ef80] [sc=0x874ec10]<
		  Table(div)(1)@0x874ecc8 {0,0,0,0} [state=00010004]
[content=0x874ef80] [sc=0x874c560]ColGroup-list<
		    TableColGroup(div)(1)@0x8749af8 {0,0,0,0} [state=40010004]
[content=0x874ef80] [sc=0x874ee78]<
		      TableCol(div)(1)@0x8755934 {0,0,0,0} [state=00010004]
[content=0x874ea08]
		    >
		  >
		>
with patch:
		TableOuter(div)(1)@0x874ee54 {0,0,3136,304} [state=00010004]
[content=0x874f268] [sc=0x874eef8]<
		  Table(div)(1)@0x874efb0 {0,0,3136,304} [state=00010004]
[content=0x874f268] [sc=0x874c7e8]<
		    TableRowGroup(div)(1)@0x8755d38 {0,0,3136,304}
[state=00010004] [content=0x874f268] [sc=0x8755cb4]<
		      TableRow(div)(1)@0x8755e54 {0,0,3136,304}
[state=00010004] [content=0x874f268] [sc=0x8755dd0]<
			TableCell(div)(1)@0x8755f88 {0,0,3136,304}
[state=00000004] [content=0x874f268] [sc=0x8755f04]<
			  Block(div)(1)@0x8755fe8 {0,0,3136,304}
[state=00c00004] sc=0x8756094(i=0,b=1)<
			    line 0x87562d4: count=1
state=block,clean,prevmarginclean,not impacted,not wrapped,nobr[0x804] mew=832
{0,0,3136,304} <
			      Block(div)(3)@0x87561e4 {0,0,3136,304}
[state=00000004] sc=0x8756118(i=1,b=0)<
				line 0x87562a4: count=1
state=inline,clean,prevmarginclean,not impacted,not wrapped,nobr[0x800] mew=832
{0,0,3136,304} <
				  Text(0)@0x8756264[0,27,T]  {0,0,3136,304}
[state=40200024] sc=0x8756238<
				    "this text should be visible"
				  >
				>
			      >
			    >
			  >
			>
		      >
		    >
		  >
		  ColGroup-list<
		    TableColGroup(div)(1)@0x8756304 {0,0,3136,304}
[state=80010004] [content=0x874f268] [sc=0x874f160]<
		      TableCol(div)(1)@0x8756424 {0,0,3136,304}
[state=30010004] [content=0x874f268]
		    >
		  >
		>

Comment 27

[basic]

Attachment: patch

patch as requested

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 164447 [details] [diff] [review]
patch

The assertions ABORT0 and ABORT1 give in this case are wrong... Please assert
the right thing?

But even beyond that, why are we putting these checks in?  This situation
should NOT happen.... any time it does is a major frame construction bug.  In
my opinion, doing that null-check will simply hide bugs we need to fix.

Comment 29

[basic]

(In reply to comment #28)
> (From update of attachment 164447 [details] [diff] [review])
> The assertions ABORT0 and ABORT1 give in this case are wrong... Please assert
> the right thing?
> 
> But even beyond that, why are we putting these checks in?  This situation
> should NOT happen.... any time it does is a major frame construction bug.  In
> my opinion, doing that null-check will simply hide bugs we need to fix.
> 
ok so basically the only change needed is what is in attachment 164151 [details] [diff] [review] ? bernd?

Comment 30

[Bernd]

Boris I asked for the check of the kidframe in table cell reflow, any other
table frame does the same with typical

while (kidFrame) { ... construction.

But I did not know that we have that construction at several places :-( .
In this case I would prefer a assertion like:

nsIFrame* firstKid = mFrames.FirstChild();
NS_ASSERTION(firstKid, "Frame construction error, a table cell has always an
inner cell frame");

I also thought that adding a assertion inside the table row frame construction
would be a nice idea instead of silenty faling. But I was to optimistic...

3527   nsresult rv = NS_OK;
3528   if (!aPresShell || !aPresContext || !aContent || !aParentFrame) return rv;

What should one do with such a snippet, scream and shout?

Comment 31

[basic]

Attachment: patch v3

(In reply to comment #30)
> Boris I asked for the check of the kidframe in table cell reflow, any other
> table frame does the same with typical
> 
> while (kidFrame) { ... construction.
> 
> But I did not know that we have that construction at several places :-( .
> In this case I would prefer a assertion like:
> 
> nsIFrame* firstKid = mFrames.FirstChild();
> NS_ASSERTION(firstKid, "Frame construction error, a table cell has always an
> inner cell frame");
> 
> I also thought that adding a assertion inside the table row frame
construction
> would be a nice idea instead of silenty faling. But I was to optimistic...
> 
> 3527	 nsresult rv = NS_OK;
> 3528	 if (!aPresShell || !aPresContext || !aContent || !aParentFrame) return
rv;
> 
> What should one do with such a snippet, scream and shout?
Heh, how about this one?

Comment 32

[basic]

Attachment: patch v4

ok I went overboard the last time, here's something more sensible.

Comment 33

[basic]

ok, I've done more testing and found that the GetPseudoRowFrame and
GetPseudoRowGroupFrame suffer the same problem as the GetPseudoCellFrame
(GetPseudoTableFrame seems to be immune), should I file a new bug on those or
should I just include it (testcases/patch..) here?

Comment 34

[Bernd]

please remove  NS_ASSERTION(lastRowFrame, "Frame construction error, a table
rowgroup has always a row frame"); this is simply wrong

If Boris can live with the wording of the assertions than this patch is OK with
me (I will run a rtest before this gets checked in) Please file new bugs for the
other issues if this patch keeps small it might be easier to get branch approval.

Comment 35

[basic]

Attachment: patch v5

(In reply to comment #34)
> please remove  NS_ASSERTION(lastRowFrame, "Frame construction error, a table
> rowgroup has always a row frame"); this is simply wrong
done.

> 
> If Boris can live with the wording of the assertions than this patch is OK
with
> me (I will run a rtest before this gets checked in) Please file new bugs for
the
> other issues if this patch keeps small it might be easier to get branch
approval.
done, that is now bug 267725

Comment 36

[Bernd]

Comment on attachment 164583 [details] [diff] [review]
patch v5

if you don't run the rtest for yourself I will do it.

Comment 37

[Bernd]

Comment on attachment 164583 [details] [diff] [review]
patch v5

if you don't run the rtest for yourself I will do it.

Comment 38

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 164583 [details] [diff] [review]
patch v5

>Index: layout/html/style/src/nsCSSFrameConstructor.cpp
>+    rv = GetParentFrame(aPresShell, aPresContext, aTableCreator, *aParentFrameIn, 
>                    nsLayoutAtoms::blockFrame, aState, parentFrame,
>                    hasPseudoParent);

Fix the indent (and watch the 80-column limit).

>Index: layout/html/table/src/nsTableCellFrame.cpp

>+  NS_ASSERTION(firstKid, "Frame construction error, a table cell has always an inner cell frame");

"always has", not "has always".

>+  NS_ASSERTION(firstKid, "Frame construction error, a table cell has always an inner cell frame");

Same.

sr=bzbarsky with those nits fixed.

Comment 39

[Bernd]

the patch passed the rtest

Comment 40

[Bernd]

fixed on trunk

Comment 41

[Jacek Piskozub]

Will the branches be patched as well?

Comment 42

[Bernd]

I am a little bit sceptical that taking this patch so late is really a good
idea. It touches table pseudo frame creation, which is known for beeing fragile.
I would prefer  to bake it at trunk and check it into the stable branches after
1.0 releases.

Comment 43

[Jacek Piskozub]

Bernd, this creates an uncomfortable situation where the "stable" branch 1.7.x
which is supposed to be used by distributors etc. is more unstable (in the
everyday meaning of the word) than the cutting edge 1.8a5 trunk builds. 

One could ask the question what actually is the "stable" branch for? And the
question is easy: it's enough to see how many patches are accepted every week
into 1.7.x. This branch is much less "frozen" than 1.4 and 1.0 branches ever
were. The reason is the branch is to stay active much longer than any former
"stable" branch because (2 years would be my guess with present pace of 1.8
development if neither 1.8 nor 1.9 become stable branches).

Comment 44

[Boris Zbarsky [:bzbarsky]]

In case such thing still matter, I am also against taking this patch on any
branches.

Jacek, in the end it's a question of how dangerous the crash fix is.  In this
case it's pretty dangerous.  "Stable" for stable branches refers to api and
behavior stability just as much as not-crashing stability.  This patch is _not_
something I would trust to not change behavior without a large amount of testing.

Comment 45

[Jacek Piskozub]

It's true. I cannot disagree. But we cannot forget about crash-stability issues
in the API-stable branches (to use your terminology).

BTW, Sorry for the stable vs. stable pun. Yes, I used both meanings on purpose
but you are right that could cause misunderstanding.

Also, sorry for the spam.

Comment 46

[Boris Zbarsky [:bzbarsky]]

No one's forgetting anything.  Bernd and I weighed the risks before making
comments about whether the patch should land on branch, of course.  The patch to
this bug is rather risky, and the crash it fixes is very rare.

Comment 47

[Steffen Wilberg]

Too late for 1.0 anyway.

Comment 48

[Boris Zbarsky [:bzbarsky]]

This is fixed.

Comment 49

[Jacek Piskozub]

Now that 1.7.5 is out, we should fix it on the 1.7 branch, should't we?

Comment 50

[timeless]

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

Comment 51

[Christopher Aillon (sabbatical, not receiving bugmail)]

Boris, Drivers are considering adding this to the blocking1.7.6 list.  Could you
please explain the risk (comment 46) since the fix seems trivial at a glance.

Comment 52

[Boris Zbarsky [:bzbarsky]]

The risk is that the pseudo-frame code is very very fragile.  Changes to it have
a very high risk of crash or rendering regressions, and it's not very well
tested in common usage, so those regressions can take a long time to flush out.

So, especially given the poorly defined interaction of columns and pseudo-frames
(which is what this patch is touching), I can't say, with any degree of
certainty, that this patch doesn't have ripple effects that cause other crashes.

Comment 53

[Christopher Aillon (sabbatical, not receiving bugmail)]

Minus for now then, since it appears to be too risky.

Comment 54

[Bob Clary [:bc] (inactive)]

layout/tables/crashtests/266015-1.html
http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3