[Note]: - This started to reprduce with from 2016-01-14, when per-monitor DPI was implemented. - Tested using two monitors: Full HD(secondary monitor) and 4k as primary [Affected versions]: - 48.0a1 Nightly - 47.0a2 Aurora [Affected platforms]: - Windows 10 x64 [Steps to reproduce]: pre-requisite: make sure 2 monitors with different resolutions are attached 1. Open Firefox on the primary monitor. 2. Drag it to the secondary monitor and observe the titlebar buttons. [Expected result]: - The minimize/maximize/close buttons in the titlebar are properly displayed. [Actual result]: - The buttons are very wide. [Examples]: http://i.imgur.com/ZEAcYgN.png http://i.imgur.com/Vc1KAeQ.png http://i.imgur.com/7ulWcjt.png
This does not reproduce on Windows 8.1 though (low and hi-dpi monitor), the buttons (although large, are scaled properly).
What's actually happening here, I think, is that the titlebar buttons are sized according to the primary monitor's DPI, just as they are on Win 8.1 (and therefore they appear very big on a lo-dpi screen when the primary is hi-dpi); but whereas on Win 8.1 we let Windows do the actual rendering of the buttons (so their appearance matches their large size), on Win 10 we instead render our own SVG assets for the symbols in the buttons, and *that* rendering is scaled according to the current screen's DPI. As a result, we get minimize/maximize/close symbols that are scaled appropriately for the screen, but they're placed within button rectangles that are scaled according to system DPI, and therefore look very big on a secondary lo-dpi screen. And as the buttons have no outline or background (until hovered over, it looks like there's simply too much spacing. Hovering over the buttons, so that their background changes color, makes it clearer that what we have here are oversized (as expected) buttons with reduced-size (what we'd prefer, if Windows would scale the titlebar properly!) symbols within them. I guess the fix we need is to somehow prevent that scaling of the SVG icons we're using, to match the fact that Windows doesn't scale the titlebar and its contents according to per-monitor DPI.
[Tracking Requested - why for this release]: User-visible UI regression. (In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #2) > What's actually happening here, I think, is that the titlebar buttons are > sized according to the primary monitor's DPI, just as they are on Win 8.1 > (and therefore they appear very big on a lo-dpi screen when the primary is > hi-dpi); but whereas on Win 8.1 we let Windows do the actual rendering of > the buttons (so their appearance matches their large size), on Win 10 we > instead render our own SVG assets for the symbols in the buttons, and *that* > rendering is scaled according to the current screen's DPI. Hmm. I thought that we controlled the size of the buttons with fixed CSS sizes for win10... I'll look at trying to reproduce this later this week once I dig out from post-PTO email piles.
tracking-firefox47: --- → ?
So, I can't reproduce this with my >100% DPI surface pro 3 (running win10) hooked up to the 100% DPI external screen that I have, on current Nightly. A couple of questions: 1) Cornel/Bogdan, can you reproduce this still on current nightly? Can you get it to reproduce with one of the surface pros that you guys have and provide more precise STR? 2) Does this ever reproduce with the main Firefox window? All the screenshots are from secondary windows, but the steps to reproduce does not talk about this. 3) Jonathan, can you reproduce this yourself? If so, see question (2), but also: the titlebar buttons are indeed using SVG - but only on the main window. The secondary window buttons (or, if you disable tabs-in-titlebar by "enabling the titlebar" in customize mode, even the buttons in the main Firefox window) are the "real thing", ie they are rendered by Windows. In which case, is this a Windows issue, or one where we don't provide it with the right information, or...?
OK, after looking at this some more, I agree it seems to be a Windows issue -- probably will be fixed (or at least fixable) in the next Windows version, when there will be APIs to allow us to opt in to properly-scaled rendering of the non-client area. To show the issue on a hi-dpi machine (even without a second monitor), you should be able to do the following (tested on my ultrabook where the default/recommended setting is 150% scaling): * Ensure Windows 10 is set to a hi-dpi mode (e.g. 150% or 200% scaling), and sign out/back in to ensure a "clean" system dpi setting. * Launch Nightly and choose the Customize mode. * Toggle the title bar on and off; notice how the window controls are rendered with (virtually) the same spacing and icon sizes in either mode. * Now use Windows Settings to change the scaling to 100%, making everything appear smaller, but do *not* sign out of Windows (so the system dpi will not yet be updated; this gives a result similar to moving the window to a lower-dpi secondary display). * Return to the Nightly window in Customize mode, and toggle the title bar on and off again; notice how the rendering of the window controls is now significantly different between the two modes. With no titlebar (i.e. using our tabs-in-titlebar rendering), they're scaled down and closer together, appropriately for the scaled-down window. But with the titlebar present (i.e. using the "real" Windows rendering) the icons are scaled down, but the button sizes (and therefore the spacing of the icons) remains as large as the hi-dpi setting. I see very similar behavior in IE11; running on a low-dpi secondary display, or after changing the scaling as described above, the window controls show scaled-down icons but within unscaled button areas, so the spacing seems excessive. (Edge doesn't suffer from this issue; I believe this is because it doesn't use Windows "native" rendering of the window frame/controls at all, it reproduces all this itself in the client area.)
Given that this seems to be a Windows issue, related to the lack of proper support for per-monitor dpi scaling (or dynamic resolution changes) in the non-client area rendering (and that we're told there will be API to address this in a future release), I think there's probably nothing for us to do here at the moment. But we can keep the bug open, pending the arrival of the APIs we need to fix it.
(In reply to :Gijs Kruitbosch from comment #4) > So, I can't reproduce this with my >100% DPI surface pro 3 (running win10) > hooked up to the 100% DPI external screen that I have, on current Nightly. A > couple of questions: > > 1) Cornel/Bogdan, can you reproduce this still on current nightly? Can you > get it to reproduce with one of the surface pros that you guys have and > provide more precise STR? > 2) Does this ever reproduce with the main Firefox window? All the > screenshots are from secondary windows, but the steps to reproduce does not > talk about this. I can confirm the investigation done by Jonathan, so it does look like a Windows issue. I used a Dell XPS 12 to check the scale down way of reproducing and Hidpi+lowdpi screen.
Given that this is a windows issue and nothing that can be done from our side, I do not feel the need to track it for Fx47. I also consider it a polish issue as such and not a release blocker. Please let me know if you disagree.
tracking-firefox47: ? → -
As we're now into RC builds, this is wontfix for 47.
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
status-firefox49: --- → affected
I can't reproduce this issue (either comment 0 or comment 5) with my Surface Pro running the latest Windows 10 (Anniversary edition, not an Insider build). I've got a external monitor at 100%, and the Surface screen at 200%. Comment 0 wouldn't reproduce with either of the monitors set as primary. Cornel - is this working for you now too? (Check for an up-to-date Windows.)
Created attachment 8785975 [details] title bar.PNG I have reproduced this issue using the STR from Comment 5 on the latest Nightly 51.0a1 build (id: 20160829030202) on a Windows 10 x64 OS. Please keep n mind that this issue reproduces ONLY as long as you don't sign out of Windows and does NOT reproduce after you do or after an OS restart. I could NOT reproduce the issue with the STR from comment 0.
Wontfix for 49, while this would be nice to fix, it seems like an edge case we don't need to keep triaging in the platform meeting.
status-firefox49: affected → wontfix
(In reply to Alexandru Simonca, QA (:asimonca) from comment #11) > I have reproduced this issue using the STR from Comment 5 on the latest > Nightly 51.0a1 build (id: 20160829030202) on a Windows 10 x64 OS. > Please keep n mind that this issue reproduces ONLY as long as you don't sign > out of Windows and does NOT reproduce after you do or after an OS restart. > I could NOT reproduce the issue with the STR from comment 0. I wasn't signing out when I was testing. Can you confirm you're on the newest Windows 10 "anniversary edition" update? Comment 2 suggests this is an OS bug, so likely depends on the Windows 10 version you're running.
Indeed, it was the Windows build that did the trick. I updated to the latest "Anniversary Edition" and couldn't reproduce anymore. Please ni? me for further assistance, if necessary.
Marking invalid as this is an OS bug that is now fixed, so there doesn't seem to be anything we could/should do about this.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Actually we did something about this because the new Windows feature (per-monitor non-client DPI scaling) is opt-in.
Resolution: INVALID → DUPLICATE
Duplicate of bug: 1270954
You need to log in before you can comment on or make changes to this bug.