Closed Bug 1756241 Opened 2 years ago Closed 2 years ago

Tearing off tabs to a different monitor opens a new window on the original screen

Categories

(Firefox :: Tabbed Browser, defect)

defect

Tracking

()

RESOLVED FIXED
99 Branch
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.

Flags: needinfo?(emilio)

Probably a regression from bug 1755315 instead, but will look

Assignee: nobody → emilio

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.

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

(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).

Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
See Also: → 1288760, 1306309

This gives proper window-relative, CSS-scaled window coordinates on X11.

Before D139243 the coordinates were only correct in non-HiDPI
environments.

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

Ok with the patches above all drag coordinates behave correctly in various HiDPI / multi-monitor setups in all desktop platforms, afaict

Flags: needinfo?(emilio)
Has Regression Range: --- → yes
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3aa2f9ecd615
Make Windows DragService have the same coordinate system as all other drag and mouse events. r=tnikkel
https://hg.mozilla.org/integration/autoland/rev/3d3c269d374b
Improve tab dragging calculations to work correctly between mixed-dpi screens. r=dao
https://hg.mozilla.org/integration/autoland/rev/ba487d8a591c
Fix drag coordinates on X11 after D139243. r=stransky
https://hg.mozilla.org/integration/autoland/rev/3e29ce629843
Fix drag coordinates on macOS after D139243. r=mac-reviewers,bradwerth
Blocks: 1306309
See Also: 1306309
Flags: qe-verify+
Regressions: 1767165
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: