1982455 - Mac GPU process: Content added by typing sometimes does not appear

Status: RESOLVED FIXED

(Core :: Graphics, defect, P2)

Description

[Andy Leiserson [:aleiserson]]

Attachment: Screenshot 2025-08-11 at 12.44.00 PM.png

I have the GPU process enabled in my nightly Mac Firefox with layers.gpu-process.enabled. Hardware is M1. I am using an external 3440 x 1440 34" (not hidpi) display. Typically my Firefox window is on the right half of the screen.

I have seen this on several different sites, including Matrix, Notion, and Gmail. See the attached screenshot for an example. It is hard to tell just from looking at the screenshot, but I have pasted a link into the message entry box, and the rightmost portion of the link (the pull request number) is not showing up on the screen. This is the general form of the bug: when typing text into a document, the first part of a line of text appears, but the portion on the right side of the window does not appear.

If the content is scrollable, scrolling usually causes the missing text to appear, as does typing sufficient text to wrap onto a new line and move the existing text upwards.

It's hard to estimate how often this occurs. I'd say frequently, but it's possible it's not so frequent and I just don't notice all the times it doesn't happen. I've definitely seen it multiple times on each of multiple sites.

Comment 1

[Erich Gubler [:ErichDonGubler] (he/him)]

Tentatively classifying as S2; this seems like a potentially significant problem for all types of user.

Brad, since you introduced the GPU process for macOS: Can you diagnose this issue, please?

Comment 2

[Brad Werth [:bradwerth]]

This is real, and happens in various scenarios. I am still trying to produce some crisp reproduction steps. Typing is not strictly necessary. For example, popups in Google Docs sometimes are clipped through, and that is the same issue as this Bug. When I can find clean reproduction steps, I'll update this Bug's title to reflect that.

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: Screenshot 2025-08-15 at 5.54.44 PM.png

I see related problems a bunch on my Mac, like when switching apps back to Firefox or between Firefox windows the right and bottom parts of a window will be blanked out something like the screenshot in bug 1981793. And a whole bunch of visual problems on google docs and sheets. Not consistently reproducible, but I finally found STR and then was able to reproduce it in a new Profile so I know it's not all the extensions and custom settings I've accumulated over the years.

STR

0. use a scaled resolution (e.g. 1920x1080 or 2560x1440 on my 4K external monitor, or 1512x982 HiDPI on my MBP screen)
1. Open the sidebar (Cmd+B for Bookmarks, Cmd+Shift+H for History)
2. In the address bar start typing a term with a max number of matches, then add a character that collapses the results to 0-2 matches. For example, I type "bugz" and then add "x" ("bugzx").

Results: the visual corruption shown in the screenshot

3. adjust the size of the window so a reflow fixes the visual glitch
4. backspace in the search term so it jumps from few results to lots

Results: the same visual corruption

• It doesn't matter whether it's the "old" sidebar or the new one from the "Show sidebar" checkbox in Settings
• it doesn't matter whether the sidebar is on the left or right
• It doesn't matter what the sidebar contents are. One from an extension works fine, "customize sidebar" sidebar works too
• Vertical Tabs alone does NOT reproduce. If you use VT you still have to open history or something in addition

Quite often I am also missing the first part of the link URL hovertext we show at the bottom left. Comes and goes, happens a lot except when I'm trying to reproduce it :-)

Comment 4

[Daniel Veditz [:dveditz]]

The screenshot was at step 4 rather than step 2, but they were basically the same.

Comment 5

[Daniel Veditz [:dveditz]]

A reliably broken page when using the Mac GPU process: https://www.nps.gov/maps/full.html?mapId=4cfda76a-cc61-4113-8a00-44882918ba9a

• graphical corruption as you scroll in (scrolling out usually undoes the damage)
• comet-tails if you drag the map
• if you zoom into something so the numbers get small and then click, individual map pins will animate out to actual locations. Often they get clipped by some invisible box boundary or disappear entirely. For example, zoom in on the "3" in Pinnacles Nat'l Park SE of the Bay Area (you may have to scroll in, and then back out a little so the numbered circle reappears). Then click.
• if you hover over the individual map pins the view circle is probably clipped if the pin is clipped. If you click on a pin a more detailed info box pops up that is often corrupted.

Is this part of the same problem or should it be a separate bug?

Comment 6

[Brad Werth [:bradwerth]]

I've got at least part of this figured out. It is necessary, and perhaps sufficient, to make NativeLayerCA::SetSurfaceToPresent unconditionally set mMutatedFrontSurface, even when the surfaces are the same. That's because the surface contents may still have changed. We're going to have to trust that the call to SetSurfaceToPresent is happening only when something about the surface has changed. That appears to be true with the current calling patterns.

Still not sure this is sufficient to handle all the mis-rendering we're seeing here. I'll prepare the patch, maybe land it, and then see if we have more problems.

Comment 7

[Brad Werth [:bradwerth]]

Attachment: Bug 1982455 Part 1: Allow NativeLayerCA display rect to be set independently of its size.

This also eliminated the unused InvalidateRegionThroughoutSwapchain
method, which was moved into the surface handler and is only used by
other methods of the surface handler.

Comment 8

[Brad Werth [:bradwerth]]

More testing is showing that this is not sufficient. Still working on figuring out the rest of it.

Comment 9

[Brad Werth [:bradwerth]]

Attachment: Bug 1982455 Part 3: Enforce the order of layer commands in NativeLayerRootRemoteMacChild.

Comment 10

[Brad Werth [:bradwerth]]

Attachment: Bug 1982455 Part 2: Make NatlveLayerRemoteMac only send surface info when it has changed.

Comment 11

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #6)

I've got at least part of this figured out. It is necessary, and perhaps sufficient, to make NativeLayerCA::SetSurfaceToPresent unconditionally set mMutatedFrontSurface, even when the surfaces are the same. That's because the surface contents may still have changed.

I'm losing confidence in this assessment. Any call to NotifySurfaceReady() will provide a new surface. It doesn't appear to be possible that the existing/old surface can be drawn into by any mechanism. That drawing is done into mInProgressSurface, which becomes the front surface within the call to NotifySurfaceReady().

Comment 12

[Brad Werth [:bradwerth]]

With the WIP patches applied, here are the simple Steps to Reproduce I am using:

1. Check the menu item View -> Toolbars -> Bookmarks Toolbar -> Always Show.
2. Put at least 2 bookmarks with different URLs (different string lengths) in the Bookmarks Toolbar.
3. Mouseover the leftmost bookmark, generating a status bar URL tooltip in the lower-left part of the window.
4. Mouseover the next bookmark.

Expected results: second bookmark URL tooltip should appear properly in the lower-left of the window.
Actual results: some combination of URL tooltips appears in the lower-left of the window.

Comment 13

[Brad Werth [:bradwerth]]

Figured out the missing piece: NativeLayerCA::SetDisplayRect (which is used by the GPU process compositor, but not by the parent process compositor) was not setting mMutatedDisplayRect. A fix for this will be rolled into part 1 of the patch series.

Comment 14

[Brad Werth [:bradwerth]]

Attachment: Bug 1982455 Part 4: Ensure IOSurface counts are positive throughout gpu-to-parent handoff.

NativeLayerRemoteMac now updates use counts of the changing value of
FrontSurface() during the call to NotifySurfaceReady(). Its destructor
is updated. That should be enough to keep the surface from being
recycled until it reaches the parent.

NativeLayerCA updates the use counts in SetSurfaceToPresent and in its
destructor.

Together, the changes in these two places should be sufficient to keep
the use count positive across the gpu-parent process divide.

Comment 15

[Brad Werth [:bradwerth]]

Going to split these patches up since part 1 is probably the only necessary part to solve this Bug. Parts 2 and 3 are optimizations and code cleanups. Part 4 is a fix for a potential issue that is not manifesting here.

Comment 16

[Phabricator Automation]

Comment on attachment 9510422 [details]
Bug 1982455 Part 2: Make NatlveLayerRemoteMac only send surface info when it has changed.

Revision D263165 was moved to bug 1987046. Setting attachment 9510422 [details] to obsolete.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f8ab2425b63e
https://hg.mozilla.org/integration/autoland/rev/c26c9cddb08a
Part 1: Allow NativeLayerCA display rect to be set independently of its size. r=mstange

Comment 18

[Phabricator Automation]

Comment on attachment 9510420 [details]
Bug 1982455 Part 3: Enforce the order of layer commands in NativeLayerRootRemoteMacChild.

Revision D263163 was moved to bug 1987046. Setting attachment 9510420 [details] to obsolete.

Comment 19

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/c26c9cddb08a

Comment 20

[Daniel Veditz [:dveditz]]

The fix is working for me: the awesomebar suggestions aren't glitching out with a sidebar (comment 3), I get the full URL in the link hovertext at the bottom of the page, the site mentioned in comment 5 is behaving, and gdoc spreadsheets are no longer unusable. Thanks!