Closed Bug 1938619 Opened 2 months ago Closed 23 days ago

Certain CSS Grids with flexible tracks end up too wide (leading to e.g. overflow/misalignment on about:processes)

Categories

(Core :: Layout: Grid, defect)

Firefox 135
defect

Tracking

()

VERIFIED FIXED
136 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox133 --- unaffected
firefox134 --- unaffected
firefox135 + disabled
firefox136 + verified

People

(Reporter: alice0775, Assigned: alaskanemily)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: nightly-community, regression, webcompat:platform-bug)

Attachments

(5 files)

Attached image screenshot

Steps to reproduce:

  1. Open any web pages such as youtube
  2. Open about:processes in a new tab
  3. Observe for a while

Actual results:
Header and column positions are misaligned in sometimes.
So, Memory and CPU usage pushed off screen.
See attached screenshot

OS: Unspecified → Windows 11
Hardware: Unspecified → Desktop
Version: unspecified → Firefox 135
Component: Layout → Layout: Grid
Summary: Header and column positions are misaligned in about:processes → Header and column data positions are misaligned in about:processes

:alaskanemily, since you are the author of the regressor, bug 1916849, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(emcdonough)

This affects Linux as well. It's a bit annoying since I can no longer see any meaningful details about the process list (or terminate one) when those columns are all shoved off the screen with no ability to reach them. Scrolling doesn't work either.

I'm also on the latest nightly build.

I'll add that it makes about:processes rather unusable since the pertinent information on CPU and RAM usage are shoved off the edge, as well as the close button to terminate a process (useful when I'm tracking down a misbehaving page).

Blocks: 1938461

A workaround: Launch inspector in about:processes, change overflow-x: hidden in <body> to scroll.
Setting to S3 due to being able to be worked around, but there is a case for S2.

At any rate, I think a partial cause may be the long, long string in the first entry i.e. "N active threads out of M [...]"

Severity: -- → S3

I've just been doing the following to limit the size of the table cells:

(()=>{document.querySelectorAll('td').forEach(e=>e.style.maxWidth='80vw')})()

I tried just adding a style:

(()=>{document.head.insertAdjacentHTML('beforeend','<style>td{max-width:80vw!important}</style>')})()

But the page's CSP prevents that.

Bookmarklets also don't work so I can't just one-click the problem away like I usually do.

workaround userContent.css

@-moz-document  url-prefix("about:processes") {
  tr {
    grid-auto-rows: auto !important;
  }
  
  td.name.indent {
    max-height: none !important;
    & span+span {
      white-space: pre-wrap !important;
    }
  }
}

I believe that the issue here relates to measuring available space for spanning grid items with flex tracks. Currently, definite-sized tracks do not reduce this space at all.
This wasn't an issue before my change because the column with the size 1fr got an intrinsic size of zero (incorrect, but in this circumstance, compatible and visually correct). I should be able to fix at least the simple case, as is demonstrated here, relatively easily.

Assignee: nobody → emcdonough
Flags: needinfo?(emcdonough)

[Tracking Requested - why for this release]: layout regression, which might be triggered by real web content (in the same way that it's triggered here for about:processes). It sounds like a fix will be ready soonish, per end of comment 8 (during the about-to-begin Nightly 136 cycle), so it's worth keeping this on the 135 radar to help us remember to uplift to 135 if/when the time is right.

Chrome and Safari correctly layout the standalone test case

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

Attached file bug1938619.html

Including a reduced version of the testcase.
I'm including this to demonstrate a standalone, cut-down version of specifically what about:processes is doing. After some investigation and discussion with dholbert, the table layout seems like a bit of a red-herring as forcing the tr to be display: grid is actually foiling a lot of how table layout actually works.

Attached file bug1938619_grid.html

This is a further reduced version of the testcase that doesn't use table layout at all.

The bug is marked as tracked for firefox135 (beta). However, the bug still has low severity.

:fgriffith, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(fgriffith)

Discussed with dholbert. Bumping to S2. Looking for a fix soon in 136 regardless, with a flag to consider uplift.

Flags: needinfo?(fgriffith)
Severity: S3 → S2

(In reply to Frank Griffith Jr from comment #16)

Looking for a fix soon in 136 regardless.

(with intent to uplift to 135, per the tracking+ for 135 status.)

Note, we've now got one report of an actual site that's tripping over this same issue; see bug 1940486.

[generalizing bug title to focus on the underlying issue rather than on about:processes, to avoid confusion when linking this as the root cause of site issues like bug 1940486]

OS: Windows 11 → All
Hardware: Desktop → All
Summary: Header and column data positions are misaligned in about:processes → Certain CSS Grids with flexible tracks end up too wide (leading to e.g. overflow/misalignment on about:processes)
Duplicate of this bug: 1941101
Duplicate of this bug: 1941136
Duplicate of this bug: 1941416
Duplicate of this bug: 1942197
Duplicate of this bug: 1942213

Can we consider backing bug 1916849 out of nightly too? Having about:processes sort of broken has been a bit of a pain.

Flags: needinfo?(emcdonough)

A suggestion for papering over: I've been modifying tr width from 100% to 100vw as a low-change workaround. Perhaps we can make a change like that to aboutProcesses.css for now?

For about:processes, ideally it wouldn't be using table + grid layout in the way that it does.

I am going to prepare a change to gate this behavior behind a pref, and leave it pref'ed off until these issues are resolved.

Flags: needinfo?(emcdonough)

The pref layout.css.grid-flex-spanning-items-intrinsic-sizing.enabled is
expected to be removed once these regressions are fixed. This should be a good
compromise between maintaining the code from bug 1916849, and avoiding
breakage/extra backouts.

Attachment #9460883 - Attachment description: Bug 1938619 - Add a pref (disabled by default) to enable intrinsic sizing of grid items that span flex tracks. → Bug 1938619 - Add a pref (disabled by default) to enable intrinsic sizing of flexible grid tracks based on grid items that span multiple tracks.
Pushed by emcdonough@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/87632f7cc602 Add a pref (disabled by default) to enable intrinsic sizing of flexible grid tracks based on grid items that span multiple tracks. r=layout-grid-reviewers,dholbert
Status: NEW → RESOLVED
Closed: 23 days ago
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch

I was able to reproduce the issue on an affected Firefox Nightly 135.0a1 build from 2024-12-20, using Windows 11, while following the steps described in Comment 0.
Verified as fixed on Firefox 136.0b3 using Windows 11, macOS 14.7 and Ubuntu 22.04. Memory and CPU usage are no longer pushed off the screen in about:processes and the "X" button is also visible now.
I've also verified the the test cases from Comment 10 and Comment 13 are correctly rendered.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: