Closed Bug 348729 Opened 18 years ago Closed 18 years ago

[FIX]Crash [@ nsRuleNode::GetParentData] with :first-letter anonymous content and removing styles


(Core :: Layout, defect, P1)






(Reporter: martijn.martijn, Assigned: bzbarsky)



(5 keywords, Whiteboard: [sg:critical] regression from 264914)

Crash Data


(3 files)

See upcoming testcase, which crashes for me on load. Usually, it crashes for me the first time. If it doesn't, try reloading a few times.

Talkback ID: TB22114083K
nsRuleNode::GetParentData   nsStyleContext::GetStyleData   nsRuleNode::WalkRuleTree   nsRuleNode::GetVisibilityData  

This is a regression.
It doesn't crash in a 2004-10-29 build, it crashes in a 2005-05-06 build.
Attached file testcase
Attached file original file
Attached patch FixSplinter Review
Yeah, this is a regression from bug 264914.  The problem is that when we remove the <tfoot>'s abs pos frame we also remove the placeholder.  So we hit that first hunk in this patch, which clobbers parentFrame to be the parent of the placeholder.  Then we use parentFrame to construct the frame constructor state for recovering the letter frames.  And the patch for bug 264914 made us use the frame constructor state to determine the float parent, so we put the float on totally the wrong float list, and things break.

The first hunk of the patch makes us not clobber parentFrame and is enough to fix this bug; the second hunk just avoids an extraneous call to GetFloatContainingBlock.
Assignee: nobody → bzbarsky
Attachment #233798 - Flags: superreview?(roc)
Attachment #233798 - Flags: review?(roc)
We should get this in on branches too.
Flags: blocking1.8.1?
Flags: blocking1.8.0.7?
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: Crash [@ nsRuleNode::GetParentData] with :first-letter anonymous content and removing styles → [FIX]Crash [@ nsRuleNode::GetParentData] with :first-letter anonymous content and removing styles
Target Milestone: --- → mozilla1.9alpha
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Comment on attachment 233798 [details] [diff] [review]

looks branch-good to me
Attachment #233798 - Flags: superreview?(roc)
Attachment #233798 - Flags: superreview+
Attachment #233798 - Flags: review?(roc)
Attachment #233798 - Flags: review+
Flags: blocking1.8.0.7? → blocking1.8.0.7+
Whiteboard: needs trunk landing
Attachment #233798 - Flags: approval1.8.1?
Attachment #233798 - Flags: approval1.8.0.7?
Fixed on trunk.
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 233798 [details] [diff] [review]

a=dbaron on behalf of drivers.  Please land on MOZILLA_1_8_BRANCH and add the fixed1.8.1 keyword once you have done so.
Attachment #233798 - Flags: approval1.8.1? → approval1.8.1+
Comment on attachment 233798 [details] [diff] [review]

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #233798 - Flags: approval1.8.0.7? → approval1.8.0.7+
Fixed for 1.8.1 and
ff2b2 debug/nightly windows/linux no crash

###!!! ASSERTION: out of bounds: 'PRInt32(aIndex) >= 0 && aIndex <= length', file /work/mozilla/builds/ff/2.0/mozilla/layout/base/nsChildIterator.h, line 133
Break: at file /work/mozilla/builds/ff/2.0/mozilla/layout/base/nsChildIterator.h, line 133
###!!! ASSERTION: Float frame has wrong parent: 'floatFrame->GetParent() == mBlock', file /work/mozilla/builds/ff/2.0/mozilla/layout/generic/nsBlockReflowState.cpp, line 835
Break: at file /work/mozilla/builds/ff/2.0/mozilla/layout/generic/nsBlockReflowState.cpp, line 835

verified fixed 1.8 should not crash browser.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20060821 Firefox/

Given the regression window this is not a problem on the 1.7/aviary branches, right?
Blocks: 264914
Flags: blocking1.7.14-
Flags: blocking-aviary1.0.9-
Whiteboard: needs trunk landing → [sg:critical] regression from 264914
Group: security
Flags: in-testsuite?
crash test landed
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ nsRuleNode::GetParentData]
You need to log in before you can comment on or make changes to this bug.