1254020 - Dropdowns and scrollbars look awful with Windows on Retina display

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[(No longer employed by Mozilla) Aaron Klotz]

Macbook Pro Retina, Windows 10 bootcamp

Scrollbars and dropdown buttons are really tiny. Looks like they aren't being scaled to high DPI.

Comment 1

[Jonathan Kew [:jfkthame]]

Could you attach a screenshot of what you're seeing? Thanks.

Comment 2

[Honza Bambas (:mayhemer)]

On a real win10 box with fullHD display and 125% upscale I don't see any problems.  Screenshot would help tho.

Comment 3

[Jonathan Kew [:jfkthame]]

:aklotz, could you attach a screenshot showing examples of this problem with latest Nightly, please? I haven't seen it on my windows hi-dpi system, but wonder if it's somehow a bootcamp issue...

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

I was able to repro after having Fx maximized on a lower dpi external monitor, and then unplugging the monitor. When Fx was moved to my retina, it continued to use the previous dimensions for the themed controls.

I'll upload a screenshot when I get a chance.

Comment 5

[Bogdan Maris, Desktop Test Engineering [OOO until Dec 16th]]

Attachment: Screenshot showing the issue

I was able to reproduce this on a Windows 10 and 8.1 machine with low and hi-dpi monitors. 
Maximized FF on hi-dpi screen, unplugged hi-dpi screen, FF switched to low-dpi. The other way around (unplug the low-dpi screen) the issue did not reproduce.

Comment 6

[Bogdan Maris, Desktop Test Engineering [OOO until Dec 16th]]

Forgot to mention that I used latest Nightly and DevEdition to test this. I also went ahead and test with old Nightlys and I got this: 

Nightly 2016-01-12 - not affected (per-monitorDPI was not enabled)
Nightly 2016-01-14 - Affected (per-monitorDPI enabled)

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #5)
> Created attachment 8733899 [details]
> Screenshot showing the issue
> 
> I was able to reproduce this on a Windows 10 and 8.1 machine with low and
> hi-dpi monitors. 
> Maximized FF on hi-dpi screen, unplugged hi-dpi screen, FF switched to
> low-dpi. The other way around (unplug the low-dpi screen) the issue did not
> reproduce.

Aha, thanks; I've been able to reproduce this, too.

Which direction it reproduces is dependent on which of the screens was your primary monitor, I think. I've been able to trigger the problem in both directions (resulting in either oversized or miniature controls), by varying my display configuration.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Always compute theme scaling factor when per-monitor dpi aware, even if only a single display is currently present

The issue here arises when the system's primary display is removed, leaving a single display whose DPI does not match the (fixed-until-signout) Windows system scaling. Because of cases like this, we can't short-circuit the theme-scale computation even if there's only a single monitor present, as it may nevertheless differ from the system DPI.

Comment 9

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/05cf733d5b26369caeca4550a0d33e9fd099b622
Bug 1254020 - Always compute theme scaling factor when per-monitor dpi aware, even if only a single display is currently present. r=emk

Comment 10

[Jonathan Kew [:jfkthame]]

Comment on attachment 8734317 [details] [diff] [review]
Always compute theme scaling factor when per-monitor dpi aware, even if only a single display is currently present

Approval Request Comment
[Feature/regressing bug #]: 890156 (per-monitor dpi)

[User impact if declined]: potential for incorrect scaling of controls after certain types of change to display configuration

[Describe test coverage new/current, TreeHerder]: manually

[Risks and why]: minimal, just removing a shortcut that is not always valid

[String/UUID change made/needed]: none

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/05cf733d5b26

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Aaron, could you please verify the fix on a latest Nightly build? Thanks!

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8734317 [details] [diff] [review]
Always compute theme scaling factor when per-monitor dpi aware, even if only a single display is currently present

per-monitor DPI related fix, Aurora47+

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/fa1e44b04c91

Comment 15

[(No longer employed by Mozilla) Aaron Klotz]

LGTM. Thanks!

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Verified based on comment 15.