Closed Bug 1265977 Opened 8 years ago Closed 8 years ago

Firefox window jumps multiple times from hidpi to lowdpi during moving transition

Categories

(Core :: Widget: Win32, defect)

All
Windows
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox45 --- unaffected
firefox46 --- unaffected
firefox47 --- verified
firefox48 --- verified

People

(Reporter: bmaris, Assigned: jfkthame)

References

()

Details

Attachments

(1 file)

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

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

[Steps to reproduce]:
- prerequisits: hidpi and lowdpi monitor

1. Open Firefox
2. Drag Firefox on lowdpi monitor
3. Move Firefox to hidpi monitor just a little (Just before it resizes on hidpi).
4. Move cursor to hidpi and from there 'slowly' complete the action of moving Firefox to hidpi. 

[Expected result]:
- Firefox window transition from one screen to another is smooth.

[Actual result]:
- Firefox window jumps multiple times from one screen to the other while moving it.

[Regression range]:
- This is not a regression, it reproduces with old Nightly (2016-01-13).

[Additional notes]:
- Check the URL for a video of the behavior.
- My Configuration:
-- Monitors: Samsung 2233 WSXGA+ and Dell P2415Q UHD-1 (with Dell being the main display - the issue reproduces only when transitioning from lowdpi to hidpi regardless of which is the main display).
--- Here are more detailed information from dxdiag: http://pastebin.com/dSqAEayK
-- devicePixelRatio scale: lowdpi 1680x1049 (size of text from control panel 100%), hidpi 1920x1079 (size of text from control panel 200%). Same issue with low 100% and hi 150% and 100% and hi 250%. For each test I signed out after altering the values of text size.

A curious thing happened when I changed text size of low on 150%. When trying to repeat the issue, Firefox window jumped back only once and then it stopped moving, after I retried, Firefox window did not jump at all. Hidpi screen value was changed from 175%, 200% and 250% with the same outcome as mentioned above. 

Please let me know I can provide more information about this issue.
OK, this is kinda interesting. It turns out that Windows handles the DPI change differently depending on where in the titlebar you're dragging.

Using the STR described above, it's important whether, at step 4, you move the cursor _just_ over to the hidpi screen, so that it's still near the middle of the window, or move it _far_ over so that you're taking hold of the window near its edge. In my testing, at least, this makes a big difference to the stage of the move at which Windows decides to fire the WM_DPICHANGED message, and therefore to how the Firefox window behaves in response.

Anyhow, what leads to the particularly bad behavior is the code in nsWindow::OnDPIChanged that attempts to adjust the "proposed" window coordinates from the WM_DPICHANGED message to maintain the size of the window's client area. What Windows gives us are coordinates based on maintaining the overall (including non-client) window size, but because of the lack of per-monitor scaling of the non-client area, this means that the actual client area will change size within the window.

So for example, if I have a window whose innerWidth/innerHeight size is 800px by 500px on a 100% (secondary) screen, and I drag it to a 200% (primary) screen, the window borders and titlebar become thinner, and so the client area (as exposed to web content) would grow to about 811px by 518px.

I figured that is somewhat undesirable -- you don't generally expect a window to change its size just because it was moved around on the desktop -- and that's why we have the code in OnDPIChanged that uses the difference between GetClientBounds and GetScreenBounds to adjust the proposed size. Unfortunately, this can lead to issues because by putting the window somewhere other than where Windows proposed, we may confuse its idea of whether the DPI change ought in fact to have happened...

For now, I think it's best to simply drop this code and accept the window coordinates that we're given in the WM_DPICHANGED message (except that we'll keep the constraint to screen dimensions, because that's important to avoid cases where e.g. unplugging a large external screen can result in a window that overflows the built-in screen in all directions and is really hard to fix manually). This means we'll have the issue where the effective client size of the window changes between screens, but that's relatively minor, and when Microsoft adds the promised APIs to let us opt in to per-monitor scaling of the non-client areas, it will no longer be an issue.

I've started a try build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=7e19cbbc5091; Bogdan, please test with this when it's ready, and let me know if it improves the behavior for you.

Note that there is still an "untidy" issue where the content and chrome may re-scale at slightly different stages during a window move; this also seems to be dependent on whether you're dragging the window by the middle of its titlebar, or far to one of the sides. But I think this is separate from the window-sizing instability here.
Flags: needinfo?(bogdan.maris)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8743214 - Flags: review?(VYV03354) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/75848971e880c85802bfe3f19c39fedf6d9c773a
Bug 1265977 - Use the suggested window coordinates from WM_DPICHANGED, without trying to improve them to maintain window client size. r=emk
(In reply to Jonathan Kew (:jfkthame) from comment #1)
> I've started a try build at
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=7e19cbbc5091;
> Bogdan, please test with this when it's ready, and let me know if it
> improves the behavior for you.

I definitely can't see the issue reported here anymore with this trybuild. Window does not jump anymore at all. 
 
> Note that there is still an "untidy" issue where the content and chrome may
> re-scale at slightly different stages during a window move; this also seems
> to be dependent on whether you're dragging the window by the middle of its
> titlebar, or far to one of the sides. But I think this is separate from the
> window-sizing instability here.

Yes, I can see the content re-scale here with this build, and yes it seems that it's more pronounced if I drag the window from the side rather then close to the middle. Did you had a chance to logg a bug on that or should I?
Flags: needinfo?(bogdan.maris) → needinfo?(jfkthame)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #4)
> I definitely can't see the issue reported here anymore with this trybuild.
> Window does not jump anymore at all. 

Great, thanks.

> Yes, I can see the content re-scale here with this build, and yes it seems
> that it's more pronounced if I drag the window from the side rather then
> close to the middle. Did you had a chance to logg a bug on that or should I?

No, I didn't file it yet, so please go ahead -- thanks again.

(We probably won't get that fixed right away, but it's a relatively minor cosmetic issue IMO; still good to have it on record, though.)
Flags: needinfo?(jfkthame)
Comment on attachment 8743214 [details] [diff] [review]
Use the suggested window coordinates from WM_DPICHANGED, without trying to "improve" them to maintain window client size

Approval Request Comment
[Feature/regressing bug #]: 890156

[User impact if declined]: possible erratic window movement when dragging between displays with different DPI

[Describe test coverage new/current, TreeHerder]: tested manually (& confirmed by Bogdan using try build)

[Risks and why]: minimal - this just removes an extra window-sizing tweak that turns out to be more problematic than helpful

[String/UUID change made/needed]: none
Attachment #8743214 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/75848971e880
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
(In reply to Jonathan Kew (:jfkthame) from comment #5)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #4)
> > I definitely can't see the issue reported here anymore with this trybuild.
> > Window does not jump anymore at all. 
> 
> Great, thanks.
> 
> > Yes, I can see the content re-scale here with this build, and yes it seems
> > that it's more pronounced if I drag the window from the side rather then
> > close to the middle. Did you had a chance to logg a bug on that or should I?
> 
> No, I didn't file it yet, so please go ahead -- thanks again.
> 
> (We probably won't get that fixed right away, but it's a relatively minor
> cosmetic issue IMO; still good to have it on record, though.)

I agree it's quite a minor issue only because if the transition is completed, the cosmetic problems will go away.

Logged bug 1266377

I also verified this bug as fixed on official Nightly build from today (2016-04-21).
Comment on attachment 8743214 [details] [diff] [review]
Use the suggested window coordinates from WM_DPICHANGED, without trying to "improve" them to maintain window client size

This was deemed blocking by SV, let's uplift to Aurora47.
Attachment #8743214 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified using latest Developer Edition 48.a2 and Firefox 47 beta 1 on Windows 10 and Windows 8.1.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.