Open Bug 318260 Opened 16 years ago Updated 12 years ago

Drag tabs between windows

Categories

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

PowerPC
macOS
enhancement

Tracking

(Not tracked)

People

(Reporter: nicolas.dupont.1980, Assigned: Jeff.Dlouhy)

References

(Depends on 1 open bug)

Details

(Whiteboard: 1.9.1)

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
Depends on: 160720
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Blocks: 338983
Assignee: mikepinkerton → d.elliott
QA Contact: tabbed.browsing
Status: NEW → ASSIGNED
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. :)
Sorry, that was supposed to be, "Personally, I don't find x very useful as it is implemented in Colloquy...".
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
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?
(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
The Desktop is already a valid drag target with a sensible action: creating a webloc.
(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

Oh, right (need more sleep).  When we drag an image to the Desktop/etc., we save the image there, FWIW,
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.
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?
> 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. 
Setting priority per 1.6 roadmap.
Priority: -- → P1
Setting priority per 1.6 roadmap.
Priority: P1 → P2
Assignee: des.elliott → nobody
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Assignee: nobody → Jeff.Dlouhy
Status: ASSIGNED → NEW
bz has a patch on bug 113934 that might help do this and solve bug 339472.
You need to log in before you can comment on or make changes to this bug.