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•3 months 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•3 months ago
|
||
oops , the Componentis win32 not gtk.
| Reporter | ||
Updated•3 months ago
|
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Comment 3•3 months ago
|
||
I must've goofed something during testing or so, I pretty explicitly tested native titlebar / fullscreen etc...
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Comment 4•3 months 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•3 months ago
|
Comment 5•3 months ago
|
||
Changing 146 to unaffected, Bug 1993474 was only on the beta branch for a short time and never made a build.
Comment 8•3 months ago
|
||
| bugherder | ||
Updated•3 months ago
|
| Assignee | ||
Comment 10•3 months 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•3 months ago
|
Comment 11•3 months ago
|
||
Comment on attachment 9529752 [details]
Bug 2002986 - Use IAppWindowTitlebar::ResetToDefault() for non-collapsed titlebar. r=#win-reviewers
Approved for 146.0rc1
Updated•3 months ago
|
Comment 12•3 months ago
|
||
| uplift | ||
Updated•3 months ago
|
Comment 13•3 months 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•3 months ago
|
||
| uplift | ||
Comment 15•3 months ago
|
||
This is being reverted in 146.0rc2 along with bug 1993474 for causing bug 2004018. It will remain in 147.
Updated•3 months ago
|
Comment 17•3 months 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•3 months ago
|
||
Firefox 146 should have been fixed when bug 1993474 was backed out in 146.0rc2.
Comment 19•2 months ago
|
||
Marking this bug as Verified for 146 since the code for it has been reverted in 146.0rc2.
Thank you.
Description
•