Closed
Bug 412014
Opened 17 years ago
Closed 15 years ago
"ASSERTION: Wrong parent style context" with -moz-column, rel&abs pos
Categories
(Core :: CSS Parsing and Computation, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: assertion, testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
Loading the testcase triggers:
###!!! ASSERTION: Wrong parent style context: 'Error', file /Users/jruderman/trunk/mozilla/layout/base/nsFrameManager.cpp, line 822
Wrong parent style context: style: 0x409d4040 {}
should be using: style: 0x40a0d238 {}
Comment 1•17 years ago
|
||
Absolute-list<
Area(div)(1)@0xb0f15eb8 next-in-flow=0xb1b2acb8 {51120,1140,0,240} [state=00d00100] sc=0xb0f15978(i=0,b=0)<
>
OverflowContainers-list<
Area(div)(1)@0xb1b2acb8 prev-in-flow=0xb0f15eb8 {51120,0,0,420} [state=00d00184] sc=0xb0f15e0c(i=0,b=0)<
>
Note that the style contexts for these in-flows are different.
In this case, we're asserting that the style context for that AreaFrame on the OverflowContainers-list is wrong. Is the problem that ReResolveStyleContext doesn't manage to find it? Is it not reachable by "normal" means (walking in-flow child lists and walking through placeholders)?
Presumably a regression from bug 379349?
Blocks: 379349
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Updated•17 years ago
|
Priority: P2 → P4
Flags: wanted-next+
Flags: blocking1.9-
Updated•17 years ago
|
Flags: tracking1.9+
Reporter | ||
Comment 2•15 years ago
|
||
WFM
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 3•15 years ago
|
||
I'll add a crashtest
Reporter | ||
Comment 4•15 years ago
|
||
Crashtest added:
http://hg.mozilla.org/mozilla-central/rev/aad5b1c64ed4
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•