Closed
Bug 301726
Opened 20 years ago
Closed 17 years ago
Calculation of overflow: auto in 2 cascaded boxes; outer having overflow: auto, inner having overflow: auto height: 100% width: 200%
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: Mail, Unassigned)
References
()
Details
(Keywords: css2, Whiteboard: [reflow-refactor] Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html)
Attachments
(1 obsolete file)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050719 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050719 Firefox/1.0+
In Firefox 1.0.x it was possible to create a Column Style Layout like this one:
http://jonas-hartmann.com/css/finder.jpg
In Deer Park Alpha a layout like above (finder.jpg) can't be created cause
height: 100% of the columns does not calculate by the formular ((parent box
height) - (parent box scrollbar height)). To me the CSS specs are not fixed on
this issue regarding overflow: auto (they are so on overflow: scroll; ) - also
see http://www.w3.org/TR/CSS21/visufx.html#overflow about this topic.
See the comparison shots:
http://jonas-hartmann.com/css2/firefox_deer_park_nightly.jpg
http://jonas-hartmann.com/css2/firefox_1.0.x.jpg
Reproducible: Always
Steps to Reproduce:
1. Prepare Firefox 1.0.x and Firefox Deer Park Nightly to see the Comparison
2. Start http://jonas-hartmann.com/css2/index1.html in each Browser
3. Scroll to the right in each Browser
4. Notice the Difference
Actual Results:
Scrollbars to reach scrollbars instead of a horizontal scrollbar (of the outer
box) and a vertical scrollbar (of the inner box)
Expected Results:
overflow: auto should behave like in Firefox 1.0.x - else a mutiple column
layout within a horizontal scrollable container is not creatable.
Real World Examples:
http://jonas-hartmann.com/css/index2.html
http://jonas-hartmann.com/css/index.html ( not showing the error always, try to
resize the user_agent's window - it is just to show that there is no smooth way
to work around the problem )
Real World Usage:
http://jonas-hartmann.com/rach/ (resize the window so that scrollbars are shown
for sure!)
Reporter | ||
Updated•20 years ago
|
Component: General → Style System (CSS)
Keywords: css2
Product: Firefox → Core
Version: unspecified → Trunk
Reporter | ||
Updated•20 years ago
|
Hardware: Macintosh → All
Reporter | ||
Updated•20 years ago
|
Summary: Calculation of Overflow: Auto in 2 Cascaded Boxes, Inner Box having height: 100%; width: 200% (colum layout) → Calculation of Overflow: Auto in 2 Cascaded Boxes, Inner Box having height: 100%; width: 200%
Reporter | ||
Updated•20 years ago
|
Summary: Calculation of Overflow: Auto in 2 Cascaded Boxes, Inner Box having height: 100%; width: 200% → Calculation of overflow: auto in 2 cascaded boxes; outer having overflow: auto, inner having overflow: auto height: 100% width: 200%
Reporter | ||
Comment 1•20 years ago
|
||
can one say something about
"auto
The behavior of the 'auto' value is user agent-dependent, but should cause a
scrolling mechanism to be provided for overflowing boxes."
and:
"In the case of a scrollbar being placed on an edge of the element's box, it
should be inserted between the inner border edge and the outer padding edge. Any
space taken up by the scrollbars should be subtracted from the computed
width/height, thus preserving the inner border edge."
(both from http://www.w3.org/TR/CSS21/visufx.html#overflow )
Comment 2•19 years ago
|
||
I believe that current builds are doing this correct.
Height:100% means that the inner box should be as high as the containing box.
Current builds give a 100px computed height for the inner box (as high as the containing box), while Mozilla1.7 gives 84px.
I think Mozilla does that, because it mistakingly calculates the height of containing block minus the horizontal scrollbar height.
Component: Style System (CSS) → Layout
QA Contact: general → layout
Comment 3•19 years ago
|
||
roc, dbaron, what's the right layout here?
I think that 200% of 100px is correct, but like you guys I'm not 100% certain.
Comment 5•19 years ago
|
||
All browsers seem to behave the same on the testcase and Opera and Firefox interoperate on the "real-life" website. (Showing one outer scrollbar and an inner scrollbar.)
Reporter | ||
Comment 6•19 years ago
|
||
I am still looking for some comments on:
"In the case of a scrollbar being placed on an edge of the element's box, it
should be inserted between the inner border edge and the outer padding edge. Any
space taken up by the scrollbars should be subtracted from the computed
width/height, thus preserving the inner border edge."
in the CSS3 spec [1] I cannot find this paragraph - so what does this mean?
[1]: http://www.w3.org/TR/2002/WD-css3-box-20021024/#overflow
Many layouts use floats these days so I think this topic here is important.
(maybe this is important as well http://www.w3.org/TR/2002/WD-css3-box-20021024/#flow-root )
Comment 7•19 years ago
|
||
> in the CSS3 spec [1] I cannot find this paragraph - so what does this mean?
The CSS2.1 candidate recommendation on this is actually newer than the last CSS3 draft (which is not a spec).
Reporter | ||
Comment 8•19 years ago
|
||
Boris well I dont actually know how the mozilla-dev-team's philosophy is on things that are working as intendet by css3-drafts and would break that if they worked like in css 2.1. thats why i ask.
Still I am not fully convinced that the inner boxes height should be as high as the outer boxes height without scrollbars IF there are scrollbars AND the scrolling overflow mechanism is set to overflow:auto (instead to overflow:scroll).
If my point is wrong, explain it shortly and resolve the bug to worksform... ;-)
Comment 9•19 years ago
|
||
> things that are working as intendet by css3-drafts and would break that if they
> worked like in css 2.1.
The CSS Working Group is clear on this. In case of conflict, CSS2.1 is authoritative at the moment.
Reporter | ||
Comment 10•19 years ago
|
||
so what about this in the css 2.1 specs: "...Any
space taken up by the scrollbars should be subtracted from the computed
width/height, thus preserving the inner border edge."
doesn't this mean that the height of a box that overflows is calculated by the height of the outer substracted by the scrollbar's graphics height, in a scenario like this?:
#outerbox {
width: 200px;
height: 100px;
overflow: auto;
}
#innerbox {
width: 200%;
height: 100%;
overflow: auto;
}
(check http://jonas-hartmann.com/css2/index1.html - scroll the bottom scrollbar to the right)
Updated•19 years ago
|
Whiteboard: Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html
Updated•19 years ago
|
Whiteboard: Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html → [reflow-refactpr] Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html
Reporter | ||
Updated•19 years ago
|
Whiteboard: [reflow-refactpr] Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html → [reflow-refactor] Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html
Reporter | ||
Comment 11•19 years ago
|
||
Any News?
For now I would be intrested if this "bug" is a valid bug or not. Can one confirm that this is a bug?
Comment 12•19 years ago
|
||
See the status whiteboard -- I've heard absolutely 0 response from the CSS working group on the matter.
I think there is some stuff that we fix up for percentage widths in cases like this but that we don't fix up for percentage heights.
Reporter | ||
Comment 14•19 years ago
|
||
And why not, exactly?
I don't know. Probably either because nobody filed a bug about it or because it's faster.
(In theory, I agree that this is a valid bug -- width and height should work the same. But percentage heights really are a hack to begin with, and I'm not sure how much we want to penalize the common case to make this obscure case work.)
Reporter | ||
Comment 17•19 years ago
|
||
Well, if its a bug, why not fix it? So much work? I am no C-Guru, else I'd offer my work and efforts.
In FireFox 1.0 the realworld example I provived worked prefectly. In 1.5 it did not. So imho something that worked like the specs tell (just my opinion) broke.
Why not fix it again?
Further its not an obscure thing - its just not used very much and its the only way to my knowledge to create a horizontal scrolling layout. Yes its a float hack, and?
So - is this WONTFIX? Or whats your opinion on this?
Please don't add long comments repeating the same thing in response to everything I say. Bugs with more comments are less likely to be fixed.
Reporter | ||
Comment 19•19 years ago
|
||
Sry.
See, in particular, the "XXX" comments about absolutely positioned children in nsHTMLScrollFrame::ReflowContents :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsGfxScrollFrame.cpp&rev=3.259&mark=622-624,639-641#573
This is another case of that same problem.
Comment 21•19 years ago
|
||
the overflow value does not seem to matter. The position:absolute on both outer and inner DIVs does matter.
Comment 22•19 years ago
|
||
Comment on attachment 218671 [details]
No reflow when using javascript to resize an absolutely positioned DIV inside another absolutely positioned DIV.
that's bug 227121.
Attachment #218671 -
Attachment is obsolete: true
Reporter | ||
Comment 23•19 years ago
|
||
I have retestet this problem on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060613 Minefield/3.0a1
Is there already a decission made up if to deal with this issue of incorrect rendering described here, or will it be left out because it would make rendering too slow or something like that and this report resolved to wontfix?
Reporter | ||
Comment 24•17 years ago
|
||
Hello,
I have good news: I have tested this on the current nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121405 Minefield/3.0b3pre
I will test it on Mac nightly soon.
The bug seems to be gone - both relating test cases seem to work now!
http://jonas-hartmann.com/css/index2.html (testcase)
http://jonas-hartmann.com/rach/ (real world scenario)
I do not feel to have enough responsibility to set this bug from UNCONFIRMED to FIXED, if you feel to have that, and tested it too. Please do so.
If you read this and are related to fixing this bug. Thank you so much :)
Reporter | ||
Comment 25•17 years ago
|
||
http://jonas-hartmann.com/css2/index1.html works as well (that is the pure test case)
Reporter | ||
Comment 26•17 years ago
|
||
Works for me on Mac nightly too:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007121404 Minefield/3.0b3pre
Comment 27•17 years ago
|
||
Probably fixed by the checkin for bug 375304. Could someone write up a reftest for this bug? Just an "expected" vs "actual" rendering (two separate HTML pages). I'll make sure it gets checked in!
Depends on: 375304
Flags: in-testsuite?
Reporter | ||
Comment 28•17 years ago
|
||
I took a look at reftests but can't quite figure out how to create a test vs reference scenario.
Despite that, I have updated my stripped down test case, maybe one can create a reftest by that:
http://jonas-hartmann.com/css2/index1.html
Reporter | ||
Comment 29•17 years ago
|
||
http://jonas-hartmann.com/css2/index1b.html shows what http://jonas-hartmann.com/css2/index1.html SHOULD NOT render like. Although its only an approximation of PRE Gecko/2007121405 Minefield/3.0b3pre rendering IN Gecko/2007121405 Minefield/3.0b3pre
Sorry, can't do it better.
Reporter | ||
Comment 30•17 years ago
|
||
Reference: http://jonas-hartmann.com/css2/index1_reference.html
(Working reference in rv:1.9b3pre, slightly wrong rendering in rv:1.8.1.11 AFTER scrolling right)
Test: http://jonas-hartmann.com/css2/index1_test.html
(Working test in rv:1.9b3pre, wrong rendering in rv:1.8.1.11)
If you do not interact with the scrollbars then this might be an appropriate reftest?
Comment 31•17 years ago
|
||
Jonas, thanks a ton! I checked in those tests, as well as another test I thought of to test this bug, based on reading the patch that fixed it again.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•