Calculation of overflow: auto in 2 cascaded boxes; outer having overflow: auto, inner having overflow: auto height: 100% width: 200%

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Jonas Hartmann, Unassigned)

Tracking

({css2})

Trunk
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor] Waiting on http://lists.w3.org/Archives/Public/www-style/2006Jan/0034.html, URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

13 years ago
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

13 years ago
Component: General → Style System (CSS)
Keywords: css2
Product: Firefox → Core
Version: unspecified → Trunk
(Reporter)

Updated

13 years ago
Hardware: Macintosh → All
(Reporter)

Updated

13 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

13 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

13 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 )
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.

Comment 5

13 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

13 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 )
> 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

13 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... ;-)
> 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

13 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)
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
(Reporter)

Updated

13 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

13 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?
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

13 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

13 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

13 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

12 years ago
Created attachment 218671 [details]
No reflow when using javascript to resize an absolutely positioned DIV inside another absolutely positioned DIV.

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
(Reporter)

Comment 23

12 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

11 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

11 years ago
http://jonas-hartmann.com/css2/index1.html works as well (that is the pure test case)
(Reporter)

Comment 26

11 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
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

11 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

11 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

11 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?
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
Last Resolved: 11 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.