Closed Bug 301726 Opened 19 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)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Mail, Unassigned)

References

(
URL
)

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!)
Component: General → Style System (CSS)
Keywords: css2
Product: Firefox → Core
Version: unspecified → Trunk
Hardware: Macintosh → All
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%
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%
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 )
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
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.
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.)
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 )
> 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).
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... ;-)
> 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.
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)
Whiteboard: Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html
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
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
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?
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.
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.)
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.
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.
the overflow value does not seem to matter. The position:absolute on both outer and inner DIVs does matter.
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
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?
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 :)
http://jonas-hartmann.com/css2/index1.html works as well (that is the pure test case)
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
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?
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
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.
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?
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.

Attachment

General

Creator:
Created:
Updated:
Size: