2051611 - Nightly shows a non-functional title bar despite being set not to

Status: RESOLVED DUPLICATE of bug 2051030

(Firefox :: General, defect)

Description

[Pomax]

Attachment: {987934B3-8246-4609-8B2F-DBE20A0AF643}.png

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

Steps to reproduce:

I opened Nightly on Windows.

Actual results:

There is a title bar above the main UI, which appears to behave in crazy ways.

• I can click-drag using the title bar to move the application around, but
• the minimize, maximize, and close buttons do nothing. However,
• double clicking the title bar maximizes Nightly, while also removing the title bar

It's... a bit of a hot mess.

Expected results:

With "title bar" unchecked in the bar customization UI (bottom left), there should never be a title bar shown.

With it checked, there should be a title bar, with control buttons in the title bar and not in the tab bar, and it should behave the way a title bar should behave.

Comment 1

[Pomax]

Note that restarting in troubleshooting mode does not have this issue, so somehow normal Nightly is not bothering to look at the title bar setting.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, but is not confident enough to move the bug to that component.

Comment 3

[Pomax]

It should not. Also there is no such thing as the "address bar", we renamed it to the "awesome bar" when we launched Quantum ;)

Comment 4

[Pomax]

It'd be great if someone could look at this, it's infuriatingly bad.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Current suspicion is that this could be a regression from Bug 1957069. From an AI triage tool, which suggests:

This is a genuine, in-scope frontend/chrome defect. I localized it to a Windows widget regression rather than a JS/CSS issue:

• The "custom titlebar" (tabs-in-titlebar) needs the DOM customtitlebar attribute and the widget's native non-client area to stay in sync. CustomTitlebar._update() only toggles the DOM attribute.
• Bug 1957069 (ded44b2b9717, landed 2026-06-23 — one week before this report) added an early SetCustomTitlebar(true) in the pre-XUL skeleton-UI branch of nsWindow::Create (nsWindow.cpp:1078). It sets mCustomNonClient = true prematurely, so the real init-time sync hits the early-return at nsWindow.cpp:2841 and never runs UpdateNonClientMargins() at the right time → native title bar with dead buttons until a relayout (maximize) fixes it.
• Skeleton UI is disabled in Troubleshooting Mode, which explains why safe mode is fine.

Proposed fix: scope that early SetCustomTitlebar(true) to the maximized branch where it's actually needed (or re-assert UpdateNonClientMargins() after chrome shows).

Greg, what do you think?

Comment 7

[Greg Stoll :gstoll]

:handyman is looking at the duplicate bug with a similar approach. Thanks!