1614218 - Maximized window titlebar bleeds into bottom of adjacent monitor or under taskbar (overflow, overlap, spill, multiple, dual, display, screen)

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[haloflooder]

Attachment: I have a 2x2 monitor setup. I took a screenshot where it shows 4 corners of each monitor. Top left, Top right = Notepad maximized. Bottom right = Display Settings maximized.. Bottom left = Firefox maximized

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

Steps to reproduce:

OS: Windows 10 Build 18362.592

Have a multi-monitor setup with at least 1 monitor on top and 1 on the bottom.

Maximize the firefox window on the bottom monitor via snapping or maximize button.

Actual results:

The firefox window bleeds into the top monitor by 6 pixels.

I have tried maximizing other programs such as Chrome, Notepad, Visual Studio Code, etc and they don't bleed into the top monitor.

Also attempted to rearrange the display positions in Display Settings in the Windows settings but it didn't change the results.

Expected results:

The window shouldn't bleed into the other monitor when the window is maximized.

Comment 1

[Alice0775 White]

Bug 1588316, Bug 1592580

Comment 2

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

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[riasat]

Attachment: firefox bleeding on another monitor

Firefox bleeding (that white bar at top; sometimes different color) on top monitor when maximized in bottom monitor.
Sometimes it also bleeds on side monitors.

Please fix.

Comment 4

[milzer]

I have the same issue. 8px bleed on the top monitor (1080p monitor on top of 1440p).

The bleed disappears if browser.tabs.drawInTitlebar is disabled.

Some people have commented about this in bug 485707 just couple weeks ago.

Comment 5

[Sherman Wang]

I see the same issue in Firefox beta 89.0b11 on Windows 10 20H2 with a 2x2 monitor setup similar to haloflooder. All 4 monitors are 1920x1200, and a window maximized in the bottom right monitor bleeds into almost the entire length of the upper right monitor while also drawing a small corner into the top left monitor. A window maximized in the bottom left monitor only bleeds into the top left monitor.

Per milzer's comment I tried disabling browser.tabs.drawInTitlebar, and that works around the bleed issue.

Comment 7

[Aterfax]

Attachment: Screenshot 2021-08-02 142600.png

Adding another example of this occuring in Win64 Firefox 90.0.2 (64bit).

Comment 8

[yidonaw601]

I have exactly the same issue in Win10 FF 91.1.0esr (64bit). The Chrome browser doesn't have this issue at all.

Comment 23

[Sunny]

Same problem for me :(
FF 93.0 64bits

Comment 26

[Kestrel]

Added keywords to title to make it easier to find and help reduce the number of duplicates.

Comment 27

[Kestrel]

Can be avoided with the following userChrome.css:

:root[tabsintitlebar][sizemode="maximized"] {
  appearance: -moz-win-glass;
}

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=307a7a34013060a6a1e87dfbb911f058d0781a2e&tochange=57f68296c350469d73d788eb3695a898947b4acb

Regressed by Bug 1366405.

Comment 28

[Kestrel]

The overflow is mentioned in the following code:

} else if (aAppearance == StyleAppearance::MozWindowTitlebarMaximized) {
// The origin of the window is off screen when maximized and windows
// doesn't compensate for this in rendering the background. Push the
// top of the bitmap down by SM_CYFRAME so we get the full graphic.
widgetRect.top += GetSystemMetrics(SM_CYFRAME);

https://searchfox.org/mozilla-central/rev/2c4b830b924f42283632b70f39a60fd36433dd4d/widget/windows/nsNativeThemeWin.cpp#1597

This would suggest background transparency is necessary for maximized windows to avoid this problem.

Comment 29

[MozillaFan]

I have the same Bug, super annoying. Only thing working is: browser.tabs.drawInTitlebar to false

Hope you guys can fix this soon!

Cheers

Comment 30

[MozillaFan]

I have 2 4K monitors, one above the other. chrome etc. work fine. firefox 93.0. win 10/11

Comment 31

[GASH]

(In reply to Kestrel from comment #27)

Can be avoided with the following userChrome.css:

:root[tabsintitlebar][sizemode="maximized"] {
  appearance: -moz-win-glass;
}

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=307a7a34013060a6a1e87dfbb911f058d0781a2e&tochange=57f68296c350469d73d788eb3695a898947b4acb

Regressed by Bug 1366405.

Thank you very much. I works perfectly and the bug is gone. I wonder why the other people igrnored this post.

Comment 32

[GASH]

(In reply to GASH from comment #31)

(In reply to Kestrel from comment #27)

Can be avoided with the following userChrome.css:

:root[tabsintitlebar][sizemode="maximized"] {
  appearance: -moz-win-glass;
}

Thank you very much. It works perfectly and the bug is gone. I wonder why the other people igrnored this post.

Comment 33

[Sunny]

Because it does not fix.

Comment 34

[GASH]

(In reply to Sunny from comment #33)

Because it does not fix.

Indeed. I was too fast. It works until you fullscreen a video on YT e.g.

Comment 35

[Coolishy]

At a guess i would say there something about how the newer versions of windows is handling the titlebar that is causing this issue.

Comment 36

[github]

(In reply to GASH from comment #34)

(In reply to Sunny from comment #33)

Because it does not fix.

Indeed. I was too fast. It works until you fullscreen a video on YT e.g.

It works for me..

I have the same problem with a setup of 2 monitors at the top and 1 at the bottom. Maximizing Firefox lets the titlebar bleed into the top two monitors.

Firefox 94.0.1 (64-bit)
Microsoft Windows [Version 10.0.19043.1288]

I can confirm that both:

Toggling browser.tabs.drawInTitlebar to false
or
Creating a userChrome.css and toggling 'toolkit.legacyUserProfileCustomizations.stylesheets' to true (see post above)
solve the problem.

Comment 37

[Sunny]

Toggling browser.tabs.drawInTitlebar to false

Unacceptable. This is no more solution than 'don't maximize your firefox'

Creating a userChrome.css and toggling 'toolkit.legacyUserProfileCustomizations.stylesheets' to true

Does not fix.

Comment 38

[Coolishy]

(In reply to Sunny from comment #37)

Toggling browser.tabs.drawInTitlebar to false

Unacceptable. This is no more solution than 'don't maximize your firefox'

Agreed

Creating a userChrome.css and toggling 'toolkit.legacyUserProfileCustomizations.stylesheets' to true

Does not fix.

Fixes it for me at least until I fullscreen a video.

Comment 39

[MozillaFan]

After 2 years I hope the developers can fix this natively. cause i guess its a problem for many people because lots of people have dual screen setups.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Given the number of dupes, can we get some more attention on this from the OSInt team?

Comment 42

[Albert Miller]

Mozilla Firefox Browser and the Mozilla Thunderbird both have this same bug.

I have tested many other applications looking for this problem on multiple PCs that use different video drivers (NVIDIA, AMD, Intel). I found that Firefox and Thunderbird are the only two applications that have this problem, regardless of the video driver.

Comment 43

[T]

Any news on this?

Comment 45

[David Parks [:handyman]]

Attachment: Bug 1614218: Do not adjust for resize region when maximized on Windows r=emilio!

As with the other 3 borders, the top of the window should not try to move the region offscreen. We were doing this and compensating for it with widget padding in the theme. The problem is that Windows uses a heuristic internally to determine when this happens and clip drawing that would fall on another monitor, but this fails when we take our (non-standard) approach. Instead, we can just set the client region normally in WM_NCCALCSIZE.

Comment 46

[David Parks [:handyman]]

Attachment: Bug 1614218: Clean up horizontal/vertical mixup in Windows widget r=cmartin!

InvalidateNonClientRegion mixed up these constants. They seem to always map to the same value on Windows so this doesn't change any behavior.

Depends on D143389

Comment 47

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0f6c40a96642
Do not adjust for resize region when maximized on Windows r=emilio
https://hg.mozilla.org/integration/autoland/rev/b46fde1669ca
Clean up horizontal/vertical mixup in Windows widget r=cmartin

Comment 48

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/0f6c40a96642
https://hg.mozilla.org/mozilla-central/rev/b46fde1669ca

Comment 49

[Norisz Fay [:noriszfay]]

Backed out per request for causing Bug 1764624

Backout link

Comment 50

[Iulian Moraru]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/4ddd4f1a1b27

Comment 51

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/4ddd4f1a1b27

Comment 52

[David Parks [:handyman]]

Win7/8.1 handle the non-client region very differently than Win10+. They don't set up the buttons in the DOM or use the ClientMarginHitTestPoint method to detect them. I'm considering normalizing the approaches instead of just trying to restore the old behavior. It could go either way.

Comment 53

[mnejing]

Same issue as others.

I have 3 monitors, two side by side, and a third sitting above the other 2, approximately in the middle (so basically a pyramid layout). I typically keep Firefox open on the right monitor, and the top of the window is clearly visible under the taskbar on my upper monitor. If I move the taskbar away from the bottom, then fullscreen windows WILL cover the edge of the Firefox window, but that's not ideal. Instead, I have a weird white bar visible under my taskbar that flashes fairly constantly. It's incredibly distracting.

This has been ongoing for ages, and clearly this thread shows it's been unresolved for literally years. Not sure how or why this happens. I'd really like it fixed. The proposed fixes in this thread are just generally not acceptable as long-term fixes.

I'm on what I believe is the most recent stable x64 release, 99.0.1. Running on Windows 10.

Comment 54

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/00324cb52293
Do not adjust for resize region when maximized on Windows r=emilio
https://hg.mozilla.org/integration/autoland/rev/7a3848fc8f8f
Clean up horizontal/vertical mixup in Windows widget r=cmartin

Comment 55

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/00324cb52293
https://hg.mozilla.org/mozilla-central/rev/7a3848fc8f8f

Comment 56

[David Parks [:handyman]]

I forgot the intermittent test failure this caused (bug 1764560). I'm going to turn off the test on Windows for a while -- the intermittent exposed that it hasn't been working this whole time anyway.

Comment 58

[Ciprian Georgiu, Desktop QA]

I've tried to reproduce this bug, but unfortunately I have only an external monitor to test the bug. The issue didn't reproduce on Win 10 x64, with my current set-up using an affected Nightly build (99.0a1, 20220301215224).

Hi haloflooder! Could you please help us verify if the issue is fixed on Beta 101. Or, maybe other reporters who encountered the bug more recently.

Comment 59

[Ray Kraesig [:rkraesig]]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #58)

Or, maybe other reporters who encountered the bug more recently.

On my current system (laptop with external monitor "above"), the bug is exhibited by the current Release build (100.1), but not by the current Nightly build (102.0a1, 20220518094725).

Comment 60

[Ciprian Georgiu, Desktop QA]

Thanks, Ray for verifying this! I can also reproduce the bug now on Release 100.1, with a different laptop connected to an external monitor.

The issue is verified as fixed on Beta 101.0b8 under Windows 10 x64.

Comment 61

[keifanel]

Attachment: Firefox Nightly with Firefox stable behind it. Notice how the window size gets very slightly smaller with titlebar enabled. This smaller window is the "correct" size.

I suffer from a similar sounding bug, that still occurs on the newest Nightly version. While using PowerToys FancyZones to create zones that windows can snap to, Firefox is the only one of hundreds that I tested that doesn't sit perfectly inside the zone. Instead, it "overflows" a bit. This can be "fixed" by enabling title bar, presumably because task of rendering border is offloaded to Windows, but I don't consider that a fix. You can notice Firefox getting smaller by a few pixels even without FancyZones if you toggle "title bar" option.

I attached a GIF showing the very slight difference between their sizes. Notice how there seem to be a second, white border around Nightly window with titlebar enabled. This is Firefox Stable without titlebar, which is a few pixels wider.

I noticed that changing chromemargin attribute in #main-window via userchrome developer tools sort of fixes it. Changing it from default 0,2,2,2 to 0,0,0,0 snaps the window perfectly flush with other ones, but it lacks rounded corners from Windows 11.

Comment 62

[David Parks [:handyman]]

Hi keifanel. What you are describing sounds like a separate issue. You can file a new bug with the info you collected.

Comment 63

[Fabian Sigrist]

Attachment: If Firefox 101 is snapped to the side of a screen it still bleeds into the other screen

I have just updated to Firefox 101, but my Firefox window still bleeds into my left (2x1 setup) monitor, when it is snapped to the left side of the right monitor. Is this the same bug and FF 101 should've fixed it or is this another bug? If I submitted this in the wrong place/way help, is appreciated!

I'm on Windows 11 Build 22000.675, my right screen (main) is 2560x1440 and the left screen 1920x1080.

I have attached an image of the bug, you can see the bleed in the middle of the screen. It's just a few pixels, but it's really bugging me.

Comment 64

[Itsa Fakename]

This appears to still be happening on 104.0.2. Is there a regression?

Ciprian - How did you verify the change, so I can make sure my setup is the same. Also, are you able to point me to the patch(es) that supposedly address this? I'm happy to dig in and lend some effort, but I'm not familiar with this bug tracking site or which repo to look through for patches. Thanks!

Comment 65

[Sunny]

(In reply to Itsa Fakename from comment #64)

This appears to still be happening on 104.0.2. Is there a regression?

No problem with 104.0.2 here, bug is still fixed.

Comment 66

[Ciprian Georgiu, Desktop QA]

The pat(In reply to Itsa Fakename from comment #64)

This appears to still be happening on 104.0.2. Is there a regression?

Ciprian - How did you verify the change, so I can make sure my setup is the same. Also, are you able to point me to the patch(es) that supposedly address this? I'm happy to dig in and lend some effort, but I'm not familiar with this bug tracking site or which repo to look through for patches. Thanks!

Sorry for my late reply, I was on PTO.

No, this is still fixed for my as well using FF 104.0.2, under Win 10 x64 with an external 2560x1440 monitor connected to a Dell laptop which has the resolution set to 1080p.

The patches with this fix can be found in comment 54.