Closed
Bug 1254020
Opened 8 years ago
Closed 8 years ago
Dropdowns and scrollbars look awful with Windows on Retina display
Categories
(Core :: Widget: Win32, defect)
Tracking
()
VERIFIED
FIXED
mozilla48
People
(Reporter: bugzilla, Assigned: jfkthame)
References
(Depends on 1 open bug, Regressed 1 open bug)
Details
Attachments
(2 files)
159.73 KB,
image/png
|
Details | |
1.27 KB,
patch
|
emk
:
review+
ritu
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Macbook Pro Retina, Windows 10 bootcamp Scrollbars and dropdown buttons are really tiny. Looks like they aren't being scaled to high DPI.
Assignee | ||
Comment 1•8 years ago
|
||
Could you attach a screenshot of what you're seeing? Thanks.
Flags: needinfo?(aklotz)
Comment 2•8 years ago
|
||
On a real win10 box with fullHD display and 125% upscale I don't see any problems. Screenshot would help tho.
Assignee | ||
Comment 3•8 years ago
|
||
: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...
Reporter | ||
Comment 4•8 years ago
|
||
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.
Flags: needinfo?(aklotz)
Comment 5•8 years ago
|
||
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•8 years ago
|
||
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)
Assignee | ||
Comment 7•8 years ago
|
||
(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.
Assignee | ||
Comment 8•8 years ago
|
||
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.
Attachment #8734317 -
Flags: review?(VYV03354)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Updated•8 years ago
|
Attachment #8734317 -
Flags: review?(VYV03354) → review+
Assignee | ||
Comment 9•8 years ago
|
||
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
Assignee | ||
Comment 10•8 years ago
|
||
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
Attachment #8734317 -
Flags: approval-mozilla-aurora?
Comment 11•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/05cf733d5b26
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Hi Aaron, could you please verify the fix on a latest Nightly build? Thanks!
Flags: needinfo?(aklotz)
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+
Attachment #8734317 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 14•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/fa1e44b04c91
Verified based on comment 15.
Status: RESOLVED → VERIFIED
Updated•4 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•