Cursor changes position when Firefox is dragged from one screen to another

VERIFIED FIXED in Firefox 47

Status

()

defect
--
minor
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: bogdan_maris, Assigned: jfkthame)

Tracking

Trunk
mozilla48
All
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 unaffected, firefox46 unaffected, firefox47 verified, firefox48 verified)

Details

Attachments

(1 attachment)

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

[Affected platforms]:
- Windows 8.1 64bit
- Windows 10 64bit

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

[Expected result]:
- Cursor does not change the position

[Actual result]:
- Cursor changes position.

[Regression range]:
- I tracked this down to Nightly from 2016-01-13 (where per-monitorDPI was enabled) so this is not a regression.

[Additional notes]:
- This is not reproducible using Firefox 45.0.1 nor 46 beta 4.
This is a particular problem when dragging from a high-dpi to low-dpi screen; I'm not seeing it happen when going in the other direction. I think I know the major cause; just testing a patch, before posting it here.
Assignee: nobody → jfkthame
This makes the window-dragging experience much better; we don't want to suddenly force it fully onto the destination screen in the middle of an on-going move.
Attachment #8733987 - Flags: review?(VYV03354)
Attachment #8733987 - Flags: review?(VYV03354) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/7b686e0a9ce4c5f1970b30ffbc4885a9ff29b9bf
Bug 1259065 - Don't constrain window position (only its size) when DPI-rescaling during a move. r=emk
Comment on attachment 8733987 [details] [diff] [review]
Don't constrain window position (only its size) when DPI-rescaling during a move

Approval Request Comment
[Feature/regressing bug #]: 890156 (per-monitor dpi)

[User impact if declined]: unexpected "jump" in position when dragging a window between hi- and lo-dpi screens

[Describe test coverage new/current, TreeHerder]: tested manually

[Risks and why]: minimal - small tweak to dpi-change handling in Windows widget code, cannot affect any other systems

[String/UUID change made/needed]: none
Attachment #8733987 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/7b686e0a9ce4
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Bogdan, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(bogdan.maris)
Comment on attachment 8733987 [details] [diff] [review]
Don't constrain window position (only its size) when DPI-rescaling during a move

per-monitor DPI support is planned for 47, Aurora47+
Attachment #8733987 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I just checked on Windows 8.1 and 10 using latest Nightly/Aurora and although the initial issue seems fixed I observed that when dragging Firefox window to the low-dpi monitor, the cursor now changes position on vertical. If Firefox is on low-dpi, cursor moves down a few pixels and when moving the window back to hi-dpi monitor it changes back where it was initially (I had main display hi-dpi monitor). 
Should I log a new bug for that or reopen this one?
Flags: needinfo?(bogdan.maris) → needinfo?(jfkthame)
Yes, I'd seen the same thing, though it's barely noticeable unless you're specifically looking for it. Please file a new bug; this is a minor discrepancy that is unrelated to the basic fix here.

It may be that the apparent shift is really just a side-effect of how the window border area changes size (due to Windows' lack of proper dpi scaling for the non-client area) when moving between hi- and lo-dpi screens, and will be resolved once there's an API that lets us control this scaling properly (coming in the next version of Windows, I'm told). But perhaps we can work around this or adjust for it in the meantime.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #10)
> Yes, I'd seen the same thing, though it's barely noticeable unless you're
> specifically looking for it. Please file a new bug; this is a minor
> discrepancy that is unrelated to the basic fix here.
> 
> It may be that the apparent shift is really just a side-effect of how the
> window border area changes size (due to Windows' lack of proper dpi scaling
> for the non-client area) when moving between hi- and lo-dpi screens, and
> will be resolved once there's an API that lets us control this scaling
> properly (coming in the next version of Windows, I'm told). But perhaps we
> can work around this or adjust for it in the meantime.

Logged bug 1262398 on that, also marking this as verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.