1254026 - Save As and Open File dialogs are not scaled according to secondary display's resolution

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[(No longer employed by Mozilla) Aaron Klotz]

Macbook Pro Retina, bootcamp Windows 10

Bring up a Save As dialog. The dimensions of the dialog box are fine, the dimensions of the pushbuttons are fine, but everything inside of it is too small.

Comment 1

[Jonathan Kew [:jfkthame]]

Screenshot, please. Do you have an external display as well, or only the MBP's retina screen?

Comment 2

[Honza Bambas (:mayhemer)]

As well here... no problem for me.  Save as dialog is a windows widget.

Comment 3

[Jonathan Kew [:jfkthame]]

On Win8.1, the Save As dialog is displayed according to the system's primary monitor's resolution. So if you have a lo-dpi primary display, and open Save As on a hi-dpi secondary display, it'll look very small; and in the reverse scenario, it appears awfully big.

This seems to be "expected" Windows behavior: I see the same thing with the Save As dialog in IE10 on my Win8.1 system. It matches the unscaled rendering of window borders, titlebars, controls, the system popup menu you get by right-clicking the title bar, etc. I think this is a misguided design choice in Windows, but it's how the system consistently behaves.

Not sure if there's anything we can currently do to work around this, short of implementing our own in-app Save As dialog instead of using the system-provided one.

Comment 4

[Jonathan Kew [:jfkthame]]

The same issues apply to the Open File dialog.

Comment 5

[Jonathan Kew [:jfkthame]]

FWIW, we're not the only people who don't currently know how to fix this:
http://stackoverflow.com/questions/35454712/make-windows-common-dialogs-per-monitor-dpi-aware

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> FWIW, we're not the only people who don't currently know how to fix this:
> http://stackoverflow.com/questions/35454712/make-windows-common-dialogs-per-
> monitor-dpi-aware

Hmm, if that is any indication, we should be using an updated API when running on Vista or newer.

Comment 7

[Jonathan Kew [:jfkthame]]

AFAICS, we -are- already using the "updated" APIs mentioned there -- see nsFilePicker::ShowFilePicker() in widget/windows/nsFilePicker.cpp, which uses IFileOpenDialog/IFileSaveDialog.

Comment 8

[Jonathan Kew [:jfkthame]]

I've heard from contacts at MS confirming that there will be new APIs in a future version of Windows to help address this (but for now, it is what it is...)

As of now, this could arguably be closed as WONTFIX (or maybe INVALID), as it's not a Firefox bug, it's expected Windows behavior. But I'll leave it open because we'll want to adopt the new APIs as soon as they're available.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

I'm not sure if this actually works, but would wrapping those APIs in ActivateActCtx/DeactivateActCtx with an activation context that does /not/ indicate multi-monitor DPI support help? My thought pattern is that maybe it would force Windows to scale just the dialog?

(I know that would work for other aspects such as sxs redirection, but I'm not sure if DPI scaling would work the same way)

Comment 10

[Jonathan Kew [:jfkthame]]

I don't believe so. Per-monitor dpi awareness is a process-wide state declared in the application manifest, and not connected to activation contexts.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as dpi-unaware windows, so that they are auto-scaled by the system appropriately for the display's resolution

The latest Windows Insider build includes new APIs that allow us to fix this issue; here's a patch that should do it.

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: followup - Apply the same fix to the Print dialog

Comment 16

[Jonathan Kew [:jfkthame]]

Comment on attachment 8757311 [details] [diff] [review]
When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as dpi-unaware windows, so that they are auto-scaled by the system appropriately for the display's resolution

The Win10 Anniversary Update due to ship at the beginning of August will include these APIs, allowing a much improved user experience with the file dialogs. So we should get this into the tree and onto the trains soon...

(This patch sets up the EnableNonClientDpiScaling proc ptr as well, although it's not actually used here; we'll be needing that too, for bug 1270954, so I included it here for simplicity but we can split it off if you prefer.)

Comment 17

[Masatoshi Kimura [:emk]]

Comment on attachment 8757311 [details] [diff] [review]
When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as dpi-unaware windows, so that they are auto-scaled by the system appropriately for the display's resolution

Review of attachment 8757311 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/windows/WinUtils.cpp
@@ +476,5 @@
>      }
>    }
> +
> +  if (IsWin10OrLater()) {
> +    HMODULE user32Dll = ::LoadLibraryEx(L"user32", NULL,

GetModuleHandle() is sufficient. We implicitly link to user32, so it will never be unloaded.

::: widget/windows/nsFilePicker.cpp
@@ +1050,5 @@
>    mFiles.Clear();
>  
> +  // On Win10, the picker doesn't support per-monitor DPI, so we open it
> +  // with our context set temporarily to non-dpi-aware
> +  WinUtils::AutoDpiUnaware dpiUnaware;

Why is this DPI-unaware instead of system-DPI-aware? System-DPI-aware will prevent blurry dialogs on single high-DPI monitor systems.

Comment 18

[Jonathan Kew [:jfkthame]]

Attachment: When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as system-dpi-aware windows, so that they are auto-scaled by the system appropriately for any secondary display's resolution

Yes, of course system dpi awareness is a better option - thanks.

Comment 19

[Jonathan Kew [:jfkthame]]

Attachment: followup - Apply the same fix to the Print dialog

Comment 20

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1b782dcb677abdbbeade064e3321a87505b7d0c9
Bug 1254026 - When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as system-dpi-aware windows, so that they are auto-scaled by the system appropriately for any secondary display's resolution. r=emk

https://hg.mozilla.org/integration/mozilla-inbound/rev/5c98fa080b96a19d4ed2dc6947c78ba7240fe19b
Bug 1254026 - followup - Apply the same fix to the Print dialog. r=emk

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1b782dcb677a
https://hg.mozilla.org/mozilla-central/rev/5c98fa080b96

Comment 22

[Jonathan Kew [:jfkthame]]

Comment on attachment 8767356 [details] [diff] [review]
When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as system-dpi-aware windows, so that they are auto-scaled by the system appropriately for any secondary display's resolution

With the Windows 10 Anniversary Update due to ship very soon (early August, IIUC), it would be good to get this into FF48/49 rather than waiting for FF50 to improve the user experience.

Approval Request Comment
[Feature/regressing bug #]: Win10 hi-dpi support

[User impact if declined]: file open/save dialogs mis-sized on secondary monitor

[Describe test coverage new/current, TreeHerder]: tested manually (requires mixed-dpi config)

[Risks and why]: minimal, no effect except on mixed-dpi Windows systems

[String/UUID change made/needed]: n/a

Comment 23

[Gerry Chang [:gchang]]

Hi Jonathan,
Since it's late beta, is this patch critical for user? I would like this patch ride the train on 49/50 and bake more time.

Comment 24

[Jonathan Kew [:jfkthame]]

(Yes, I figured it might be too late to take this on beta.)

I don't think we can regard this as "critical". The undesired behavior (Open/Save/Print dialogs don't scale appropriately on secondary displays with a different DPI setting) already exists for Windows 8.1 and 10 users; it's ugly but not crippling. (Note that the behavior is a result of limitations in the Windows APIs for supporting mixed resolutions, it's not really a Firefox bug.)

The Win10 Anniversary Update will introduce new APIs (currently in Insider builds) that can solve the issue, and will ship to end users next month, but our users won't get the benefit until we ship an update of Firefox that actually uses the new APIs. So that's what we're doing here.

But I'd agree that it's not "critical" to have this as soon as Win10AU goes out; we can deliver the fix somewhat later. In the meantime, things just continue as-is (ugly, but functional) for those users.

Comment 25

[Jonathan Kew [:jfkthame]]

Comment on attachment 8767357 [details] [diff] [review]
followup - Apply the same fix to the Print dialog

See approval request for the main patch (above).

Comment 26

[Gerry Chang [:gchang]]

Comment on attachment 8767356 [details] [diff] [review]
When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as system-dpi-aware windows, so that they are auto-scaled by the system appropriately for any secondary display's resolution

Review of attachment 8767356 [details] [diff] [review]:
-----------------------------------------------------------------

Since this is not critical for user, let it ride the train on 49/50.

Comment 27

[Gerry Chang [:gchang]]

Mark won't fix for 47/48.

Comment 28

[Gerry Chang [:gchang]]

Comment on attachment 8767356 [details] [diff] [review]
When Win10 dpi-awareness-context APIs are available, run the Open File and Save As dialogs as system-dpi-aware windows, so that they are auto-scaled by the system appropriately for any secondary display's resolution

The patch fixes a UI issue in secondary display's resolution. Take it in 49 aurora.

Comment 29

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/59e0323f3db6
https://hg.mozilla.org/releases/mozilla-aurora/rev/70ca7c42db31