1928881 - Title bar changes color from light to dark when browser is started in PBM

Status: NEW

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

Description

[Walter K.]

Attachment: Title bar is drawn with light colors when FF starts

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Start Firefox with -private-window parameter on Windows 10.

Actual results:

Browser starts in PBM mode. Title bar is drawn with light Windows color. After the browser window switches focus to another app or a dialog is opened, the color of the title bar is permanently switches to dark. See attached images.

Expected results:

Browser should start and stay with the same title bar color while it runs.

This could be a regression from the latest changes to the Skeleton UI in Bug 1925577.

Comment 1

[Walter K.]

Attachment: Title bar color is permanently switched to dark after window focus change

Comment 2

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

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

Comment 3

[Ray Kraesig [:rkraesig]]

I can reproduce, with the following setup:

• Firefox is using the system theme;
• browser.tabs.inTitlebar is 0; and
• under Windows Settings > Personalization > Colors,
  • "default app mode" is set to "Light"; and
  • the option to show the accent color on "Title bars and window borders" is not checked.

It doesn't reproduce directly under mozregression, but it appears to actually be due to bug 1923334 — prior thereto, private browsing's "dark mode" state did not override the titlebar. Perhaps that was a bug?

Regardless, pinging :emilio as author of the regressing patch.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yep, I the right/expected behavior there is that the titlebar is dark, not light.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: WIP: Bug 1928881 - Blind attempt?

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Can y'all reproduce on Windows 11? It doesn't seem to repro there, afaict, and I only have Windows 11 handy right now...

Maybe we need something like extra invalidation there after the DWM calls if the window has already been shown?

Comment 7

[Ray Kraesig [:rkraesig]]

I also don't appear to be able to repro on Win11.

(Tests with the above patch will be discussed in the associated Phabricator review.)

Comment 8

[Walter K.]

I can check the fix locally on Win10 if there is a zip build to test.

Comment 9

[Ray Kraesig [:rkraesig]]

(In reply to Walter K. from comment #8)

I can check the fix locally on Win10 if there is a zip build to test.

There is — but I've tested it already, and the patch had no visible effect.

Comment 10

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

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

Comment 11

[Christoph Kerschbaumer [:ckerschb, back on Aug 10th}]

Hey Emilio, I am the REO for FX133. I see you provided a blind attempt? patch. The last chance for Beta uplifts is on the 14th/15th this week. Do you think this is important to get fixed, or should we mark it as fix-optional?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

I can't reproduce this locally, so this is hard to fix for me at least. That said, this seems relatively low severity, as it needs a number of non-default configurations (always-on private browsing mode, titlebar shown), plus it is an improvement from the pre-regression behavior in a way (see comment 4).

So tldr I think this is fix-optional.