Tearing off tabs to a different monitor opens a new window on the original screen
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | unaffected |
firefox98 | --- | unaffected |
firefox99 | + | fixed |
People
(Reporter: RyanVM, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
[Tracking Requested - why for this release]: User-facing visible regression
2:05.31 INFO: No more integration revisions, bisection finished.
2:05.31 INFO: Last good revision: 3eec0fc28bd504d3c44f803222bff5acb4118eda
2:05.31 INFO: First bad revision: 01d8e901bb369cad52f885808fd0d8ebb5176ca7
2:05.31 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3eec0fc28bd504d3c44f803222bff5acb4118eda&tochange=01d8e901bb369cad52f885808fd0d8ebb5176ca7
If I drag a tab off the tab strip from my primary monitor to my secondary monitor, it no longer opens a window on the secondary monitor as expected. It instead opens on the primary monitor still. I have dual 4K screens and run at 200% scaling in case that ends up being important.
Assignee | ||
Comment 1•3 years ago
|
||
Probably a regression from bug 1755315 instead, but will look
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
Passing the widget makes sure that in mixed dpi situations the pixels match
that of all other events.
The windows code was working around this by storing CSS pixels directly, but
with that tweak it's no longer needed.
Chances are I need to undo similarish workarounds on other platforms like
https://searchfox.org/mozilla-central/rev/caad7a563d267a8a06ed8c7222b21df91625f5ac/widget/gtk/nsDragService.cpp#2110,
will test there.
Assignee | ||
Comment 4•3 years ago
|
||
The root cause of the bug is fixed by the previous patch. This patch improves
the calculations to work properly across mixed dpi displays (which doesn't work
on release either by any stretch).
Hopefully it's somewhat straight-forward to follow.
Depends on D139243
Assignee | ||
Comment 5•3 years ago
|
||
(I still need to check behavior with this patch on macOS and Linux, as per the commit message there's probably some other workarounds that can go now).
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
This gives proper window-relative, CSS-scaled window coordinates on X11.
Before D139243 the coordinates were only correct in non-HiDPI
environments.
Assignee | ||
Comment 8•3 years ago
|
||
D139243 makes drag events more similar to all other events (passing down the
widget the coordinates are relative to and so on), so we need to use the same
coordinate space as everything else now (widget-relative).
Depends on D139245
Assignee | ||
Comment 9•3 years ago
|
||
Ok with the patches above all drag coordinates behave correctly in various HiDPI / multi-monitor setups in all desktop platforms, afaict
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3aa2f9ecd615
https://hg.mozilla.org/mozilla-central/rev/3d3c269d374b
https://hg.mozilla.org/mozilla-central/rev/ba487d8a591c
https://hg.mozilla.org/mozilla-central/rev/3e29ce629843
Updated•3 years ago
|
Updated•3 years ago
|
Description
•