Intrinsic width calculation for block with overflow not visible and a percentage-height image child is incorrect

RESOLVED FIXED in mozilla25

Status

()

Core
Layout: Block and Inline
RESOLVED FIXED
5 years ago
7 months ago

People

(Reporter: Cristian Dobre, Assigned: Bem Jones-Bey)

Tracking

18 Branch
mozilla25
x86
Windows 7
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mentor=bz][lang=c++])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130104151925

Steps to reproduce:

container > div > img




Actual results:

Firefox doesn't update widths of inline-block elements( div ) when their children( img ) are resized through CSS like height: 80%. This bug appears when overflow of container is hidden or scroll.

http://jsfiddle.net/e4nAN/


Expected results:

widths should be updated, none of the other browsers have this issue
I can repro the Issue back to at least

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 ID:2010031422

=> probably already filed.
Whiteboard: [dupeme]

Updated

5 years ago
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
Hmm.  So the issue here, presumably, is that GetPercentHeight in nsLayoutUtils.cpp ends up returning auto because of the scrollframe/scrolledframe stuff or something...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: CSS inline block with image child → Intrinsic width calculation for overflow:scroll percentage-height block with a percentage-height image is incorrect
Whiteboard: [dupeme]
Duplicate of this bug: 887885
Summary: Intrinsic width calculation for overflow:scroll percentage-height block with a percentage-height image is incorrect → Intrinsic width calculation for block with overflow not visible and a percentage-height image child is incorrect
Whiteboard: [mentor=bz][lang=c++]
(Assignee)

Comment 4

4 years ago
Created attachment 772409 [details]
Standalone version of JSFiddle test case
Attachment #772409 - Attachment mime type: text/plain → text/html
Assignee: nobody → bjonesbe
(Assignee)

Comment 5

4 years ago
Created attachment 772728 [details] [diff] [review]
Fix for the bug

Change the intrinsic height calculation to use the height from the scroll frame not from it's scrollable div child when determining percentage heights so that it works the same way as reflow does in this situation.
Attachment #772728 - Flags: review?
(Assignee)

Updated

4 years ago
Attachment #772728 - Flags: review? → review?(bzbarsky)
Pushed attachment 772728 [details] [diff] [review] to try:
https://tbpl.mozilla.org/?tree=Try&rev=4ba0f67f4991
Comment on attachment 772728 [details] [diff] [review]
Fix for the bug

Very nice!  Sorry for the review lag...

r=me
Attachment #772728 - Flags: review?(bzbarsky) → review+
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/4a12e7c6f742
Flags: in-testsuite+
Keywords: checkin-needed

Comment 9

4 years ago
https://hg.mozilla.org/mozilla-central/rev/4a12e7c6f742
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Duplicate of this bug: 653739

Comment 11

7 months ago
It seems the same bug appears again (FF 50.1), overflow-y:hiddenn overflow-x: scroll (or equivalent propertie) on parent container makes the issue.

HTML
<div class="productSingle-imagesContainer">
     <a href="{{ image.path }}" class="productSingle-linkImage">
	<img src="{{ image.path }}" alt="" class="productSingle-image">
     </a>
</div>

CSS
.productSingle-imagesContainer {
    height: 300px;
    overflow-y: hidden;
    display: flex;
    width: 100%;
    justify-content: center;
}
.productSingle-linkImage {
    background: green;
    height: 100%;
}
.productSingle-image {
    width: auto;
    height: 100%;
}
Comment 11 is likely due to the nonzero min-width on the <a> coming from it being a flex-item.  Setting min-width:0 on it explicitly probably produces the behavior you want.

If not, it would be useful to link to an actual testcase, because the image dimensions matter here.
You need to log in before you can comment on or make changes to this bug.