¡Hola!

Steps:
Maximize a Nightly window (press Windows + Up arrow keys) to a secondary monitor.

Actual result:
A line of white pixels is seen on the left, bottom and right of the maximized window. Please see attached screen captures.

Expected result:
The border is the color of the theme set in the Windows preferences.

Build Configuration:
Built from https://hg.mozilla.org/mozilla-central/rev/e7163954456087c31980de0c22fba01096bfadd8

¡Gracias!
Alex

Is this a recent regression?

Waiting for the reply from Alex.
In the meanwhile, in an attempt to reproduce the issue did not reproduce with the live build 74.0a1 (2020-01-14) nor with the one from the provided link.
Check perfomed on an AMD and Intel PC, second of which had webrender enabled.

Any additional settings that might cause this?

¡Hola Dão!

I tried with Mozregression-gui and the issue exists as far back as this:

app_name: firefox
build_date: 2018-08-03
build_file: C:\Users\Alex.mozilla\mozregression\persist\2018-08-03--mozilla-central--firefox-63.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2018/08/2018-08-03-22-02-59-mozilla-central/firefox-63.0a1.en-US.win64.zip
changeset: c4c1a90df788b7634da5a89f417bf55198172640
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b72cd47198be4022905e23cf56407ce68ecbcf02&tochange=c4c1a90df788b7634da5a89f417bf55198172640
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

The tool doesn't let me go further back.

Also, forgot to mention this is only seen on windows maximized to a secondary monitor not the main laptop display.

Hope this helps.

¡Gracias!
Alex

Bugbug thinks this bug is a regression, but please revert this change in case of error.

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

For more information, please visit auto_nag documentation.

This is on old regression and an edge case, marking as fix-optional for 74.

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

For more information, please visit auto_nag documentation.

Hey Alex, a few questions -

1. can you post your about:support?
2. what DPI setting are you using?
3. where's your taskbar positioned?

¡Hola Jim!

1. Please find the contents below.
2. The external monitors where this happens are set to 125% in scale, their resolution is 2160 x 3840, one of them is Portrait (flipped) and another one is Landscape.
3. The taskbar is on the left on the laptop screen and bottom on the external monitors.

Hope this helps.

¡Gracias!
Alex

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

For more information, please visit auto_nag documentation.

Since the Regression window is already provided I will remove the flag for this issue.

Issue is reproducible with Windows 10x64 with 2 external displays, one set to 125% in scale, resolution 1920x11080. Issue occurs after dragging the maximized browser window from one display to another.

Hey Gabi, can you provide a screenshot of what you're seeing?

This happens to me too, occasionally. I'll try to post a screenshot once I manage to reproduce.

(In reply to Itiel from comment #19)

This happens to me too, occasionally. I'll try to post a screenshot once I manage to reproduce.

Nope, apparently the cause for this in my Windows is another app. Unrelated to Firefox.

(In reply to Jim Mathies [:jimm] from comment #18)

Hey Gabi, can you provide a screenshot of what you're seeing?

Here is a screenshot of what I am seeing: laptop+monitor.png. Draged the maximized Firefox window from a laptop to an external monitor scaled to 125%, observe on right, left and bottom of the monitor a line of white pixels. Note that it is reproducible with 88.0a1 nightly only, with beta 87.0b4 not reproducible.

¡Hola y'all!

I'm unsure is this is a whole new bug or just a variant of https://bugzilla.mozilla.org/show_bug.cgi?id=1609129

Commenting here so I don't forget.

Can someone here confirm perhaps, por favor?

¡Gracias!
Alex

I'm not sure 1723539 is actually a duplicate of this one as the issue (at least for me) seems to be exclusively relating to the title bar itself. That said, you guys know your pixel rendering process so it may indeed be.

The pixels get a nice round border in Windows 11!

Here's my about:support. The pixels happen on the primary monitor.

Primary: AW3418DW@3440x1440 / Secondary: Cintiq Pro 24 @ 4k / RTX2080

And getting the pixels to show up is just a matter of minimize/restore on the primary monitor.

Additional data points -

1. Definitely tied in some way to a dual monitor setup, removing one screen from the device fixes the issue.
2. Checked in safe mode and with the OS compositor turned off, issue still reproduces. This implies the issue is not caused by NVidia's drivers or graphics pipeline code.
3. The setup is unique - dual monitors, one of which is 4K. Specific monitor orientation and layout settings, and mixed graphics refresh rates.
4. scaling settings - 100% on the primary monitor, 175% on the secondary

My feeling right now is that this is not Graphics related. I'm also not convinced this is a widget bug, it might be related to something going wrong in Layout.

ni'ing Frank, maybe the Layout Team can read this over and suggest additional steps we might take to try and debug.

Note, David Parks is out for a bit, so he won't be able to work on this in the near future.

Do we know for sure that this is a Firefox-specific issue? (i.e. is it possible this is just a bug in Windows that affects all programs?)

I spent some time this morning trying to reproduce this, and I couldn't repro via fullscreening my windows. But I could repro something like this, via "left-half-of-screen" snapping my window (dragging it to the left edge of my 4K display, where the left edge happens to be the "seam" between the monitors). In my case:

• instead of a thin line of white pixels, I got a thick line of transparent pixels
• similar to comment 31, minimize/restore are sufficient to fix the issue.
• ...and importantly, I can also reproduce with Chrome and with cmd.exe (i.e. the Windows terminal)

I'll post a screenshot to demonstrate what I saw, using Chrome as the affected app in this case.

Here's a screenshot of the configuration that I was using when I captured the above screenshot. Monitor #1 is a Dell 24" 1920x1200 with 100% scaling; Monitor #2 is a Samsung 27" 4K display, 3840x2160, with 125% scaling. I think the precise "offset" geometric arrangement of the monitors in the diagram at the top made a difference, too, though I'm not entirely sure.

(I tried a variety of other configurations/resolutions/scale factors based on earlier comments here, and wasn't able to reproduce any issues beyond this thick-transparent-border on the "snapped-to-half-of-the-screen" type of window.)

jimm, given that you have a configuration that can reliably reproduce the fullscreen issue -- would you mind getting back into that configuration, verifying that you can repro with Firefox (to be sure you've got the right setup), and then testing whether you can trigger it with other apps as well, (cmd.exe, and Chrome-with-a-dark-theme)?

Adding Botond's email comments.... Jim if you can follow Daniel's line of questioning, that would help.

Hi Frank,

I read through the bug. Haven't really seen anything to suggest an APZ
relation. Based on the fact that it involves (1) external monitors and
(2) scaling settings, my suspicion is perhaps some sort of rounding
error, perhaps in Widget code (though I don't think we can rule out
Layout code, and in any case the two are kind of interdependent, in
that Layout ultimately gets window sizing information from Widget
code).

The debugging strategy that occurs to me to narrow down the problem,
is to look at a display list dump, and see if the wrong sizes (1 pixel
too short) show up there. If not, that would suggest the issue is
"later in the pipeline" (WebRender or Widget code). If so, we'd need
to additionally narrow down whether the window sizing information we
get is wrong to begin with, or if an error is introduced during layout
calculations.

Hope that helps as an idea for a starting point / approach.

Thanks,
Botond

(In reply to Daniel Holbert [:dholbert] from comment #37)

jimm, given that you have a configuration that can reliably reproduce the fullscreen issue -- would you mind getting back into that configuration, verifying that you can repro with Firefox (to be sure you've got the right setup), and then testing whether you can trigger it with other apps as well, (cmd.exe, and Chrome-with-a-dark-theme)?

I wasn't able to reproduce as I do not have a 4K secondary. I was just relaying information off Reddit in my post. Looks like Timea was able to rerpo this, maybe she can confirm this happens in other apps.

Redirecting this to the right Timea that confirmed the issue.

This may be on point:
https://stackoverflow.com/questions/45110655/the-recommended-window-size-sent-with-the-wm-dpichanged-message-is-too-big

So we may well be getting bad advice from Windows here. Minimize+restore (comment 31 and comment 34) would then do another resize, so it makes sense that they would clean up the mess.

As stated by the SE reporter, who resolved the issue and seems to have the patience of a saint, WM_GETDPISCALEDSIZE can override the suggestion. I would think you could just ignore it but the docs for WM_DPICHANGED say:

The expectation is that apps will reposition and resize windows based on the suggestions provided by lParam when handling this message.

I don't know what "expectation" means but I probably don't want to find out.

I'm not yet set up to reproduce this.

I mention that I don't have a 4K secondary monitor either. What I reproduce on any site and with any picture, I think that's how it's designed nightly versus beta. I don't know if that's the issue. I attached a screenshot to se the extra lines around the window, I see this extra lines both on laptop and on secondary monitor too.

zstimi, two questions/requests for you:

(1) can you see whether you can reproduce this with Chrome, and also with the windows cmd.exe terminal? (see comment 37 - to the extent that I can reproduce this bug, I can also reproduce it with those applications as well, and hence I'm guessing this is a general Windows bug rather than a Firefox bug.)

(2) Your observation is interesting about this seeming Nightly-specific (and not affecting beta), in comment 42 and comment 22. If that's true, that does suggest that there's a bug to be fixed on our end here (or perhaps some Windows footgun that we could avoid). Have you verified this behavior-difference with fresh profiles in both Nightly and Beta? (In particular, I'm not sure whether you've confirmed that this bug affects Nightly-with-a-fresh-profile -- in both of the screenshots you posted that showed the bug, it looks like the Nightly profile is a regular browsing profile -- there are other tabs open in comment 22, and there are some bookmarks on the Nightly bookmarks-toolbar in comment 42.)

Thank you!

(1) I don't see those extra white lines either around chrome and around the terminal.
(2) With fresh profile and with about:welcome page using nightly, see some extra white line on left, bottom and right part of the maximized window, on laptop and on the secondary monitor too, the lines are present as if it were an intentionally designed border on nightly.
I hope this helps you!

OK, thanks for testing that. Good to know that it does seem Firefox-Nightly-specific on your machine (with beta, Chrome, and cmd.exe unaffected).

handyman's Comment 41 seems to be the closest thing we have to a theory about what's going on here; hopefully someone can follow that thread at some point.

Still looking around...

I cannot reproduce this with any configuration of monitors I have but I can reproduce it using either a small code change or by changing an esoteric Windows setting. I think this is probably close to being the cause.

First, this bug seems to have consolidated a number of actual issues. The issue I'm looking at has the following STR:

--

1. Have two monitors with different Windows DPI settings. I'm using a 3840x2160 display at 150% scale as my source monitor (the one I am dragging from) and a 2560x1440 display at 100% as my destination monitor. The destination monitor is set as my primary monitor, although I don't think this matters.
2. Launch Firefox and put the window on the source (high DPI) monitor.
3. Maximize the Firefox window. This is required.
4. Drag the window to the destination monitor. It will exit maximize mode immediately during dragging.

Expected:
The window looks fine on the destination monitor.

Actual:
A thin (depending on the distance between the two DPI settings) white line around the window border, except at the top. For dramatic effect, I can set the high DPI monitor to 350% and the white bars on the 100% DPI monitor become comical.

--

First, the programmatic way to reproduce this is to remove the WM_DPICHANGED handler, although the only line that needs to be removed is this.

Alternatively, I can override Firefox's requested per-process per-monitor DPI setting (in Windows 10, at least) by:

• Right click on the icon for Firefox in the dock or in explorer. (If in the dock, also right-click Firefox again in the popup menu). Choose "Properties" from the popup menu. Go to the Compatibility tab, select "Change high DPI settings" and check "Override high DPI scaling behavior. Scaling performed by:". Make sure the adjacent dropdown is set to "Application" and apply the changes in the original Properties window. If running Firefox, restart it.

I would have thought that the second method was just setting it to the default behavior but that is wrong. Using spy++, I can confirm that WM_DPICHANGED is not sent in this mode.

For the record, the mNonClientOffset calculations are where this fails. I haven't yet figured out why maximizing first is essential. I thought it might be that the maximize calculations were being used in the WM_DPICHANGED message but the size mode is changed from nsSizeMode_Maximized to nsSizeMode_Normal the moment you first move the window to drag it. I also tried ignoring when the size mode is set back to normal but that did not reproduce the issue.

I'm wondering if Windows is choosing not to send the WM_DPICHANGED message for the affected machines (and why).

Can someone who can reproduce this check that the "Override high DPI scaling behavior" isn't checked in their Firefox properties?

Side note: I can also reproduce this by messing with the WM_NCCALCSIZE calculations, but I think they are basically correct. See chromemargin in html and c++ code.

In conversations with Timea, I've got a lot of new data that suggests this is yet another variant of this bug:

• Timea's issue is nightly-only. The issue doesn't even reproduce with try builds.
• The issue is different than others, like :dcamp's issue in comment 31. Nothing makes the white lines go away once they appear. Not minimizing+restoring. Not dragging back to the other monitor. Not maximizing the window.
• Most notably, nightly build processes are running "Per Monitor" instead of "Per Monitor (v2)", as the other builds are. This can be seen in Task Manager -- in the details tab you have to add the "DPI Awareness" column. This must be the issue. (NB: the Network process always runs DPI "Unaware" for any machine/build anywhere. I'm not sure why but this is not important.)
• "Override high DPI scaling behavior" would certainly be suspect but it is not checked. Setting it would change the DPI Awareness though. Also, the symptoms are different -- the override behaves like comment 31.

The investigation is ongoing -- I don't know what is causing nightly to ignore the DPI setting in the manifest. I suspect something related to dpi awareness is responsible for other issues in this bug (except the ones where maximized windows bleed into other monitors -- I think that's something else).

If you can reproduce the white lines, in addition to your "Override high DPI scaling behavior" setting (comment 47), I'm now also interested in what Task Manager says about your DPI Awareness. NI to Alex and dcamp for this info.

¡Hola David!

Thanks for looking into this.

The Nightly I have, built from https://hg.mozilla.org/mozilla-central/rev/0283aba1bf2069cfff3ee77c86162fb153a55fc2 , says "Per-Monitor (v2)"

FWIW on the desktop I currently have access to the bug I'm seeing is https://bugzilla.mozilla.org/show_bug.cgi?id=1528747#c7 and not this specific one.

Hope this is helpful.

Please ni? again if there's anything else y'all need from the profile or device, please note it might be a few months until I can access the desktop where I 1st observed this bug.

¡Gracias!
Alex

The severity field for this bug is relatively low, S4. However, the bug has 5 See Also bugs.
:handyman, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.