1354102 - Dialogs are displayed at the wrong size when moved back and forth between screens with different dpi

Status: RESOLVED WORKSFORME

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

Description

[Florian Quèze [:florian]]

I saw this on a Windows 10 laptop with an HiDPI internal screen and a lowdpi external screen, with Firefox windows on both screen.

When closing a window with multiple tabs on the external screen, I got a giant confirmation prompt. See http://i.imgur.com/vONKERX.png

Comment 1

[Kartikaya Gupta (email:[e-mail])]

This one should be fixed by bug 1387340 which is on Nightly. Can you confirm?

Comment 2

[Chris Morgan]

This is mostly fixed; but the window sizes are not always quite correct.

My primary display is 2×. My external displays are 1×. In the past, things like the Confirm close dialog and the Help → About Nightly window have always been at 2× size, regardless of which screen they’ve been on.

I used continued to use these two test subjects: the “Confirm close” dialog, and the Help → About Nightly window (which is chrome://browser/content/aboutDialog.xul).

Screenshots: https://imgur.com/a/OuJK5

The incorrect window sizing occurs when the window is opened on the 1× display, or when it is opened on the 2× display, moved to the 1× display and then moved back to the 2× display (after which the window is stuck in the wrong size, not amplifying the error with each cycle through the different DPIs).

The window sizes are all a bit inconsistent. On the aboutDialog at 1×, the height difference is 19px and width difference 15px; on the confirm close dialog at 2×, it’s a height difference of 75dpx (37.5px) with no width difference.

My initial guess (based on a little DPI-awareness fiddling in Windows) is that calculations around the window chrome size (title bar and possibly edges) are being done incorrectly, but I’m not at all confident of that analysis given the apparent inconsistencies.

Comment 3

[Florian Quèze [:florian]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> This one should be fixed by bug 1387340 which is on Nightly. Can you confirm?

Yes. I reproduced the bug again on a Nightly from 2018-01-08. After upgrading to the current Nightly (2018-01-16), I can't reproduce anymore. This matches the time frame when the fix in bug 1387340 landed.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Thanks. We're going to leave this bug open to continue tracking the issue in comment 2.

Comment 5

[Nate Graham]

I experience this in KDE Plasma on Linux too. See upstream bug report: https://bugs.kde.org/show_bug.cgi?id=491762

Comment 6

[Ray Kraesig [:rkraesig]]

(In reply to Nate Graham from comment #5)

I experience this in KDE Plasma on Linux too. See upstream bug report: https://bugs.kde.org/show_bug.cgi?id=491762

This was a Windows-specific bug. Moreover, both the original bug and the lesser bug in comment #2 appear to be resolved, the latter apparently sometime around 2022-09-29 per mozregression. Closing as WORKSFORME.

If you believe what you're seeing is a Firefox bug rather than a KDE Plasma bug, please open a new bug in the appropriate category.