1934136 - Completely white tab bar background when Mica is enabled (fixed when resizing or painting the NC area somehow else)

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P3)

Description

[kanapa1]

Attachment: Tab bar background when Mica is enabled

Steps to reproduce:

1. Make sure that:
   • you are using Firefox version 133 stable
   • support for the Mica effect from Windows 11 is enabled in the advanced settings via the widget.windows.mica pref
   • you are using the default theme, i.e. System theme — auto, as this is currently the only one that supports the Mica material as the tab bar background.
     If these three conditions are met, proceed to the next step.
2. Start Firefox.
3. Look at the tab bar, especially the right side, and see what is described in the "Actual results" section.

Actual results:

The tab bar background appears completely white (#FFFFFF), and the native (or at least native-looking) window control buttons on the right are barely visible (see the attached screenshot). This is what it looks like until Firefox is forced to redraw its client area, which can be done by:

1. Performing actions on the main window, such as:
   • minimizing the window and then restoring it from the taskbar
   • maximizing the window or restoring it down
   • grabbing the window by one of its edges and resizing it by even a single pixel.
2. Dragging the Firefox window off-screen (past any screen edge) and back again. In this case, however, only the pixels that were moved off-screen seem to be redrawn (see the screenshot from one of my comments below this bug description).
3. Entering the customization mode (Application hamburger menu > More tools > Customize toolbar...), which still seems to trigger a redraw even though the blueprint-like Australis-era grid that blended into the window borders is no longer there.
4. ...And more, but the ones I listed are probably more than enough...

After doing one of the above, the Mica effect in the tab bar will remain "fixed" until Firefox is completely closed and reopened, so this is more of a temporary workaround.

⚠️ Interestingly, this issue does NOT occur at all when using the touch density from the customization mode, as if the resizing of various elements occurred a bit later in the startup sequence and thus caused additional redraw, which is enough to mask the occurrence of this issue with Mica rendering.

Expected results:

The Mica Alt effect should be correctly drawn over the entire surface of the tab bar when tabs are displayed in the title bar (which is the default these days), and the window minimize, maximize, and close buttons should have sufficient contrast with the background underneath them.

Comment 1

[kanapa1]

Attachment: Tab bar background after partially dragging the window off-screen

This is what the tab bar may look like when the window is partially dragged off-screen at the left edge, then at the top, and finally at the right. The white rectangle in the middle is the part that remained inside the screen the whole time, while the fixed bluish area around it was off-screen at least for a moment (which fixed the Mica effect only on those pixels).

Comment 2

[kanapa1]

This is what the tab bar may look like when the window is partially dragged off-screen at the left edge, then at the top, and finally at the right. The white rectangle in the middle is the part that remained inside the screen the whole time, while the fixed bluish area around it was off-screen at least for a moment (which fixed the Mica effect only on those pixels).

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Yeah, I've seen this intermittently (well, a different version of this, in dark mode).

We're probably missing an NC-area clear when the window becomes transparent.

Curious, does it happen for you on any window that isn't the first one? The first window is kinda fun (we have the skeleton UI, then the early blank window, then the actual firefox window with the mica effect).

Comment 4

[kanapa1]

Curious, does it happen for you on any window that isn't the first one? The first window is kinda fun (we have the skeleton UI, then the early blank window, then the actual firefox window with the mica effect).

No, it doesn't. Only the first browser window opened has problems with drawing the Mica effect in the tab bar. And it doesn't necessarily have to be a standard window, as private windows (when browser.theme.dark-private-windows is set to false) are also affected.

---

However, you've drawn my attention to an important (as it turns out) aspect here — the early blank window.

Is this still a thing? If I remember correctly, it was introduced sometime at the beginning of the Photon era, when many users were still relying on traditional HDDs, to give the user some feedback that they could stop clicking that icon on the desktop for the n-th time because Firefox was already starting.

Later on, the pre-XUL skeleton UI was introduced, which simply did the job better from the user's perspective. Since then, I can't recall seeing that plain white screen ever again. Is it still in use?

Getting back to the main topic, and the reason I'm bringing this up, in my experience, the browser.startup.preXulSkeletonUI pref doesn't seem to do anything. Regardless of its logical value, the raw and simplified interface always appears first, followed by the proper browser UI.

However, it appears that the browser.startup.blankWindow pref seems to disable the skeleton UI described in the previous paragraph. Always, regardless of whether Mica is enabled or not. Is this how it's supposed to work? I have absolutely no idea.

Interestingly, disabling it (only the browser.startup.blankWindow pref set to false) resolves the issue with the Mica effect not rendering correctly in the tab bar for the first browser window opened. The same happens when using the touch density from the customization mode (as mentioned in the bug report description in the paragraph with the warning sign). So, I can confirm that your assumptions, :emilio, were correct.

Comment 5

[[:userChrome.css]]

Attachment: Screenshot 2024-12-09 154631.png

I think this is related issue. As you mentioned it weird mica drawing effect only happens on first window.
Resizing the window fixes it too.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1934136 - Ensure we trigger any pending WM_PAINT once we stop being the initial blank window. r=#win-reviewers

nsWindow::OnPaint() will basically lie and claim it has painted without
having painted if we are the early blank window. Make sure that once we
stop being the early blank window, we do any remaining work we might
need.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/03950b834d58
Ensure we trigger any pending WM_PAINT once we stop being the initial blank window. r=win-reviewers,rkraesig

Comment 8

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/03950b834d58