Closed Bug 366952 Opened 13 years ago Closed 13 years ago

"ASSERTION: used padding property missing (out of memory?)" involving -moz-inline-grid and position: fixed

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: dbaron)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase, Whiteboard: [patch])

Attachments

(2 files, 3 obsolete files)

Attached file testcase
Loading this testcase triggers:

###!!! ASSERTION: used padding property missing (out of memory?): 'p', file /Users/admin/trunk/mozilla/layout/generic/nsFrame.cpp, line 731
So the problem is that in nsHTMLReflowState::InitConstraints for the div with the padding-right there is no parentReflowState, so we never call InitOffsets(), so never compute the padding...

This is the "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." item in the to-do list on http://wiki.mozilla.org/Gecko:Reflow_Refactoring.
Flags: blocking1.9?
OS: Mac OS X → All
Hardware: Macintosh → All
Assignee: nobody → dbaron
Attached patch possible patch (untested) (obsolete) — Splinter Review
This is untested; I originally wrote it while working on bug 359769.
This patch breaks a bunch of things (HTTP auth dialogs to narrow, scrollbars a pixel or two off), as I'd noticed the previous time I tried doing this.  Need to figure out why.
Attached patch patch (obsolete) — Splinter Review
This starts constructing the padding and border on the reflow state properly for reflow states with no parent, and switches the box/block adaptation code to using the reflow state border/padding on the block inside rather than the box's notion of border/padding, which fixes the regressions I was seeing without that change (and makes sense).
Attachment #251603 - Attachment is obsolete: true
Attachment #251688 - Flags: superreview?(roc)
Attachment #251688 - Flags: review?(roc)
Status: NEW → ASSIGNED
Whiteboard: [patch]
Shouldn't we also ensure that the computed width/height doesn't go below 0?  Or are we guaranteed that it can't?
Attached patch patch (obsolete) — Splinter Review
Yep.

This addresses Boris's comment.
Attachment #251688 - Attachment is obsolete: true
Attachment #251688 - Flags: superreview?(roc)
Attachment #251688 - Flags: review?(roc)
What about the 4th hunk in nsFrame::BoxReflow and the nsHTMLReflowState changes?
Attached patch patchSplinter Review
Right.
Attachment #251690 - Attachment is obsolete: true
Attachment #251703 - Flags: superreview?(roc)
Attachment #251703 - Flags: review?(roc)
r=bzbarsky, for what it's worth.  But I'm not as familiar with the box code as you guys, so it's probably still worth roc looking...
Attachment #251703 - Flags: superreview?(roc)
Attachment #251703 - Flags: superreview+
Attachment #251703 - Flags: review?(roc)
Attachment #251703 - Flags: review+
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Flags: blocking1.9?
Flags: in-testsuite?
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
Comment on attachment 251703 [details] [diff] [review]
patch

>+    InitOffsets(aContainingBlockWidth, aBorder, aPadding);
>+    // Override mComputedMargin since reflow roots start from the
>+    // frame's boundary, which is inside the margin.
>     mComputedMargin.SizeTo(0, 0, 0, 0);
>-    mComputedPadding.SizeTo(0, 0, 0, 0);
>-    mComputedBorderPadding.SizeTo(0, 0, 0, 0);
This caused bug 391358.
(I verified by manually applying these specific changes to a working build.)
Blocks: 391358
No longer blocks: 391358
Depends on: 391358
You need to log in before you can comment on or make changes to this bug.