Dialog boxes are not scaled if Firefox is dragged from a low dpi display to another one with a high dpi

NEW
Unassigned

Status

()

Core
Widget: Win32
P3
normal
3 months ago
28 days ago

People

(Reporter: ciprian_georgiu, Unassigned)

Tracking

({regression})

Trunk
All
Windows 10
regression
Points:
---

Firefox Tracking Flags

(firefox55 wontfix, firefox56 fix-optional, firefox57 wontfix)

Details

(Whiteboard: tpi:+)

Attachments

(1 attachment)

Created attachment 8904522 [details]
screenshot showing this issue.png

[Affected versions]:
- latest Nightly 57.0a1
- Beta 56.0b9
- RC 55.0.3

[Affected platforms]:
- Windows 10 x64

[Prerequisites]:
- 2 monitors: one with a low dpi (I used WSXGA Samsung 2233) and another one with a high dpi (Dell UHD-1 P2415Qb) 

[Steps to reproduce]:
1. Open Firefox on 1st monitor (with the lower resolution) and have some random tabs opened.
2. Drag Firefox to the 2nd monitor (with higher resolution).
3. Click on close button (X).
 - observe the "Confirm close" dialog

[Expected result]:
- The "Confirm close" dialog box is properly scaled after is dragged to a HiDPI monitor.

[Actual result]:
- The "Confirm close" dialog box is not scaled in the HiDPI monitor.

[Regression range]:
- This seems to be an old regression as I cannot reproduce on Firefox 10. I will follow-up with a regression range asap.  

[Additional notes]:
- I can see this behavior only on Windows 10 (OS Version 1607), on W7 and W8.1 is not reproducible. While testing the lower resolution display had 125% level scaled and the higher one 200%
- see the attached screenshot
status-firefox55: affected → wontfix
status-firefox56: affected → fix-optional

Updated

2 months ago
Priority: -- → P3

Updated

2 months ago
Whiteboard: tpi:+

Comment 1

2 months ago
I managed to reproduce the bug on Windows 10x64 using beta 56.ob9 and latest Nightly (2017-10-04).
This is an old regression.

Last good buildid: 20160716030215 (2016-07-16)
First bad buildid: 20160717030211 (2016-07-17)
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4c05938a64a7fde3ac2d7f4493aee1c5f2ad8a0a&tochange=711963e8daa312ae06409f8ab5c06612cb0b8f7b

I hope this pushlog is helpful, because I had it to create it manually. Neither mozregression or Firefox Regression Range Link Maker (https://bsmedberg.github.io/firefox-regression-range-finder/) generated a pushlog for this two builds. 

It might be this bug 1283959 which regressed this behaviour, but I am not sure.
Keywords: regressionwindow-wanted

Updated

28 days ago
status-firefox57: affected → wontfix
You need to log in before you can comment on or make changes to this bug.