[e10s] tearaway tab page thumbnail image does not follow the mouse across display boundaries




Widget: Cocoa
2 years ago
2 years ago


(Reporter: jfkthame, Unassigned)


Mac OS X
Dependency tree / graph

Firefox Tracking Flags



(Whiteboard: tpi:+)



2 years ago
(Spun off from bug 1239353 comment 5.)

When I drag a tab header to tear a tab off into its own window (or to drop it into another window), the drag image (page thumbnail) that is displayed with e10s does not follow the mouse across screen boundaries; it just disappears at the edge of the original monitor.

This does not seem to be a dpi-scaling issue; it happens even when both displays have the same dpi, or when the browser is opened in low-res only mode (using the app properties setting available in the Finder).

My guess is that this is related to the OS X behavior (new in 10.9, iirc?) whereby windows are only displayed on their "owning" monitor; any parts of the window that spread onto a secondary monitor are simply clipped away. Note that if you drag an application window so that it straddles two displays, it shows up in a semi-transparent "ghost" form on the second display while dragging, but as soon as it is released, only the part of the window that is on its "home" monitor (the one where the mouse was when it was released -- not necessarily the display with the largest area of the window) will display it; the "ghost" on the secondary display just disappears. This is true even if both displays use the same resolution (backing scale factor).

So what I think may be happening here is that the e10s thumbnail image isn't being handled as a normal OS X "drag image"; it's a new window that we're moving around. But its "owning" display always remains the one where it started out -- where the mouse-down initiating the drag happened -- and therefore it will only display on that monitor. Note that even when first approaching the edge of the first monitor, so that just a small amount of the thumbnail should overlap onto the new one, that part of it is not displayed.

I'm not sure whether this can be solved somehow in the Cocoa widget code, or if it will require a higher-level re-think of how the e10s tab-drag image is handled.


2 years ago
tracking-e10s: --- → +
Priority: -- → P1
I can reproduce with latest Nightly 49.0a1, 20160531030258 by dragging a tab from one screen to another.  (external/macbook)
Whiteboard: tpi:+


2 years ago
Priority: P1 → P2
I was unable to reproduce with a local build off of current m-c. I believe we may have fixed this with the landing of bug 1235162 where we changed the native DnD API. Jonathan, would you be able to confirm? Thanks!
Flags: needinfo?(jfkthame)

Comment 3

2 years ago
If anything, bug 1235162 seems to have made things worse here; in Nightlies immediately after that landing, I get no drag image at all when dragging a tab.

But starting from 2016-12-25, it starts to work again, and the issue here no longer appears. So it looks like this got fixed just in time for Christmas. :)

I tried running `mozregression --find-fix`, which points to bug 1309596 as the point where this actually started working.
Last Resolved: 2 years ago
Depends on: 1309596
Flags: needinfo?(jfkthame)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.