1993474 - On an external monitor in a maximized Firefox window, can't select a tab with the cursor at the top of the screen

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Greg Stoll :gstoll]

I can't click tabs if I have my cursor at the top of the screen. Need to move it down by 3-4 pixels to be able to click the hit area. This happens only on external monitors, not the laptop screen. The caption buttons or new tab button are also not clickable.

mozregression points at bug 1947324.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Greg Stoll :gstoll]

On my external monitor, there's an extra 5 px of space in the titlebar that seems to be causing this. This seems to be caused by the call to put_ExtendsContentIntoTitleBar(true).

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[Greg Stoll :gstoll]

Using the Browser Toolbox Inspector, when the window is maximized and on my external monitor (may be an DPI thing), there is ~5 px at the top of the titlebar that Firefox isn't drawing on. (i.e. mousing over the top <html> tag doesn't highlight)

Calling SetPresenterKind(AppWindowPresenterKind_FullScreen) does not help.

Comment 6

[michaelleo420]

So i originally posted my own bug report but its been merged here.

I decided to try that widget.windows.windowsappsdk.enabled to false, and it also fixes my issue, but the strange thing is when i view photos with windows photo viewer, i have that big white line at the top of my screen on my 2nd monitor still, so its not just a firefox issue

Im thinking this is actually a windows 11 issue?

Comment 7

[Greg Stoll :gstoll]

Removing the WS_BORDER style from our windows seems to fix this. I was going to only do this when our window is maximized, but even with an unmaximized window you can still drag/resize it, and this also seems to fix bug 1994918 so I'm going to try just turning it off everywhere and see what happens.

Comment 10

[Greg Stoll :gstoll]

[Tracking Requested - why for this release]: Many duplicates and Reddit threads about this problem; I'd like to uplift to beta after the fix is in.

Comment 12

[Greg Stoll :gstoll]

Attachment: Bug 1993474 - remove WS_BORDER to fix border issues with Windows App SDK r=#win-reviewers!

When a window with WS_BORDER is maximized on a low-ish DPI monitor, an
"extra" border on top shows up. This breaks the workflow of moving your
mouse to the very top of the screen to hover over or select tabs.

(people have reported this with non-Firefox apps so I'm guessing this is
really an OS problem)

But the WS_BORDER style doesn't actually seem necessary for us when tabs
are being shown in the toolbar - removing it still means we can resize
our window, etc.

We do need to handle the case when tabs are not being shown in the toolbar,
so we have to toggle the WS_BORDER style when that changes. I tested on my
system in a number of different configurations and it seems to work fine.

I believe this will fix bug 1994918 and possibly some others.

Comment 14

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Multiple users have reached out via Bugzilla, SUMO, and Reddit, complaining about this issue.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: medium
• Explanation of risk level: Changing our window styles is a little risky. I have verified this fix with my dev build locally (on Windows 11) and on a Windows 10 VM.
• String changes made/needed: no
• Is Android affected?: no

Comment 15

[Greg Stoll :gstoll]

Attachment: Bug 1993474 - remove WS_BORDER to fix border issues with Windows App SDK

When a window with WS_BORDER is maximized on a low-ish DPI monitor, an
"extra" border on top shows up. This breaks the workflow of moving your
mouse to the very top of the screen to hover over or select tabs.

(people have reported this with non-Firefox apps so I'm guessing this is
really an OS problem)

But the WS_BORDER style doesn't actually seem necessary for us when tabs
are being shown in the toolbar - removing it still means we can resize
our window, etc.

We do need to handle the case when tabs are not being shown in the toolbar,
so we have to toggle the WS_BORDER style when that changes. I tested on my
system in a number of different configurations and it seems to work fine.

I believe this will fix bug 1994918 and possibly some others.

Original Revision: https://phabricator.services.mozilla.com/D272653

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/569ef287466f
https://hg.mozilla.org/integration/autoland/rev/6b6fbc2c8e4c
remove WS_BORDER to fix border issues with Windows App SDK r=win-reviewers,handyman

Comment 17

[Greg Stoll :gstoll]

Attachment: Bug 1993474 - remove WS_BORDER to fix border issues with Windows App SDK

When a window with WS_BORDER is maximized on a low-ish DPI monitor, an
"extra" border on top shows up. This breaks the workflow of moving your
mouse to the very top of the screen to hover over or select tabs.

(people have reported this with non-Firefox apps so I'm guessing this is
really an OS problem)

But the WS_BORDER style doesn't actually seem necessary for us when tabs
are being shown in the toolbar - removing it still means we can resize
our window, etc.

We do need to handle the case when tabs are not being shown in the toolbar,
so we have to toggle the WS_BORDER style when that changes. I tested on my
system in a number of different configurations and it seems to work fine.

I believe this will fix bug 1994918 and possibly some others.

Original Revision: https://phabricator.services.mozilla.com/D272653

Comment 18

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Multiple users have reached out via Bugzilla, SUMO, and Reddit, complaining about this issue.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: medium
• Explanation of risk level: Changing our window styles is a little risky. I have verified this fix with my dev build locally (on Windows 11) and on a Windows 10 VM.
• String changes made/needed: no
• Is Android affected?: no

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/40834c6a92e4
https://hg.mozilla.org/integration/autoland/rev/84c79b9d4973
Revert "Bug 1993474 - remove WS_BORDER to fix border issues with Windows App SDK r=win-reviewers,handyman" for causing bc failures on browser_test_fullscreen_size.js

Comment 20

[Cristina Horotan [:chorotan]]

Backed out for causing bc failures on browser_test_fullscreen_size.js

Backout link

Push with failures

Failure log bc
Failure log wpt
Failure log bc

Comment 21

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox146 (beta) and tracked for firefox147 (nightly). However, the bug still has low severity.

:jstutte, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 22

[Jens Stutte [:jstutte]]

IIUC there is a very simple workaround, that is move down the mouse a few pixels? So I'd be inclined to not rate this S2.

Comment 23

[Enon]

Jumping in to say this is nevertheless still very annoying and workflow breaking! I'd like to argue that this workaround isn't nearly good enough for this to not be prioritized.

Comment 24

[Mauro V [:cheff]]

I'd disable widget.windows.windowsappsdk.enabled for a quick fix (Because this also breaks double clicking on the sidebar with window-dragging enabled, which we desperately need for Zen, caused by the root issue of this bug) for now.

Comment 25

[Greg Stoll :gstoll]

To be clear, I'm still actively working on this; I have a fix but it seems to cause some other problems relating to fullscreen/maximized windows.

Comment 33

[Pascal Chevrel (relman team) -> :pascalc]

Current patch is too risky for 145, we'll try to target 146.

Comment 34

[Donal Meehan [:dmeehan]]

:gstoll, I see the patch is still in progress.
This is the last week of Beta for Fx146, so there is little time left to uplift a fix if we have one.

Comment 35

[Greg Stoll :gstoll]

I’m OOTO (although can hop on to do something if needed) but when I left :handyman was looking at this and thinking about the risk level.

Comment 36

[Donal Meehan [:dmeehan]]

Thanks, it's not a new bug in Fx146 so won't block.
It was just more a heads up that there is little time left.

Comment 37

[David Parks [:handyman]]

Thanks Donal. We're going to hold off on the uplifts and instead target 147. We've got some wrinkles to iron out first.

Comment 38

[Donal Meehan [:dmeehan]]

Changing Fx146 to fix-optional. When we have a fix and some bake-time, we should uplift for a Fx146 dot release ride-along.

Comment 39

[Emilio Cobos Álvarez [:emilio]]

So I could briefly reproduce this, but after an OS update I can't anymore, can somebody confirm whether they can or can't reproduce on:

Version 25H2
OS build 26200.6899
Experience Windows Feature Experience Pack 1000.26100.253.0

?

Comment 40

[Emilio Cobos Álvarez [:emilio]]

Ok, it's back somehow. But I see what's going on.

Comment 41

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1993474 - Ensure our WNDPROC has precedence over WinAppSDK's. r=gstoll,#win-reviewers

See the comment for reasoning. WM_NCCALCSIZE wasn't getting called, and
we rely on that to get the right client area on things like maximized
windows.

Comment 42

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1993474 - Remove redundant nsWindow::mPIPWindow. r=#win-reviewers

nsIWidget already has a member for this.

Comment 43

[dgrdsv]

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

Ok, it's back somehow. But I see what's going on.

26200.6899 with Experience Windows Feature Experience Pack 1000.26100.253.0 are not the latest release versions of Win11 25H2, and the bug remains on 26200.7171 / 1000.26100.265.0 which are.

Comment 44

[Emilio Cobos Álvarez [:emilio]]

Yeah, what's going on is that the app sdk is overwriting our WNDPROC and that messes with our NCCALCSIZE handling among others.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/433cc8224790
https://hg.mozilla.org/integration/autoland/rev/a29551a96851
Ensure our WNDPROC has precedence over WinAppSDK's. r=gstoll,win-reviewers

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/418e274c76f9
https://hg.mozilla.org/integration/autoland/rev/96a01fda50b6
Remove redundant nsWindow::mPIPWindow. r=win-reviewers,gstoll

Comment 47

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9529537 [details]
Bug 1993474 - Ensure our WNDPROC has precedence over WinAppSDK's. r=gstoll,#win-reviewers

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: See list of dupes.

• Is this code covered by automated tests?: Yes

• Has the fix been verified in Nightly?: No

• Needs manual test from QE?: Yes

• If yes, steps to reproduce: The specific configurations affected are not super clear. What worked for me was having:

• Primary monitor with scale 150%

• Secondary monitor with scale 100%

In such cases, putting a maximized firefox window on the second monitor always caused the issue.

• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Makes behavior more similar to pre-regression (winappsdk disabled). It'd be a one liner to back out.
• String changes made/needed: none
• Is Android affected?: No

Comment 48

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/a29551a96851
https://hg.mozilla.org/mozilla-central/rev/96a01fda50b6

Comment 49

[Pascal Chevrel (relman team) -> :pascalc]

Emilio, double-checking, should both 433cc8224790 and a29551a96851 be uplifted?

Comment 50

[Emilio Cobos Álvarez [:emilio]]

No need for the second patch. Doesn't hurt either tho.

Comment 51

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6d7bddde7155
https://hg.mozilla.org/releases/mozilla-beta/rev/9a803f195707
https://github.com/mozilla-firefox/firefox/commit/b7eaadfba3f7
https://hg.mozilla.org/releases/mozilla-beta/rev/b2c73b757d47

Comment 52

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c07fa8648729
https://hg.mozilla.org/releases/mozilla-beta/rev/f4ca255f6411
https://github.com/mozilla-firefox/firefox/commit/93c63a1b87dd
https://hg.mozilla.org/releases/mozilla-beta/rev/dc2af44ce82b

Comment 53

[Pascal Chevrel (relman team) -> :pascalc]

Uplift reverted in beta for causing bug 2002986, let's try to have a better fix for RC :)

Comment 54

[lburuian]

Hello,
I was able to reproduce the issue on Windows 11x64, using Nightly 145.0a1 (2025-10-09) and Firefox Release 145.0.2. The Firefox tabs and the new tab button are not clickable when the cursor is at the top of the screen.
Setting widget.windows.windowsappsdk.enabled to false fixes the issue, but it also brings up the Windows photo viewer issue, where a big white line is present at the top of the screen when on an external monitor.

Verified on Windows 11x64, using the latest Nightly 147.0a1 (2025-11-28), and the issue no longer reproduces. The tabs are now accessible even when the cursor is at the very top of the screen. Setting widget.windows.windowsappsdk.enabled to false does not change anything, and the tabs are still accessible, as expected.
We will verify this in Beta as well, once the new build becomes available, and update the corresponding flags and status accordingly.

However, the issue still reproduces for the address bar and some toolbar buttons when Vertical tabs is enabled. The sidebar button, the first two buttons after it, and the address bar are not accessible when the cursor is at the top of the screen. This is not the case for the other buttons. See attached video.

Should I log a separate bug for this specific scenario, or should I reopen this bug?
Thank you.

Comment 55

[lburuian]

Attachment: 2025-11-28_14h43_01.mp4

Comment 56

[Emilio Cobos Álvarez [:emilio]]

Should I log a separate bug for this specific scenario, or should I reopen this bug?

No, that is unrelated to this bug. I'd file a bug about the inconsistency of the various hit targets tho.

Comment 57

[Donal Meehan [:dmeehan]]

Comment on attachment 9529537 [details]
Bug 1993474 - Ensure our WNDPROC has precedence over WinAppSDK's. r=gstoll,#win-reviewers

Adding the uplift request back since this was backed out of beta.
It's too late for Fx146 beta, but this could be changed to a release uplift request later.

Comment 59

[Dianna Smith [:diannaS]]

Comment on attachment 9529537 [details]
Bug 1993474 - Ensure our WNDPROC has precedence over WinAppSDK's. r=gstoll,#win-reviewers

Approved for 146.0rc1

Comment 60

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/26218ae6f9db
https://hg.mozilla.org/releases/mozilla-release/rev/72d62a9a1c09
https://github.com/mozilla-firefox/firefox/commit/0e95451bdb1d
https://hg.mozilla.org/releases/mozilla-release/rev/7a43dafd3dcb

Comment 61

[Will]

Attachment: vertical tabs fitts.png

I'm in the beta channel and just upgraded to 146 "final" and can confirm this breaks Fitts' law for the first few buttons when in vertical tabs mode (though it also seems to work sometimes? it's very odd). Windows display scaling is set to 200%, so no weird non-integer scaling rounding error weirdness is behind this.

Comment 62

[lburuian]

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 tabs are now accessible even when the cursor is at the very top of the screen.

Comment 63

[Greg Stoll :gstoll]

Release Note Request (optional, but appreciated)
[Why is this notable]: This bug has a lot of duplicates (and SUMO/Reddit threads)
[Affects Firefox for Android]: No
[Suggested wording]: Fixed an issue that prevented Windows users from selecting a tab when the cursor was at the top of the screen and Firefox was maximized on some kinds of monitors.
[Links (documentation, blog post, etc)]:

Comment 65

[Dianna Smith [:diannaS]]

Added to Fx146 release notes.

Comment 66

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7041cc687af0
https://hg.mozilla.org/releases/mozilla-release/rev/36044c935df0
https://github.com/mozilla-firefox/firefox/commit/cfb14c368373
https://hg.mozilla.org/releases/mozilla-release/rev/212344e658e3

Comment 67

[Dianna Smith [:diannaS]]

This is being reverted in 146.0rc2 for causing bug 2004018. It will remain in 147 as there is a potential fix in the works for the regressor.

Comment 68

[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. However, the Firefox View button cannot be clicked when using an external monitor. (The original issue reproduces as it did before the fix.)
Thank you.

Comment 70

[Ryan VanderMeulen [:RyanVM]]

Moved to the Fx147 relnotes.