Closed Bug 522390 Opened 15 years ago Closed 15 years ago

Removing height property from overflow:auto div doesn't affect percentage-height children

Categories

(Core :: Layout, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: jruderman, Assigned: bzbarsky)

References

Details

(Keywords: regression, testcase, Whiteboard: [needs review])

Attachments

(4 files, 1 obsolete file)

Attached file testcase (dynamic)
      No description provided.
Attached file reference (static)
Based on layout/reftests/percent-overflow-sizing/simpleHeight100.html

When this bug is fixed, this test probably belongs in percent-overflow-sizing ;)
Hrm.  So this is actually a case where the two proposed fixes for bug 521525 are not equivalent, since the mVResize doesn't propagate through the anonymous scrolledframe.  And I don't think we can just make the scrolledframe return false from IsContainingBlock(), since the height and width on its reflow state are hacked to account for the scrollbars (see nsHTMLScrollFrame::ReflowScrolledFrame).

So we need to either fix bug 521525 by going back to using NS_FRAME_IS_DIRTY for size changes or we need to change the mVResize computation to skip over scrolled content too, not just things that are !IsContainingBlock.

I'm trying to think about other cases where this could bite (so where we have wrapper frames).  Table cells work due to the table cell hack in nsHTMLReflowState::InitCBReflowState (which I think we should push into IsContainingBlock).  Fieldsets use % sizing on the wrapper frame, so should be ok.  Any other obvious situations?
Blocks: 502288
Flags: blocking1.9.2?
blocking2.0: --- → ?
Attached patch Fix (obsolete) — Splinter Review
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #407229 - Flags: review?(dbaron)
Attachment #407229 - Flags: approval1.9.2?
Yes, from bug 502288.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Comment on attachment 407229 [details] [diff] [review]
Fix

r=dbaron, although I wonder why you need ClearAncestorIntrinsics; shouldn't NeedReflow|NeedDirtyReflow be sufficient?
Attachment #407229 - Flags: review?(dbaron) → review+
Er, yes.  It should.  Will fix that before landing.
Comment on attachment 409167 [details] [diff] [review]
That made the patch different enough it should really get another once-over...

r=dbaron
Attachment #409167 - Flags: review?(dbaron) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/3a5fa7a8fa16
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
> although I wonder why you need ClearAncestorIntrinsics

Reftest has the answer, methinks: because nsBoxFrame::MarkIntrinsiWidthsDirty dirties the cached _heights_ too, and without calling it up the parent chain height changes on XUL boxes don't work right.  At least I get reftest failures for <html:input> in XUL on height changes unless I have height changes clear ancestor intrinsics.  :(

Pushed http://hg.mozilla.org/mozilla-central/rev/5d1ed737e5be to fix the test orange.
Attached patch 1.9.2 mergeSplinter Review
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: