Open Bug 1729419 Opened 3 years ago Updated 2 years ago

Extremely tall content with nested grids inside of scrollable area (which goes away with incremental relayout)

Categories

(Core :: Layout: Grid, defect)

defect

Tracking

()

Tracking Status
firefox-esr78 --- affected
firefox-esr91 --- affected
firefox93 --- wontfix
firefox94 --- wontfix

People

(Reporter: dalban, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached file Example.html

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

Steps to reproduce:

The following HTML produces a strange result when the viewport is shrunk such that scrolling is necessary. I've included the same HTML as a file and as JS fiddle. You may need to play with the size of the red rectangle.
Everything included in the structure seems to be needed. The "src" of the image does not need to be valid, but an src must be given.
I'm aware it's an odd structure by itself. It started as a more complex structure for a sidebar flyout but I removed as many elements and styles as I could whilst still producing the issue.

https://jsfiddle.net/cLgm7ptr/

Instructions:
Start with the viewport vertically large enough to fit the image and red rectangle. Then shrink the viewport so it doesn't fit.

Using FF ver 91.0.2, which claims it's up to date.

Actual results:

When the content doesn't fit vertically without scrolling, a scrollbar is created but it's (practically) infinitely long and the content becomes difficult to find (not actually sure if it's rendering).

Expected results:

When the content doesn't fit vertically without scrolling, a scrollbar should be created that is proportional to the difference between the content height and the viewport height. This works as I would expect in Chrome/Edge.

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

Component: Untriaged → Layout: Flexbox
Product: Firefox → Core

Thanks for the bug report! I can reproduce, and I've reduced the testcase a bit further. The bug reproduces without any flexbox, so I think it's really an issue with nested grids. Reclassifying accordingly and needinfo'ing mats to take a look when he can.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Component: Layout: Flexbox → Layout: Grid
Ever confirmed: true
Version: Firefox 91 → Trunk

(In reply to Daniel Holbert [:dholbert] from comment #2)

I think it's really an issue with nested grids [...] needinfo'ing mats to take a look when he can.

er, needinfo'ing for real now. :)

Flags: needinfo?(mats)

Here's my reduced testcase, which reproduces the bug immediately when loaded. (note: might require scrollbars-that-occupy-space, i.e. I'm not sure if it repro's on Mac with overlay scrollbars)

STR:

  1. Load testcase (and do not have your browser devtools open)

EXPECTED RESULTS: The black-bordered box should contain a short teal area and a taller lime area, and should have a scrollbar with only a little room to scroll.

ACTUAL RESULTS: No lime is visible. The black-bordered box has a tiny scrollbar indicating that it's got an extremely long way to scroll. Also, the purple dotted bottom-border is clipped (you can't reach it by scrolling).

Note: If I have browser devtools open with the "Inspector" tab selected, then the bug doesn't reproduce. Similarly: if the bug has reproduced, I can "fix" it by opening devtools and selecting the inspector tab. So, this fixes itself with a little bit of additional relayout (which devtools triggers); or perhaps it oscillates between a broken/working state, and devtools happens to do the right amount of layout.

Summary: Strange scrolling behaviour with certain combination of fixed, grid, flex and img → Extremely tall content with nested grids inside of scrollable area (which goes away with incremental relayout)

Here's a reference case. This is identical to the testcase except for the fact that I've provided a width style on the <canvas> element (which is my stand-in for the img in the reporter's original testcase).

For some reason, having this explicit width style is sufficient to avoid the issue.

Note, looks like this is an ~old regression, with this regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=30ea2905130e85f9e1d8d56fa3097901eec6514b&tochange=67cd1ee26f2661fa5efe3d952485ab3c89af4271

In that range, I'm guessing that this started with bug 1308876's commits, since that bug was about some complexities around inline-block reflow, and this testcase does have an inline-block.

(There's one grid-related commit in the regression range, but it's just to do with serialization, so I suspect it's unrelated.)

Keywords: regression
Regressed by: 1308876
Has Regression Range: --- → yes

Set release status flags based on info from the regressing bug 1308876

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(MatsPalmgren_bugz)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: