Closed
Bug 410198
Opened 17 years ago
Closed 16 years ago
Crash with an absolutely positioned element inside a inline relative one [@ nsHTMLReflowState::GetNearestContainingBlock]
Categories
(Core :: Layout: Positioned, defect)
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
Assignee | ||
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
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?
Updated•17 years ago
|
Comment 3•17 years ago
|
||
Let's make it dependent on that bug and see whether the possible patch in that bug fixes this crash.
Updated•17 years ago
|
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]
Comment 4•16 years ago
|
||
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 ?
Comment 5•16 years ago
|
||
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
Comment 6•16 years ago
|
||
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
Assignee | ||
Comment 7•16 years ago
|
||
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.
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 8•16 years ago
|
||
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?
Updated•13 years ago
|
Crash Signature: [@ nsHTMLReflowState::GetNearestContainingBlock]
Comment 9•12 years ago
|
||
Flags: in-testsuite? → in-testsuite+
Comment 10•12 years ago
|
||
Assignee: nobody → bf
You need to log in
before you can comment on or make changes to this bug.
Description
•