Native windows title bar is broken
Categories
(Core :: Widget: Win32, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox145 | --- | unaffected |
| firefox146 | --- | verified |
| firefox147 | + | verified |
People
(Reporter: alice0775, Assigned: emilio)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(2 files)
|
905.45 KB,
image/png
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
Steps to reproduce:
- Start latest Nightly build with clean profile
- Enable Titlebar
--- Bug appears #1 - Restart the browser
--- Bug appears #2 - Maximize the browser with double-click on the titlebar
--- Bug apperas #3
Actual results:
#1
No Nightlr icon at the left side
No Windows control buttons at the right most.
No caption text
#2
No caption text
No mouse hover effect over Windows control buttons
Not function minimize, maximize/restore buttons.
See attached screenshot
And
#3
Nightly icon and window control buttons on the title bar are shifted upward, causing the top edge to be cut off.
Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=1d083dd7a3b058d466ed3aab07299c839bd827a5&tochange=a29551a9685131db14c42468ab28bb3fe8de7ed2
Expected result:
The title bar should appear and work as usual.
Comment 1•1 month ago
|
||
Set release status flags based on info from the regressing bug 1993474
:gstoll, since you are the author of the regressor, bug 1993474, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
| Reporter | ||
Comment 2•1 month ago
|
||
oops , the Componentis win32 not gtk.
| Reporter | ||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Comment 3•1 month ago
|
||
I must've goofed something during testing or so, I pretty explicitly tested native titlebar / fullscreen etc...
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Comment 4•1 month ago
|
||
This seems to actually go to the default DWM stuff and is the documented
way of doing so:
https://learn.microsoft.com/en-us/windows/apps/develop/title-bar#reset-the-title-bar
Updated•1 month ago
|
Comment 5•1 month ago
|
||
Changing 146 to unaffected, Bug 1993474 was only on the beta branch for a short time and never made a build.
Comment 8•1 month ago
|
||
| bugherder | ||
Updated•1 month ago
|
| Assignee | ||
Comment 10•1 month ago
|
||
Comment on attachment 9529752 [details]
Bug 2002986 - Use IAppWindowTitlebar::ResetToDefault() for non-collapsed titlebar. r=#win-reviewers
Beta/Release Uplift Approval Request
- User impact if declined/Reason for urgency: needed for the regressor to be uplifted as well.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Small follow-up to the previous patch.
- String changes made/needed: none
- Is Android affected?: No
| Assignee | ||
Updated•1 month ago
|
Comment 11•1 month ago
|
||
Comment on attachment 9529752 [details]
Bug 2002986 - Use IAppWindowTitlebar::ResetToDefault() for non-collapsed titlebar. r=#win-reviewers
Approved for 146.0rc1
Updated•1 month ago
|
Comment 12•1 month ago
|
||
| uplift | ||
Updated•1 month ago
|
Comment 13•1 month ago
|
||
Verified on Windows 11x64, using the latest Nightly 147.0a1 (2025-12-01), and latest Beta 146.0 (RC1). The issue no longer reproduces.
The Title Bar is displayed correctly, even after restart, and minimize/maximize. The Windows control buttons have hover effect and are working as exected. The context menu for the Title Bar is displayed and options can be selected.
Comment 14•1 month ago
|
||
| uplift | ||
Comment 15•1 month ago
|
||
This is being reverted in 146.0rc2 along with bug 1993474 for causing bug 2004018. It will remain in 147.
Updated•1 month ago
|
Comment 17•1 month ago
|
||
Hello,
This specific issue was only reproducible for the initial fix made for 1993474, and it was resolved in the next fix.
Since the fix for 1993474 has been reverted in 146.0rc2 this is no longer an issue.
Thank you.
Comment 18•1 month ago
|
||
Firefox 146 should have been fixed when bug 1993474 was backed out in 146.0rc2.
Comment 19•1 month ago
|
||
Marking this bug as Verified for 146 since the code for it has been reverted in 146.0rc2.
Thank you.
Description
•