1680049 - Intrinsic size inside scroller might be wrong with percentage bsize values.

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[gregor]

Attachment: HTML file that demonstrates the problem

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I opened the attached HTML file with Firefox.

Actual results:

The li elements are displayed wider than the img elements as soon as the scrollbar is displayed. This causes the image numbers to be positioned incorrectly. When there's no scrollbar (resize the list or remove some images to see it), the li's have the same width as the images they contain. I also tried it with Chrome and there it worked.

Expected results:

I think the li's should have the same width as the images they contain, no matter if there's a scrollbar or not.

Comment 1

[Raluca Popovici, Desktop QA]

Hi,
I can reproduce this bug on my machine Win 10 on the latest Firefox versions.
With Chrome, the li elements are displayed correctly

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: More reduced test-case.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

So, this is about the intrinsic size we calculate for the percentage. This area is generally pretty bogus in all browsers, see bug 764076, bug 1677353, etc...

The issue is that we need to figure out the image width without doing layout to try to compute the size of the flex item (or the inline-block in my test-case), so we try to resolve the percentages of its ancestors, so we end up resolving the 100% of 200px, but that's not correct because there's a scrollbar.

We can't know there's a scrollbar until we've known the width in your test-case, though in the test-case above (comment 2) we can (as I've used overflow-x: scroll).

So comment 2 should probably work. Comment 0 is... a bit more complicated :)

Back-computing percentages is just so awful. I wonder if this is a regression or never worked though.

Comment 4

[Alin Ilea, Desktop Test Engineering]

Hi,
I tried to find a regression range, but I am able to reproduce this issue in Fx60 (2018-03-02) as well, using Ubuntu 18.04. Based on this I don't think this is a regression, at least not a recent one.