318260 - Drag tabs between windows

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Tabbed Browsing, enhancement, P2)

Description

[Nicolas Dupont]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Since there doesn't seem to be any way to browse in a single window mode it would be nice to be able to drag tabs between different windows.

Reproducible: Always

Comment 1

[Chris Lawson (gone)]

Targeting for 1.2, since that's what bug 160720 is targeted for. I suspect that once that bug is fixed, this fix will either come free with it or be fairly trivial to add on.

cl

Comment 2

[Håkan Waara]

Personally, I don't find "dragging tabs out of a window to create a new window" very much as it is implemented in for example Colloquy. 

More often than not, I accidently drag a tab and it becomes a new window (which I can't reinsert again with my other tabs).

So an idea for this bug: implement dragging tabs between windows *without* the new window-spawning part. Dunno if this was planned, but just my two pre-emptive cents. :)

Comment 3

[Håkan Waara]

Sorry, that was supposed to be, "Personally, I don't find x very useful as it is implemented in Colloquy...".

Comment 4

[Desmond Elliott]

Sketches of my proposed implementation are available at http://wiki.caminobrowser.org/Image:Bug318260-1.jpg and http://wiki.caminobrowser.org/Image:Bug318260-2.jpg

Comment 5

[Chris Lawson (gone)]

I agree with Håkan. I don't see much point in dragging to create a new window; we already have a contextual menu item for that and it seems awfully easy to invoke by accident. Furthermore, dragging a tab to the desktop (read: blank space that isn't in a Camino window) seems like it ought to have some other action, like saving the file or something.

cl

Comment 6

[Desmond Elliott]

You are right Chris, it will probably be extremely annoying for users who just wanted to drag the tab to the [extreme] right of the tab bar and all of a sudden they have a new window - d'oh!

Are you suggesting that we drop support for being able to drag tabs out of the current window to create a new window? But leave in support for being able to drag tabs into a different existing window?

Comment 7

[Chris Lawson (gone)]

(In reply to comment #6)

> Are you suggesting that we drop support for being able to drag tabs out of the
> current window to create a new window? But leave in support for being able to
> drag tabs into a different existing window?
 
Either that, or we make the Desktop a valid drag target with a sensible action, like saving that tab to the Desktop.

cl

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The Desktop is already a valid drag target with a sensible action: creating a webloc.

Comment 9

[Chris Lawson (gone)]

(In reply to comment #8)
> The Desktop is already a valid drag target with a sensible action: creating a
> webloc.

Only when dragging the favicon. Since the favicon and the rest of the tab are going to be two distinct drag handles with two distinct behaviours everywhere else, do we want their drag behaviours when dropped on the Finder to be identical?

cl

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Oh, right (need more sleep).  When we drag an image to the Desktop/etc., we save the image there, FWIW,

Comment 11

[Mike Pinkerton (not reading bugmail)]

i think we need some usability testing here before we scrap this idea. if we can get the feel right for the drag (it's way too sensitive in colloquy, for example) it might be quite useful for people. If we can't, we can always scrap it later but at least we'll have proved it with real data.

Comment 12

[Desmond Elliott]

It wont do much use to post my patch for this here because it is pretty darned broken.

Here is how I am approaching things:

When the user drags a tab from one tab bar into another tab bar - draggingEntered - a check is called to see if the tab bar it is being dragged into is different - ![[sender draggingDestinationWindow] isKeyWindow]. If this evaluation is true then a temporary tab is created to store the tab that is being dragged.

Then I go through a monstrous series of subviews from the draggingDestinationWindow to get to the BrowserTabView of the destination - [[[[[[[[[sender draggingDestinationWindow] contentView] subviews] objectAtIndex:0] subviews] objectAtIndex:1] subviews] objectAtIndex:0] tabView]. As you can see, a call like that is total insanity.

Anyway, the tab that is being dragged is removed from the draggingSource NSTabView and inserted into the draggingDestinationWindow NSTabView.

This causes weird redraw (within the inactive tab sheets in the window being dragged into) and sometimes GDB pops up with different errors everytime.

I get the feeling that I am going about this in totally the wrong way, can anybody offer me any advice?

Comment 13

[Håkan Waara]

> Then I go through a monstrous series of subviews from the
> draggingDestinationWindow to get to the BrowserTabView of the destination -
> [[[[[[[[[sender draggingDestinationWindow] contentView] subviews]
> objectAtIndex:0] subviews] objectAtIndex:1] subviews] objectAtIndex:0]
> tabView]. As you can see, a call like that is total insanity.

You should see if there's a way you can ask that BrowserWindow (or ask the BWC) for a window's tabbar. If not, create an accessor method. 

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Setting priority per 1.6 roadmap.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Setting priority per 1.6 roadmap.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

bz has a patch on bug 113934 that might help do this and solve bug 339472.