1197497 - HiDPI breaks the standard Windows7 mechanism "Automatically move the pointer to the default button in a dialog box" (SnapToDefaultButton)

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P3)

Description

[arni2033]

Attachment: 2015.08.22 16-42-59.webm

STR:   (Nightly (2015-08-20))
1. Set font size in Windows = 125% (or you can try setting layout.css.devPixelsPerPx -> 1.25)
2. Make sure you have default Windows setting "place mouse over default button when confirm window opens" (I don't know how it's called in English)
3. Open Scratchpad (Shift+F4)
4. Type "asdf" in Scratchpad
5. Click close button

Result:       Mouse cursor is placed wrong
Expectations: Mouse cursor should place over the "Save" button

Note:         That happens with every browser's prompt/alert/confirm. Even when using profile manager (the last one obviously refers to 125% in Windows, not layout.css.devPixelsPerPx pref)

Comment 1

[:Gijs (he/him)]

(In reply to arni2033 from comment #0)
> Created attachment 8651384 [details]
> 2015.08.22 16-42-59.webm
> 
> STR:   (Nightly (2015-08-20))
> 1. Set font size in Windows = 125% (or you can try setting
> layout.css.devPixelsPerPx -> 1.25)
> 2. Make sure you have default Windows setting "place mouse over default
> button when confirm window opens" (I don't know how it's called in English)

"Automatically move the pointer to the default button in a dialog box"

It's stored in the "SnapToDefaultButton" registry setting.



We don't really do anything based on the registry setting, as far as I can tell from searching our codebase, so if this problem doesn't occur with other applications when using non-default Windows zoom settings, then I'm not sure what we'd be doing differently, if anything, that would be causing this. Jim, do you have ideas?

Comment 2

[arni2033]

Yes, other applications don't show this behavior
> (or you can try setting layout.css.devPixelsPerPx -> 1.25)
That's bad suggestion actually(!). What may be important is that I see the same issue with profile manager - that means that layout.css.devPixelsPerPx isn't doesn't break anything... Well, it does break things "back to normal" when I set it to 1.0 . It sort of compensates the actual bug.

So now I think that there're 2 bugs actually:
1) Firefox works bad on HiDPI
2) Pref layout.css.devPixelsPerPx affects coordinates which are transmitted to OS
  (I guess that's how the pointer gets the actual coordinates)
> screenshot:   https://dl.dropboxusercontent.com/s/7pb6frzithqm3xa/screenshot%20-%20HiDPI%20breaks%20the%20standard%20Windows7%20mechanism%20%27Automatically%20move%20the%20pointer%20to%20the%20default%20button%20in%20a%20dialog%20box%27%20%28SnapToDefaultButton%29.png?dl=0

This bug has nothing to do with the save dialog. I just filed bug 1214688 about it [the dialog].

Comment 3

[:Gijs (he/him)]

(In reply to arni2033 from comment #2)
> Yes, other applications don't show this behavior
> > (or you can try setting layout.css.devPixelsPerPx -> 1.25)
> That's bad suggestion actually(!). What may be important is that I see the
> same issue with profile manager - that means that layout.css.devPixelsPerPx
> isn't doesn't break anything... Well, it does break things "back to normal"
> when I set it to 1.0 . It sort of compensates the actual bug.
> 
> So now I think that there're 2 bugs actually:
> 1) Firefox works bad on HiDPI
> 2) Pref layout.css.devPixelsPerPx affects coordinates which are transmitted

You really shouldn't need to set that pref anyway, on Windows. It is an internal pref and I would advise you not to touch it.

Comment 4

[arni2033]

> It is an internal pref and I would advise you not to touch it.
Oh, you're really provoking me. Do you advise me to eat the blurry buggy **** firefox UI has become from 28+? I've always used Windows on 125%, and firefox was OK before "yet another improvement".
> screenshot:   https://dl.dropboxusercontent.com/s/huk01oz08dt7nta/del%20screenshot%20-%20HiDPI%20regression.png?dl=0

Comment 5

[Jim Mathies [:jimm]]

Attachment: mousesettings.jpg

This Windows pref is exposed via Mouse Settings. We implemented support in bug 76053, but apparently the code needs to be updated to support highdpi displays. This bug should probably get added to a backlog of some sort so we get to it.

Comment 7

[Neil Deakin]

From the duplicate:

nsGlobalWindow::NotifyDefaultButtonLoaded needs to convert the coordinates of buttonRect from css pixels to device pixels.

nsWindow::OnDefaultButtonLoaded should take a LayoutDeviceIntRect as well to make this clearer.

Comment 8

[Sunny Sidhu]

Hi, can you give me some direction in solving this bug please?

Comment 9

[Neil Deakin]

The nsWindow::OnDefaultButtonLoaded (declared in the nsIWidget interface) should take a LayoutDeviceIntRect instead of an nsIntRect.

The one caller of this is nsGlobalWindow::NotifyDefaultButtonLoaded, which supplies coordinates from the rectagle 'buttonRect' in the wrong rectangle unit type. The coordinates (x, y, width, height) will need to be converted into the right type using 
nsPresContext::DevPixelsToIntCSSPixels or some similar method.

A similar change for a point was made in http://hg.mozilla.org/mozilla-central/rev/fd0e8165c50f

Thanks for helping out!

Comment 10

[arni2033]

Reproducible on:   Win7_64, Nightly 51, 32bit, ID 20160801074053 (2016-08-01)

Assuming that users don't usually switch about:config prefs, this became user-visible after bug 844604
This is "regression" from bug 844604. Regression range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b672877ed046&tochange=0f7261e288f2

Comment 11

[Masatoshi Kimura [:emk]]

Is this option still supported at all?

I checked the "Automatically move pointer to the default button in a dialog box" option, but pointer did not move at all even with DPI scaling 100%, even with Notepad.

Comment 12

[:Gijs (he/him)]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> Is this option still supported at all?
> 
> I checked the "Automatically move pointer to the default button in a dialog
> box" option, but pointer did not move at all even with DPI scaling 100%,
> even with Notepad.

I can see it doing something with the default file > open... dialog on notepad on non-100% dpi scaling on Windows 10. It automatically moves to the [Open] button.

Comment 13

[Masatoshi Kimura [:emk]]

Windows 10 + Notepad + file picker didn't work for me (pointer did not move at all). That's strange...

Comment 14

[Masatoshi Kimura [:emk]]

Ah, I got it. VMware Tools prevented this option from working.

Comment 15

[Masatoshi Kimura [:emk]]

Attachment: Bug 1197497 - Convert the button rect to device coordinates correctly instead of casting CSS coordinates.

Review commit: https://reviewboard.mozilla.org/r/132578/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/132578/

Comment 16

[Jonathan Kew [:jfkthame]]

Comment on attachment 8860570 [details]
Bug 1197497 - Convert the button rect to device coordinates correctly instead of casting CSS coordinates.

https://reviewboard.mozilla.org/r/132578/#review135516

Thanks for fixing this (and various other recent dpi-related fixes)...  great to get these tidied up!

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/777eaa1593f7
Convert the button rect to device coordinates correctly instead of casting CSS coordinates. r=jfkthame

Comment 18

[Iris Hsiao [:ihsiao]]

https://hg.mozilla.org/mozilla-central/rev/777eaa1593f7