675860 - New tab dragging behavior does not play nice with spaces (warps to random places on the desktop)

Status: RESOLVED INVALID

(Firefox :: Tabbed Browser, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Current trunk nightly

STEPS TO REPRODUCE:
1)  Get a Mac
2)  Set up multiple spaces.  You need at least 2; call them "Space 1" and
    "Space 2".
3)  Start Firefox.
4)  Make sure you have two Firefox windows open which are NOT maximized.  One
    should be on Space 2 and contain a single tab.  The other should be on
    Space 1 and contain two tabs.
5)  Switch to Space 1.
6)  Mouse down on one of the tabs in the single Firefox window you see.  Do not
    mouse up.
7)  Slowly drag your mouse out of the window without hitting the edge of the
    screen.

EXPECTED RESULTS: When the mouse leaves the Firefox window you can drop the tab at the mouse location and get a new window on Space 1.

ACTUAL RESULTS: When the mouse leaves the Firefox window you are suddenly switched to Space 2.

ADDITIONAL INFORMATION: I am guessing that we're trying to find some other Firefox window than the one we just left and raise it?  Or something like that?  In this case that's really not doing the right thing....

This is seriously interfering with my ability to do tab drag and drop; in particular dragging a tab out of a window, or to a different window is completely broken for me because halfway through the drag I suddenly get warped to some other space, where my drag target is not.  Requesting tracking for Fx8 for this reason.

Comment 1

[Justin Dolske [:Dolske]]

Hmm, I remember asking about this. I thought it wasn't supposed to happen because the window coordinates for different spaces never overlapped?

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to comment #0)
> ADDITIONAL INFORMATION: I am guessing that we're trying to find some other
> Firefox window than the one we just left and raise it?  Or something like
> that?  In this case that's really not doing the right thing....
Yeah, it's probably tracking window positions and sizes, not considering each space to have different locations. If I move the window in Space 2 waaay over to the side of the screen so that there's exposed desktop space between the window in Space 1 and the window in Space 2, it detaches correctly. The moment I move it the tab over the space that the window in Space 2 occupies, it switches Spaces on me.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> because the window coordinates for different spaces never overlapped?

As far as I can tell, they overlap.  Certainly when I switch a window to a different space its screenX and screenY do not change.  Nor do they change if it ends up on a non-active space....

At least this explains which space I get switched to.  Sadly, I believe every screen pixel has _some_ Firefox window under it on one of my spaces.  :(

Comment 4

[Frank Yan (:fryn)]

CC'ing Mehdi, since I remember him fiddling with Spaces stuff once.

Comment 5

[Mehdi Mulani [:mmm] (I don't check this)]

Over in bug 372650 people discussed adding support to track the current virtual desktop. On Mac, I was able to have Firefox recognize the current workspace number which seems like it might help in this scenario.

If a regression can't be tracked down, I wouldn't mind helping to add support for workspace info.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> On Mac, I was able to have Firefox recognize the current workspace number

Is that code available anywhere?

Comment 7

[Mehdi Mulani [:mmm] (I don't check this)]

(In reply to comment #6)
> Is that code available anywhere?

Not easily, I have to go through backups/repos looking for it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

:(  Bug 372650 is what keeps me from updating my browser.  :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

This has been making it more or less impossible for me to actually drag tabs to tear them off from windows; I've been alternating between trying to use old builds and trying to just not drag tabs... :(

Frank, Marco, Justin, any chance of this getting fixed before we start shipping it to users?

Comment 10

[Frank Yan (:fryn)]

This depends upon either bug 450953 (retrieving the space on which a window is displayed) or bug 674925 (using the drag & drop API for tab animations).

It is more likely that we will fix bug 674925.

(In reply to Boris Zbarsky (:bz) from comment #9)
> Frank, Marco, Justin, any chance of this getting fixed before we start
> shipping it to users?

The risk of landing a patch for either bug is too high to push to Aurora or Beta, so I would say unfortunately no.

Comment 11

[Frank Yan (:fryn)]

(In reply to Boris Zbarsky (:bz) from comment #9)
> This has been making it more or less impossible for me to actually drag tabs
> to tear them off from windows; I've been alternating between trying to use
> old builds and trying to just not drag tabs... :(

You don't have to drag a tab outside of a window to tear it off. You can drag the tab downwards until the preview panel appears and then simply drop it. To move the window around afterwards, drag the titlebar. While it requires two steps instead of one, it's an easy workaround until we can get this bug fixed.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> You don't have to drag a tab outside of a window to tear it off.

But I do if I want to actually place it on the desktop, or if I want to drag it to another window.

If I try to do the latter without really carefully positioning my windows first, then as soon as I leave the first window I suddenly end up on some totally different desktop.

Seriously, the behavior is completely broken.  Have you actually tried it?  I'm having a hard time believing we're actually going to ship something like this to users.  It's _way_ worse than what we used to have before the changes in bug 455694, making multi-window drag/drop of tabs almost completely unusable.

Can we disable the window-raising thing on Mac or something?  What would that break, and would it at least paper over this issue?

Comment 13

[Boris Zbarsky [:bzbarsky]]

In case you have _not_ tried how this feels, I urgently suggest you do try it, by the way.  It's by far the worst UI breakage I've encountered in Firefox in years.

Comment 14

[Boris Zbarsky [:bzbarsky]]

One more note.  The "easy workaround" above goes completely against years of muscle memory.  So it's very much not "easy"....

Comment 15

[Justin Dolske [:Dolske]]

Just talked with Frank, and we actually should be able to fix this. Hopefully both simply and quickly... (aurora too)

Frank, per discussion, can you start to whip up a patch to the front end code to do this, assuming the presence of some new platform API to deal with Spaces? Let's call it nsIDOMWindowUtils.isOnScreen for the moment? I've been poking through OSX dev docs, and it _looks_ like this shouldn't be too hard. That said I'm a Cocoa noob, so we'll see. ;-)

I'll file the dependent bug now to get the platform support.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Thank you!  Happy to test any patches you need testing for!

Comment 17

[Justin Dolske [:Dolske]]

Filed 683423 specifically for OS X, I suppose we'll need a Linux flavor of it too? Frank was going to check.

Comment 18

[Boris Zbarsky [:bzbarsky]]

On Linux, it's much more common to represent virtual desktops in terms of a single large desktop with nonoverlapping coordinate spaces on each desktop, so the problem may not even exist there typically.

Comment 19

[Frank Yan (:fryn)]

(In reply to Justin Dolske [:Dolske] from comment #17)
> Filed 683423 specifically for OS X, I suppose we'll need a Linux flavor of
> it too? Frank was going to check.

(In reply to Boris Zbarsky (:bz) from comment #18)
> On Linux, it's much more common to represent virtual desktops in terms of a
> single large desktop with nonoverlapping coordinate spaces on each desktop,
> so the problem may not even exist there typically.

Just tested it, and I confirm bz's statement. Linux (at least Ubuntu) is the only tier 1 OS for which we handle dropping of tabs onto other (work)spaces correctly.

Comment 20

[Frank Yan (:fryn)]

Attachment: patch dependent on bug 683423

Dolske, here's a patch! Of course, we can't land it until we land a patch for bug 683423.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Why is this invalid, if I might ask?

Comment 22

[Frank Yan (:fryn)]

We backed out the patches in bug 455694.