470189 - Dropping a tab on other existing browser window shouldn't detach it to 3rd window

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[tabmix.onemen]

Dropping a tab on other existing browser window shouldn't detach it to new 3rd window

if you drop the tab on the other window tabbar then the result is ok. and the tab is move/copy to the target window.
but if you drop the tab on other existing window content area (or any other place other then the tabbat) the tab detach to new 3rd window and not to the target window.

Comment 2

[tabmix.onemen]

(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of bug 465346 ***

Mardeg, this bug is not about threshold at all !!!

Comment 3

[Mardeg]

Sorry about that, re-opening and it also blocks bug 471499

Comment 4

[eyal gruss]

the landing of bug 471499 seems to have changed the behavior so now there is no detachment at all

Comment 5

[IU]

Well, now it's broken again because of Bug 475066

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Doesn't block, but would be nice to fix.

Mano: if we drag a tab from the tabstrip of window A to the content window B, we should really just add it to the tabstrip of window B (since the tabstrip itself is a small and hard to hit target)

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Nominating wanting to put this on the radar and per comment 6.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I was playing around trying to patch this bug, when I realized that I wasn't quite sure what this bug was about.  

To clarify, this bug is to change the behavior so that when a tab from the tabstrip of window A is dropped on the content area of window B, the tab does not detach to window C, but rather detaches to window B, correct?  This bug is also not to change the behavior that appears to have been set in bug 471499 where dragging a tab from the tabstrip of window A to the content area of Window A detaches the tab to window C, correct?

Or more simply, the content area we're dragging to is in a different window than the tab originates from in this bug, correct?

Comment 10

[Colm Smyth]

Correct, dropping on content area of an existing window copies (with shift key) or moves (default, unshifted) to that window. If move is hard, copy all the time would still be very useful (and match the general rule for drag-and-drop).

I think if you drag from window A's tabstrip to A's content pane, it should also do a copy.

It should open in a new window only if you drag to the desktop (if that can be easily detected). If not, then double-clicking on a tab seems like a natural way to "maximize" that tab, that is to open it in its own window (comparable with the behaviour of double-clicking on a window's title bar on Windows).

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'll have a patch up in a few hours.

(In reply to comment #10)
> Correct, dropping on content area of an existing window copies (with shift key)
> or moves (default, unshifted) to that window. If move is hard, copy all the
> time would still be very useful (and match the general rule for drag-and-drop).

Yep, that's what the patch will implement.

> 
> I think if you drag from window A's tabstrip to A's content pane, it should
> also do a copy.

Beltzner was adamant in bug 471499 that the current behavior be used, so I'm not touching that.

> 
> It should open in a new window only if you drag to the desktop (if that can be
> easily detected). If not, then double-clicking on a tab seems like a natural
> way to "maximize" that tab, that is to open it in its own window (comparable
> with the behaviour of double-clicking on a window's title bar on Windows).

Interesting idea, but would you would need to file another bug for that change.  I don't know that non-Windows OS's use the double-click behavior like that anyways (I know KDE doesn't).

As I said, I'll have a patch for this in a bit.

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

This patch translates a tab drop on the content area into a drop on the tab strip iff the tab does not belong to the current <tabbrowser> element.  This preserves the current behavior where dragging a tab to its own content area detaches it to a separate window.

Requesting ui-review from Beltzner before proceeding with code review.

Comment 13

[Colm Smyth]

Kyle, you're awesome, a model of what mozilla.org can achieve; thanks is too small a word. No wonder Firefox is up to a billion downloads. 

BTW, I'm sorry but I believe Beltzner is wrong; that's entirely non-intuitive behaviour. One day we'll have a better way to solve the problem of one user designing the behaviour for a billion ;) (yes, I know that's exactly what I've done, so I fully appreciate the irony of that statement ;)

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

The part I get stuck on with this is: if dropping tab a1 from window A into the content area of window A creates a new window, why would dropping tab b1 from window B into the content area of window A add that tab to window A?

Checking into other browsers:

Safari acts like this patch suggests (tabs dropped into the content areas of their original windows will break off into new windows, tabs dropped into the content areas of other windows will be added as tabs to that window)

Chrome acts like we currently do (tabs only re-parent to a window if they're dropped on the tabstrip)

I believe that these design decisions were made because, by default, Safari doesn't show the tabstrip if there's only one tab; thus, there'd be no way to transfer a tab to a window that doesn't already have multiple tabs.

Overall, I think this patch is right, as it's more likely that the user is trying to re-parent the tab if they're hitting the content area of another browser window; especially since to create a new window they would only need to drag into the origin window's content area, or up and out to the desktop. But would appreciate input from the rest of the UX team (cc'd)

note: I'd really rather we first fix the fact that there's insufficient feedback (in terms of the drag preview and mouse cursor) about what will happen when the user finishes the drag operation (see bug 485105 and bug 483776)

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'm not working on this anymore.  Feel free to take my patch forward.

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Sorry for the spam, stupid mouse wheel.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mike, could you have a look at the outstanding ui review for the attached bug?

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 394758 [details] [diff] [review]
Patch

Not sure if this is still relevant, am sure I'm not the right reviewer :)