Closed Bug 410198 Opened 14 years ago Closed 13 years ago

Crash with an absolutely positioned element inside a inline relative one [@ nsHTMLReflowState::GetNearestContainingBlock]

Categories

(Core :: Layout: Positioned, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: fassino, Assigned: fassino)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122805 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122805 Minefield/3.0b3pre

In some cases (depending on particular word wrapping and white space in source code) there is a crash on pages with an inline relatively positioned element containing an absolutely positioned one.


Reproducible: Always
Attached file minimal test case
An inline (gray background) relative element contains an absolutely positioned one (red background.)  If the browser window is slowly resized so that the inline element starts at the end of a line, there is usually a crash (in Windows XP.)
Addition of some white-space seems to fix the problem.
Attached file crash stack
Here's the crash report I got for this:
bp-de7e95de-b662-11dc-aee5-001a4bd43e5c

The first 14 frames look the same as Bug 398332. 

duplicate?
Severity: normal → critical
Keywords: crash, testcase
Let's make it dependent on that bug and see whether the possible patch in that bug fixes this crash.
Status: UNCONFIRMED → NEW
Depends on: 398332
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Summary: Crash with an absolutely positioned element inside a inline relative one → Crash with an absolutely positioned element inside a inline relative one [@ nsHTMLReflowState::GetNearestContainingBlock]
Does not crash for me on RC1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 and also:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre)
Gecko/2008052816 Minefield/3.0pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10.5; en-US; rv:1.9pre) Gecko/2008052817 Firefox/3.0pre (Debug Builds with the Patch from Bug 398332 included) and the testcase.

Bruno, do you still see the crash on the Firefox 3RC1 Build ?

The testcase no longer crashes with the latest build after today's checkin for bug 398332.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052810 Minefield/3.0pre ID:2008052810
On OS X 10.5.2
The test case crashes with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052704 Minefield/3.0pre

But the latest hourly from tinderbox no longer crashes (after the checking for bug 398332):
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052816 Minefield/3.0pre
Yes, it does not crash anymore with the nightly builds that I get now, both on XP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052901 Minefield/3.0pre

and on OS X:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052904 Minefield/3.0pre

I believe this can be changed to FIXED.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Could people here create a simple page which crashes when it's loaded in one of the buggy builds but doesn't when loaded in one of the latest, non-crashy builds?  Good for making sure this never starts crashing again.
Flags: in-testsuite?
Crash Signature: [@ nsHTMLReflowState::GetNearestContainingBlock]
You need to log in before you can comment on or make changes to this bug.