317502 - Crash [@ nsIFrame::GetPosition() line 664]

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Comment 1

[Bernd]

the stack looks like bug 316504 which is probably a dupe of bug  253479

Comment 2

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

So this bug is actually quite different.

What's happening here is that nsFileControlFrame::Reflow constructs an nsHTMLReflowState txtKidReflowState, that has the same frame as its parent (this doesn't make much sense, but I don't think this is the only place we do it).  This file control frame happens to be fixed-positioned.

Since the file control frame |IsContainingBlock()| is true, we initialize this inner reflow states mCBReflowState (in InitCBReflowState) to be the outer reflow state.

So in  so we go into the do-while loop near the end of nsHTMLReflowState::CalculateHypotheticalBox, which assumes that the mCBReflowState for a fixed positioned frame is the reflow state for the viewport frame, and we loop in that loop until we get to the top of the frame tree and then crash.

Comment 3

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

Attachment: testcase

"Simplified" testcase written based on what I saw in the debugger.

Comment 4

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

Attachment: patch

This doesn't make the testcases in bug 118509 any worse (nor any better, unfortunately).

Comment 5

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

Checked in to trunk, 2005-12-20 19:31 -0800.

Comment 6

[Daniel Veditz [:dveditz]]

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

a=dveditz

Comment 7

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

Checked in to MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH.

Comment 9

[Bob Clary [:bc] (inactive)]

no crash in 1.8.0.1, 1.8.1, 1.9a1 20060113 on windows. 

but in 1.9a1, clicking in the input area of the input file, automatically opens the file open dialog. this does not happen in the 1.8.x builds. 

Also, using tab to switch focus allows the input are of the input file to be focused in 1.8.x, but not trunk.

Comment 10

[Jesse Ruderman]

> but in 1.9a1, clicking in the input area of the input file, automatically opens
> the file open dialog. this does not happen in the 1.8.x builds. 

> Also, using tab to switch focus allows the input are of the input file to be
> focused in 1.8.x, but not trunk.

These changes were intentional (but somewhat controversial).  See bug 258875.

Comment 11

[Bob Clary [:bc] (inactive)]

crash test landed
http://hg.mozilla.org/mozilla-central/rev/7806c9464087