1262398 - Cursor has a different position for each monitor while Firefox is dragged to multiple monitors

Status: NEW

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

Description

[Bogdan Maris, Desktop QA]

[Note]:
- this is a followup bug 1259065

[Affected versions]:
- latest Aurora 47.0a2
- latest Nightly 48.0a1

[Affected platforms]:
- Windows 8.1
- Windows 10

[Steps to reproduce]:
1. Start Firefox
2. Grab the top of Firefox
3. Drag Firefox from one screen to another (I used hi-dpi and low-dpi)

[Expected result]:
- Cursor does not change position

[Actual result]:
- On each screen the cursor is located to a different position

[Regression range]:
- This happens after bug 1259065 was fixed

[Additional notes]:
- This is not reproducible using Firefox 45.0.1 nor Firefox 46 beta 8

Comment 1

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

Hi Jonathan, this is something that is related to per-monitor DPI. Could you please investigate? This came up in the platform triage meeting.

Comment 2

[Jonathan Kew [:jfkthame]]

I don't think we can/should attempt to do anything here at the moment. It's a bit of a long story....

This is a very minor polish issue: when dragging a window between screens with different DPI, the window is re-scaled to render at the new resolution, and when that happens, the apparent position of the cursor on the window frame typically shifts by a few pixels. However, it is normally _just_ a few pixels, which is scarcely noticeable in the midst of a window drag unless you're carefully watching for it.

I believe this is connected to one of the current Windows per-monitor-DPI API limitations: the non-client area of the window (title bar, borders) does not scale according to the current display's resolution, but is always rendered according to the system default DPI. This is why the title bar and controls change their apparent size when moving the window between displays.

When the DPI change happens, and we re-scale the window content for the new resolution, the WM_DPICHANGED message that Windows sends us includes the recommended new window coordinates to use, and we simply use these. If this results in the window being slightly shifted in relation to the mouse cursor, that's a Windows issue, not our fault. We could attempt to correct for it, perhaps, by adjusting the window coordinates that we're given (or, equivalently, by "warping" the mouse pointer to offset its location), but this will expose us to worse problems: the adjustment we make will sometimes cause Windows to change its idea of the window's primary display, and so it'll revert the resolution and send us another WM_DPICHANGED message... and the cycle starts again. This can lead to ugly instability around the DPI transition, as the window flip-flops back and forth between two scales.

Things are much cleaner and more stable if we accept the scaled window size that Windows gives us, and don't try to second-guess or adjust it.

I suspect that the shift in cursor position noted here is largely a side-effect of the mismatch between scaling of the client and non-client areas of the window, as noted above. This means that there's a shift in the relative sizes/proportions of the window frame (handled by Windows, unscaled) and the content drawing, including things like menus and tabs that we push into the title area (handled by us, scaled according to DPI). And the change in relative scaling of the different parts of the window causes the mouse cursor position to appear to shift in relation to the menus/tabs/etc.

Once Microsoft provides the API to let us request scaling of the non-client parts of the window, to match the scaling of the content, we should re-examine this and see if there is any remaining issue. But for now, any attempt to mitigate this on our side risks introducing worse glitches.

Comment 3

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

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> I don't think we can/should attempt to do anything here at the moment. It's
> a bit of a long story....
> 
> This is a very minor polish issue: when dragging a window between screens
> with different DPI, the window is re-scaled to render at the new resolution,
> and when that happens, the apparent position of the cursor on the window
> frame typically shifts by a few pixels. However, it is normally _just_ a few
> pixels, which is scarcely noticeable in the midst of a window drag unless
> you're carefully watching for it.
> 
Thanks Jonathan for a quick follow up. I agree that it is a polish issue and until the Windows API is updated we may have to live with it. Since it's a minor issue, I do not feel the need to track it for any release.