1760571 - I have parent div with scrollbar and child div that scaled to 0.5. The parent scrollbar show wrong scroll size (original size)

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[gregory]

Attachment: FireFox-Bug.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Steps to reproduce:

1. Create div with "overflow: auto"
2. Create child div
3. Scale child div and put image inside the div
4. Scale child div to 0.5

Actual results:

When after scaling the image is fully visible in parent div scrollbar of parent show wrong size of scrollers.

Expected results:

The parent scrollers must be much to scaled size of child div.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alice0775 White]

gregory, could you attach a testcase or url to reproduce the problem?

Comment 3

[gregory]

Attachment: FireFox-Bug.rar

Comment 4

[gregory]

(In reply to Alice0775 White from comment #2)

gregory, could you attach a testcase or url to reproduce the problem?
I add new rar file that include a test page

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter's testcase)

Here's the reporter's testcase, but with a large turquoise <canvas> swapped in for the large <img> so that it can be a simple standalone HTML file instead of a .rar.

I do see something like the reporter's screenshot, but this is the correct rendering and matches other browsers (unless I'm missing something).

The thing that's causing content to be clipped (as shown in the screenshot) is that the testcase has overflow:hidden on the scaled div (the "child div" on comment 0).

So what happens is:

• That "child div" div gets laid out according to the rules of CSS and ends up being as wide as its container (as width:auto in-flow divs typically do, according to the rules of CSS).
• The image (or <canvas> in my attached testcase) is much wider and overflows off the right side of the child-div. The piece that runs off the right side is clipped because the div has overflow:hidden (though you wouldn't normally be able to tell if there weren't a transform, because that part is also offscreen).
• When painting the div, we apply the transform:scale(0.5) to it, which scales it down. Now you can see the fact that the overflowing parts have been (correctly) clipped.

This is what happens in Firefox as well as in other browsers, I think?

If you want the image not to be clipped, you should be sure that its container isn't going to clip it (i.e. its container shouldn't have overflow:hidden), or you should make sure that its container is at least as wide as the image (so that none of the image overflows past the edge of the container).

Comment 6

[Daniel Holbert [:dholbert]]

Ah, sorry, I think I was over-focused on the "image border" arrow in comment 0 and I thought you were filing a bug about the image being clipped -- I missed the point about the scrollbar, but I see that now.

It sounds like your bug report is that the horizontal scrollbar (shown in your comment 0 screenshot) is the wrong size; but I'm not seeing any horizontal scrollbar at all with your testcase (or with my simplified attached testcase).

Is there an additional step required? Maybe I'm missing some additional factor that's needed to reproduce the bug, or maybe there's an additional piece of the testcase that was missing from your .rar attachment?

Comment 7

[Daniel Holbert [:dholbert]]

I do see that the page has a super-tall vertical scrollbar in the attached testcase; but that seems to be a thing that happens in all browsers, not a Firefox-specific behavior. Safari and Chrome seem to render the testcase the same as Firefox, as far as I can tell, which is an indication that our behavior is likely required by the spec, or at least by compat/interop requirements.

If there's a Firefox-specific issue that you're reporting here, could you help to clarify what that issue is? (And post another testcase to demonstrate it, if necessary -- ideally as a standalone HTML file, rather than a .rar archive. rar archive testcases are kind of awkward, due to needing to be downloaded/extracted locally with a nonstandard rar archive tool that not everyone may have freely available.)

Thanks!

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Rendering matches other browsers and we're waiting for the reporter, so closing as incomplete for now as this is not actionable. Feel free to reopen with new information though.