Closed
Bug 350456
Opened 19 years ago
Closed 19 years ago
[reflow branch] Crash with display: table-row-group in xul
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Assigned: dbaron)
References
Details
(Keywords: crash, testcase, Whiteboard: [box/block])
Attachments
(1 file)
|
286 bytes,
application/vnd.mozilla.xul+xml
|
Details |
See upcoming testcase, which crash in the latest reflow branch build.
Basically, the testcase consists of this:
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<box style="display: table-row-group;">
</box>
</window>
| Reporter | ||
Comment 1•19 years ago
|
||
| Reporter | ||
Comment 2•19 years ago
|
||
It's just not table-row-group, table-row and table are also crashing. Probably every table display type is crashing on the reflow branch.
Comment 3•19 years ago
|
||
The basic problem is that there is no parent reflow state for the outer table, and therefore there is no mCBReflowState for the inner table (since the outer is not a block). This causes us to assert and then crash in InitConstraints.
This item from http://wiki.mozilla.org/Gecko:Reflow_Refactoring is probably relevant:
"Sort out the behavior of nsHTMLReflowState::InitConstraints when
parentReflowState is null. This happens for reflow roots and for frames
being reflowed as a child of a box (via nsFrame::BoxReflow). The current
behavior seems wrong."
Should we just be wrapping any non-box kids of a box in a block?
Comment 4•19 years ago
|
||
*** Bug 351627 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 5•19 years ago
|
||
(In reply to comment #3)
> Should we just be wrapping any non-box kids of a box in a block?
Yes. That would solve a huge number of problems, including bug 321402 / bug 320502, but it's not trivial to do.
| Assignee | ||
Comment 6•19 years ago
|
||
Another nice way to fix this would be to propagate containing block width/height down the reflow state chain and get rid of mCBReflowState.
| Assignee | ||
Comment 7•19 years ago
|
||
I suspect the only reason this particular testcase regressed on the reflow branch is that I'm now breaking the reflow state chain when crossing into and out of box land.
Comment 8•19 years ago
|
||
Comment 7 is right.
Just propagating the things we want out of mCBReflowState should be pretty straightforward, I think. I'll take a shot at it.
Comment 9•19 years ago
|
||
Er, not as straightforward as I thought. We do a bunch of walking starting with mCBReflowState, and have that loop in nsHTMLReflowState::InitResizeFlags adding resize bits.
| Assignee | ||
Comment 10•19 years ago
|
||
I think it would need to be replaced by a width, a height, and a frame pointer.
| Assignee | ||
Comment 11•19 years ago
|
||
I said I'd fix bug 321402 for the alpha, so this should just get fixed by that...
| Assignee | ||
Updated•19 years ago
|
Whiteboard: [box/block]
| Assignee | ||
Comment 12•19 years ago
|
||
Fixed on reflow branch.
Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v <-- nsFrame.cpp
new revision: 3.679.2.10; previous revision: 3.679.2.9
done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 13•19 years ago
|
||
Except that fix introduced some off-by-padding/border/margin problems...
| Assignee | ||
Updated•19 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
| Assignee | ||
Comment 14•19 years ago
|
||
OK, fixed again.
Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v <-- nsFrame.cpp
new revision: 3.679.2.12; previous revision: 3.679.2.11
done
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•