Last Comment Bug 469861 - Crash [@ nsHTMLReflowState::CalculateHypotheticalBox] with MathML, position:fixed, tables
: Crash [@ nsHTMLReflowState::CalculateHypotheticalBox] with MathML, position:f...
: assertion, crash, testcase, verified1.9.2
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: x86 Mac OS X
-- critical (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Depends on:
Blocks: randomclasses 535483
  Show dependency treegraph
Reported: 2008-12-16 12:26 PST by Jesse Ruderman
Modified: 2011-06-09 14:58 PDT (History)
2 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (crashes Firefox when loaded) (270 bytes, application/xhtml+xml)
2008-12-16 12:26 PST, Jesse Ruderman
no flags Details
Proposed fix (3.63 KB, patch)
2010-01-04 14:28 PST, Boris Zbarsky [:bz] (still a bit busy)
dbaron: review+
Details | Diff | Splinter Review
1.9.2 branch merge (3.67 KB, patch)
2010-02-26 18:37 PST, Boris Zbarsky [:bz] (still a bit busy)
mbeltzner: approval1.9.2.2+
Details | Diff | Splinter Review
1.9.1 branch merge (3.46 KB, patch)
2010-02-26 20:12 PST, Boris Zbarsky [:bz] (still a bit busy)
mbeltzner: approval1.9.1.9+
Details | Diff | Splinter Review

Description User image Jesse Ruderman 2008-12-16 12:26:04 PST
Created attachment 353260 [details]
testcase (crashes Firefox when loaded)

###!!! ASSERTION: shouldn't use unconstrained widths anymore: '(mFrameType == NS_CSS_FRAME_TYPE_INLINE && !frame->IsFrameOfType(nsIFrame::eReplaced)) || frame->GetType() == nsGkAtoms::textFrame || mComputedWidth != NS_UNCONSTRAINEDSIZE', file /Users/jruderman/central/layout/generic/nsHTMLReflowState.cpp, line 305

###!!! ASSERTION: Should hit cbrs->frame before we run off the frame tree!: 'aContainingBlock', file /Users/jruderman/central/layout/generic/nsHTMLReflowState.cpp, line 1103

0  nsIFrame::GetPositionIgnoringScrolling
1  nsHTMLReflowState::CalculateHypotheticalBox
2  nsHTMLReflowState::InitAbsoluteConstraints
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2010-01-04 13:53:25 PST
The key here is the second assertion.

nsHTMLReflowState::CalculateHypotheticalBox is being called with the viewport as aContainingBlock and the viewport as the cbrs->frame.  Then this loop:

1120     do {
1121       NS_ASSERTION(aContainingBlock,
1122                    "Should hit cbrs->frame before we run off the frame tree!");
1123       cbOffset += aContainingBlock->GetPositionIgnoringScrolling();
1124       aContainingBlock = aContainingBlock->GetParent();
1125     } while (aContainingBlock != cbrs->frame);

obviously asserts and crashes.

The reason for the weird containing block is that GetHypotheticalBoxContainer skips over frames that aren't IsContainingBlock(), and the relevant part of the frametree here is:

      Inline(math)(1)@0x15a6e38 next=0x15aa990 {480,480,0,0} [state=00000100] [content=0x2058b530] [sc=0x1562228]<
        Placeholder(mtable)(0)@0x15aac10 {0,0,0,0} [state=00400402] [content=0x2058ba00] outOfFlowFrame=TableOuter(mtable)(0)@0x15aa990
      TableOuter(mtable)(0)@0x15aa990 {0,0,0,0} [state=00000502] [content=0x2058ba00] [sc=0x15aba80] pst=:-moz-table-outer<
        Table(mtable)(0)@0x15aab00 {0,0,0,0} [state=00000402] [content=0x2058ba00] [sc=0x15a58e8]<>

In particular, the <math> element got an inline frame even though it's fixed-pos, and as a result isn't IsContainingBlock.  That's just broken.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2010-01-04 13:56:40 PST
Aha.  And the reason that happens is that the <math> ends up with display:table (because it's inline-table but forced to be block-outer).  If it took the normal "construct by display" codepath, this would all work, but it doesn't.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2010-01-04 14:28:22 PST
Created attachment 419975 [details] [diff] [review]
Proposed fix

We could also, or in addition, make nsFrame::IsContainingBlock return true if display is table, but I'm not sure we want that.
Comment 4 User image David Baron :dbaron: ⌚️UTC-8 2010-02-25 17:53:38 PST
Comment on attachment 419975 [details] [diff] [review]
Proposed fix

r=dbaron.  Sorry for the delay.

Probably worth checking that this also fixes bug 535483.
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2010-02-26 18:37:11 PST
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2010-02-26 18:37:39 PST
Created attachment 429280 [details] [diff] [review]
1.9.2 branch merge

This should be fairly safe and fixes a crasher.  Requesting 1.9.2 branch approval.
Comment 7 User image Boris Zbarsky [:bz] (still a bit busy) 2010-02-26 20:12:08 PST
Created attachment 429292 [details] [diff] [review]
1.9.1 branch merge

The context is all different, but the patch is the same.
Comment 8 User image Mike Beltzner [:beltzner, not reading bugmail] 2010-03-01 10:25:33 PST
Comment on attachment 429292 [details] [diff] [review]
1.9.1 branch merge

a=beltzner for both branches
Comment 10 User image Carsten Book [:Tomcat] 2010-03-22 10:47:12 PDT
verified for 1.9.2-2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100321 Firefox/3.6.2 ID:20100321170417 Debug Build on 10.6

Note You need to log in before you can comment on or make changes to this bug.