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)
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)
222 bytes,
text/html
|
Details | |
138 bytes,
text/html
|
Details | |
4.28 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
3.60 KB,
patch
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
Based on layout/reftests/percent-overflow-sizing/simpleHeight100.html When this bug is fixed, this test probably belongs in percent-overflow-sizing ;)
Assignee | ||
Comment 3•15 years ago
|
||
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?
Assignee | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 4•15 years ago
|
||
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #407229 -
Flags: review?(dbaron)
Attachment #407229 -
Flags: approval1.9.2?
This is a regression, right?
Assignee | ||
Comment 6•15 years ago
|
||
Yes, from bug 502288.
Keywords: regression
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Attachment #407229 -
Flags: approval1.9.2?
Whiteboard: [needs review]
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+
Assignee | ||
Comment 8•15 years ago
|
||
Er, yes. It should. Will fix that before landing.
Assignee | ||
Comment 9•15 years ago
|
||
Attachment #407229 -
Attachment is obsolete: true
Attachment #409167 -
Flags: review?(dbaron)
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+
Assignee | ||
Comment 11•15 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/3a5fa7a8fa16
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 12•15 years ago
|
||
> 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.
Assignee | ||
Comment 13•15 years ago
|
||
Assignee | ||
Comment 14•15 years ago
|
||
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/301b3fe25335
blocking2.0: ? → ---
status1.9.2:
--- → final-fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•