2004018 - Can't click fxview button or leftmost half of first tab (basically, leftmost ~118px) using the topmost row of pixels in a maximized window

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[:Gijs (he/him)]

Mozregression blames https://hg-edge.mozilla.org/integration/autoland/rev/a29551a9685131db14c42468ab28bb3fe8de7ed2

Single screen setup, 150% Windows scaling setting.

Worth noting that on my main profile, on 146 beta, I can't use the topmost pixels on maximized Firefox windows anywhere (not just the leftmost bits), but I can't reproduce that with mozregression...

Comment 1

[:Gijs (he/him)]

Setting widget.windows.windowsappsdk.enabled to false makes this issue go away.

Comment 2

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

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

:emilio, 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.

Comment 3

[:Gijs (he/him)]

I can reproduce the problem described in the summary on a clean profile on 146.0rc as well (makes sense as 1993474 was uplifted) - but not the issue where it affects the whole tabstrip rather than only the leftmost bits.

Comment 4

[Greg Stoll :gstoll]

It's possible that bug 1994918 will fix this since we stop using the Windows App SDK WNDPROC entirely. (I'm not sure because I haven't been able to reproduce this problem)

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Can you try with the patch from bug 1994918? I couldn't repro this off-hand either.

Comment 6

[Caspy7]

I can reproduce this. Very irritating.
Windows 11. Compact UI density (in case it matters)
Not just the top pixel, but the top few, along the width of the whole window - except the window controls.
The cursor must trigger hover over the tab (the highlight shows) in order to click it.
AMA

edit: toggling widget.windows.windowsappsdk.enabled and restarting does fix it.

Comment 7

[Yannis Juglaret [:yannis] (Away until May 11)]

I can reproduce this issue. My screens are setup as follows:

1 | 2
1: 3840x2160, 150%
2: 3840x2160, 200%, main display

The issue occurs on both screens. In order to reproduce the issue consistently it seems that I need to be using my work profile.

However, the following STR also seem to work consistently without requiring a particular profile:

• Open a new private window.
• Maximize it.
• Open a second tab.
• Try switching back to the first tab by putting the mouse at the topmost line of pixels and rather to the left of the tab button (for me 75% of the surface will refuse switching back, only the 25% rightmost pixels will switch).

(In reply to Emilio Cobos Álvarez [:emilio] from comment #5)

Can you try with the patch from bug 1994918? I couldn't repro this off-hand either.

If I follow the private window STR in a local build, this patch does not solve the issue. I'm waiting on a try push to finish before I can confirm what happens with my work profile.

Comment 8

[Greg Stoll :gstoll]

More people seem to be hitting this than were affected by bug 1993474, so I'm going to bump to S2.

Comment 9

[Greg Stoll :gstoll]

OK, I can repro this following :yannis's steps even with the patch from bug 1994918.

Comment 10

[Greg Stoll :gstoll]

I suspected that AppWindowTitleBar.LeftInset might be involved here, but that seems to return 0.

Comment 11

[Greg Stoll :gstoll]

:yannis points out that turning the system titlebar on and off seems to work around this problem.

Comment 12

[Dianna Smith [:diannaS]]

Marking 146 as fixed by backout in 146.0rc2 (which will be built today).
The regressor is still in 147, so marking tracking as blocking.

Comment 13

[Yannis Juglaret [:yannis] (Away until May 11)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #5)

Can you try with the patch from bug 1994918? I couldn't repro this off-hand either.

Complement to comment 7: I confirm that the patch from bug 1994918 doesn't fix the issue for me, neither when I'm testing with my work profile nor with the private window STR.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Ok, let me try to take a closer look next week.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Oh, Greg is also looking into it. If he gets to the bottom of this before me that's awesome, otherwise I'll still try to poke next week :)

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Blerg, sorry.

Comment 17

[Greg Stoll :gstoll]

It's Friday afternoon and my brain is fried, so let me write up what I'm working on for this:

I have a modified fix for bug 1994918 that passes all messages that our WNDPROC doesn't handle to the Windows App SDK WNDPROC except for WM_NCLBUTTONDBLCLK. This makes me think that maybe there's a way to fix this problem and bug 1993474 by sending some messages to the Windows App SDK instead of handling them in our WNDPROC. So I'm playing around right now trying to find some specific messages to do this with.

Comment 18

[Greg Stoll :gstoll]

(another option is to go back to the hacky WS_BORDER fix for bug 1993474. I assume that wouldn't cause this problem...)

Comment 19

[Emilio Cobos Álvarez [:emilio]]

A good thing to do would be to check which messages if any we get while we hover over the broken area. Or do we somehow not get any?

Comment 20

[Emilio Cobos Álvarez [:emilio]]

(Sorry can't check on a windows machine until tomorrow at least).

Comment 21

[Emilio Cobos Álvarez [:emilio]]

On a VM I have around, I have mostly WM_NCHITTEST messages (expected) and WM_MOUSEACTIVATE messages (unexpected, the window should be active). Is there a hidden window in that area somehow?

Ah, I also get a WM_PARENTNOTIFY... It seems there must be a window somewhere there that is eating the event? I'll look with winspy tomorrow on my desktop VM debugging is extra annoying.

Comment 22

[Emilio Cobos Álvarez [:emilio]]

Ok, so I could poke a bit today and there is indeed an extra window in that area with caption "Non Client Input Sink Window", and class "InputNonClientPointerSource".

Comment 23

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2004018 - Allow the Windows App SDK to handle WM_WINDOWPOSCHANGED. r=#win-reviewers,gstoll

Otherwise we might end up with a mispositioned child window that it uses
internally to handle non-client events.

Comment 24

[lburuian]

Hello,
We have verified the fix revert in 146.0rc2, and the Firefox View button can be clicked using the topmost row of pixels in a maximized window while on a single-screen setup ( verified on the Default Windows scaling setting of 125% and on 150% scaling setting).
However, the Firefox View button cannot be clicked when using an external monitor.
Marking 146 as verified based on the successful fix revert in 146.0rc2.
Thank you.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/25fe7c42713b
https://hg.mozilla.org/integration/autoland/rev/a9fcfc3ebba8
Allow the Windows App SDK to handle WM_WINDOWPOSCHANGED. r=gstoll,win-reviewers

Comment 26

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/a9fcfc3ebba8

Comment 27

[Yannis Juglaret [:yannis] (Away until May 11)]

As far as I am concerned everything works fine in the latest Nightly build. Thanks!

Comment 29

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox147 to wontfix.

For more information, please visit BugBot documentation.

Comment 30

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9531311 [details]
Bug 2004018 - Allow the Windows App SDK to handle WM_WINDOWPOSCHANGED. r=#win-reviewers,gstoll

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: broken titlebar behavior
• 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 7 seemed reliable for me.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One liner.
• String changes made/needed: none
• Is Android affected?: No

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9531311 [details]
Bug 2004018 - Allow the Windows App SDK to handle WM_WINDOWPOSCHANGED. r=#win-reviewers,gstoll

Approved for 147.0b3.

Comment 32

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/edc2d0c4e1e8
https://hg.mozilla.org/releases/mozilla-beta/rev/3bbdf62eb55c

Comment 36

[lburuian]

Hello,
I was able to reproduce the issue on Windows 11x64, using Nightly 147.0a1 (2025-12-04). The Firefox View button, together with the leftmost section up to the first half of first tab is not accessible on Single screen and extended screen setup, neither with Horizontal tabs nor with Vertical tabs.
Verified on Windows 11x64, using the latest Nightly 148.0a1 (2025-12-14) and latest Beta 147.0b3. The issue no longer reproduces.
All the buttons in the leftmost section (including Fx View when using Horizontal tabs) is now accessible from the the topmost row of pixels, on Single screen and extended screen setup, with Horizontal tabs and Vertical tabs.
Other checks:

• Verified with pinned tabs as well.
• Also checked in Private window.
• Enabled Title Bar to make sure there are no issues.

Thank you.