Open Bug 1281713 Opened 8 years ago Updated 2 years ago

intrinsic width of parent with overflow-x:scroll not computing correctly with child image with height:100%

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

People

(Reporter: iamerikbrown, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase) 

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Set an image's height to 100% and set it's parent's height to 100% and it's parent's parent height to a fixed value. Set either div with overflow-x: scroll.
This can be seen here: https://jsfiddle.net/yj32ous4/9/

Likewise, a similar result can be seen with the parent's parent being absolutely positioned with top:0 and bottom:0.
This can be seen here: https://jsfiddle.net/yj32ous4/10/

Setting inline-block for the image's parent causes both examples to be fixed.


Actual results:

The image parent's width is too wide. In the case of the scrollbar the parent width is what would be if the horizontal scrollbar is not present. In the case of the absolutely positioned div, the image parent's width is the source image's width.


Expected results:

The parent div should have shrinkwrapped to the image. This behavior is present in the latest versions of Chrome and IE.
Keywords: css3
I meant to say "Setting inline-block for the image's parent to _inline_ causes both examples to be fixed."
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
> I meant to say "Setting inline-block for the image's parent to _inline_
> causes both examples to be fixed."

By definition, 'height' does not apply to non-replaced inline elements.
https://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced


Reduced test
------------

http://www.gtalbot.org/BugzillaSection/Bug1281713-width-100-percent.html

Firefox 50.0a1 buildID=20160623072443 will render a red rectangle which is 5 times the scrollbar width.
Chrome 51.0.2704.106, Chrome 53.0.2774.3, IE11 and Edge do not render any red.
Opera 12.16 (Presto engine) does not render any red but the div computed width is, I believe, larger (20%) than it should be.

- - - - - - 

Erik, thanks to this test, I believe Firefox has indeed a bug (spec violation). But I am not 100% sure of this, at this point. I would need more time to examine the CSS2.1 specification. Or someone like Boris Zbarsky or David Baron or Elika Etemad should make that call. 

And also I have not searched for duplicates either.

Your original test involves 10.3.5 (shrink-to-fit width algorithm), 10.3.2 and 11.1.1 sections of CSS2.1

One thing I am sure of is that we did not do any test on height percentage with scrollbar in the CSS2.1 test suite (Hilbrand Edskes and I did several with max-height and scrollbar width though) and, as you discovered, mainstream browsers do not agree on how to render such test.
Keywords: css3 → testcase
OS: Unspecified → All
Hardware: Unspecified → All
Version: 47 Branch → Trunk
I have re-examined the reduced test again along with the spec and I still believe there is a spec violation here. 

Let us postulate that the scrollbar width is 15px (it is rigidly fixed to 15px in Google Chrome but not in Firefox as it uses the os setting for that); the scrollbar width is user-settable in many operating systems and it could also vary from browser theme to browser theme. Then the following should occur.

The image (the green rectangular area) should be 85px tall because
"
space taken up by the scrollbars should be taken out of (subtracted from the dimensions of) the containing block formed by the element with the scrollbars
" 
https://www.w3.org/TR/CSS21/visufx.html#overflow

so we substract 15px for the scrollbar width from the 100px content height of the <div>; so only 85px of the div is available for the image in the vertical axis.

The image (the green rectangular area) should be 425px wide because 
"
if 'width' has a computed value of 'auto', 'height' has some other computed value, and the element does have an intrinsic ratio; then the used value of 'width' is:

    (used height) * (intrinsic ratio)
"
https://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width

(85px mult by 5 == 425px because intrinsic ratio of the image is 5:1).


The offsetHeight of the div should be 100px. 
The offsetWidth of the div should be 440px. (expected)

In Firefox, the offsetWidth of the div is 5 mult by 100 + 15px == 515px (actual) which is 75px (5 times the scrollbar width) greater than expected.

- - - - - - 

I have searched for several hours the components "Layout: Images", "Layout: Floats", "Layout: Block and Inline" looking for a duplicate and did not find any. There could be a duplicate for this bug... but I have not found it.

Marking as NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
We should also submit a similar test to the CSS2.1 test suite and then make this bug report block bug 605520.
I agree with gtalbot's analysis, this is a bug in Gecko.
Blocks: css2.1-tests
Summary: Parent element's width not computing correctly with child image height set to 100% → intrinsic width of parent with overflow-x:scroll not computing correctly with child image with height:100%
I think the code for this is in nsLayoutUtils::IntrinsicForAxis, below the comment that says:
    // Handle elements with an intrinsic ratio (or size) and a specified
    // height, min-height, or max-height.
Note that the helper functions GetPercentBSize and GetBSizeTakenByBoxSizing exist only to support that code.
Erik,

I added a comment into the 3 submitted tests giving you credit for originally creating a test and reporting a similar (or related) test.

Chrome 51.0.2704.106 and Chrome 53.0.2774.3 used to pass these 3 tests and the one in comment 2. Now, Chromium 80.0.3987.132 fails these 4 tests. So, I just filed
Issue 1060904: intrinsic width of parent with overflow-x:scroll not computing correctly with child image with height:100%
https://bugs.chromium.org/p/chromium/issues/detail?id=1060904

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.