Open Bug 102132 (detachtab) Opened 23 years ago Updated 2 months ago

Ability to move content areas from tabs into new windows (Link/delink/detach tabs, port bug 225680)

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: roland.mainz, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: parity-safari, Whiteboard: [tabbrowser] )

Attachments

(1 obsolete file) 

RFE (2in1):
- Add option to move the content area of a window to a TAB within another window
- Add option to move the content area of a TAB into a new, independent window

The content area must not be changed - recreating the content may change it
(e.g. reloading from cache won't preserve dynamically changed content).
Component: XP Toolkit/Widgets: XUL → XP Apps: GUI Features
QA Contact: jrgm → sairuh
Whiteboard: [tabbrowser]
I can do this with a reload by cloning a new content area, but doing it without
changing the content area is nigh impossible in our system.


-> tabbrowser
Component: XP Apps: GUI Features → Tabbed Browser
QA Contact: sairuh → blakeross
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 103481 has been marked as a duplicate of this bug. ***
*** Bug 106263 has been marked as a duplicate of this bug. ***
while I'm cc spamming I'll just say:
a) drag a tab out of the stack (103481)
b) context menu / detach tab (or whatever words are appropriate) (106263)
*** Bug 111701 has been marked as a duplicate of this bug. ***
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!
QA Contact: blakeross → sairuh
*** Bug 113734 has been marked as a duplicate of this bug. ***
As per sairuh in bug 113734, I am adding my request to this bug.

A tab in window A should be able to be moved easily to window B.

This can be done with two steps if the detatch/attatch logic is in place, but it
would be nicer as one step, perhaps via drag and drop.



*** Bug 114586 has been marked as a duplicate of this bug. ***
Does this depend on bug 36269, bug 110535, and bug 112372 - like bug 18808?
These bugs are about cloning windows.

Actually, one of my requests were comment #9.

To recap what has been suggested: 

- Add option to move the content area of a window to a TAB within another window
- Add option to move the content area of a TAB into a new, independent window
- Move a TAB from one window to another
- Detach/drag a TAB to make it a new window

I'd like to add: 
- Context menu to concentrate all tabs into the same window with one click
- TAB manager that lets you easily manage all the TABs

Should these be all filed as separate bugs that block this one and make this one
a META? If that's the case, some of the duped bugs should probably be unduped.

Remember: one feature request per bug. That would qualify this as a META imho.



Obviously it doesn't depend on bug 112372 since that is specific to bug 18808.
Sorry.
*** Bug 117587 has been marked as a duplicate of this bug. ***
hyatt: Can't you actually move the <browser> element or its <iframe> from one
document to another? I thought the DOM had an "adopt" method or some such to
transfer nodes across documents like this.
Summary: RFE: Option to move content area from TAB <--> window → RFE: Option to move content area from TAB <--> window (Ability to link/delink tabs) (turn tabs into windows)
*** Bug 119410 has been marked as a duplicate of this bug. ***
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
*** Bug 132639 has been marked as a duplicate of this bug. ***
*** Bug 132638 has been marked as a duplicate of this bug. ***
*** Bug 133393 has been marked as a duplicate of this bug. ***
*** Bug 130936 has been marked as a duplicate of this bug. ***
Blocks: 126299
It would be nice if dragging a tab icon out of the window (and not onto another
window) moved the tab to a new window.

As for moving a window to a tab: if bug #113934 is fixed, the only thing that
would need to be added would be that dragging the last tab in window A into
window B would close window A (since the tab content has already been moved,
there would be no dataloss).
*** Bug 137624 has been marked as a duplicate of this bug. ***
*** Bug 142243 has been marked as a duplicate of this bug. ***
*** Bug 140849 has been marked as a duplicate of this bug. ***
Can the tab's icon be also made draggable just like the icon in the url bar?

Bamm, that is bug 111905.
*** Bug 146697 has been marked as a duplicate of this bug. ***
*** Bug 156070 has been marked as a duplicate of this bug. ***
I like this idea a lot as a drag n drop routine. Drag to empty desktop for a new
window, drag to another browser icon on the taskbar or another window itself to
move a tab to another window. The UI must stay simple as possible.
Alias: tabclone
*** Bug 162140 has been marked as a duplicate of this bug. ***
*** Bug 163316 has been marked as a duplicate of this bug. ***
*** Bug 166094 has been marked as a duplicate of this bug. ***
I'd like to add that it would be nice if a Tab could be changed into a seperate
window when you double-click on it. I guess that would be simpler than dragging
to the desktop (especially when you many open (or fullscreen) Moz-Windows it
might be hard to find an empty place). There is also a conflict with bug #113934
comment 14 when dragging a tab to the desktop.
QA Contact: sairuh → pmac
*** Bug 176113 has been marked as a duplicate of this bug. ***
*** Bug 170628 has been marked as a duplicate of this bug. ***
Many of the comments here call for what are essentially UI variations on ways 
to do the same thing.  The basic functionality needed, as I see it, is the 
ability to move a tab from one window to another.  (Creating new windows or
closing existing ones can be done already.)  Everything else is some variation
on that, or a UI for it.  There are other possible variations (such as the 
ability to bulk-move several tabs from one window to another, or to a new 
window), but we can discuss such variations further, or file bugs for them,
once the basic functionality is in place.
*** Bug 187310 has been marked as a duplicate of this bug. ***
*** Bug 188504 has been marked as a duplicate of this bug. ***
I've seen a window manager that does tabbing with any windows... just move the 
grab bar over another grab bar, and they become tabs...

I forget what it's called though, just saw someone sporting it at our lug.

anyway, there's also the issue of copying the history to the new window.

If this is creating a new window with duplicate of contents in tab, or tabbing 
a copy of something that is in it's own window...   the special stuff has to be 
done in mozilla...

if not, some investment into a window manager could save duplication of work.
*** Bug 191752 has been marked as a duplicate of this bug. ***
Alias: tabclone → detachtab
*** Bug 194131 has been marked as a duplicate of this bug. ***
Summary: RFE: Option to move content area from TAB <--> window (Ability to link/delink tabs) (turn tabs into windows) → Option to move content area from TAB <--> window (Ability to link/delink tabs) (turn tabs into windows)
Summary: Option to move content area from TAB <--> window (Ability to link/delink tabs) (turn tabs into windows) → Ability to move content areas from tabs into windows (Link/delink tabs)
> Drag to empty desktop for a new window, drag to another browser icon on 
> the taskbar or another window itself to move a tab to another window. 
> The UI must stay simple as possible.

Make sure there's an easy way to move a tab to a new window even if no
empty desktop is exposed. 

The context menu of a tab should also have a "move to new window" action.

Daniel


*** Bug 223631 has been marked as a duplicate of this bug. ***
See also bug 225680, same bug for Firebird.
*** Bug 210151 has been marked as a duplicate of this bug. ***
wishes list so far + my wishes:
- create new window from existing tab/tabs
- move single tab or group of tabs to existing window*
- create new tab from existing window*
- rearrange the order of tabs within existing window*

*drag-n-drop,
able to decide wish position to inserted/removed tab(s)


Maybe cuting/copying and pasting could be used along with or instead of
drag/dropping. Pasting might be more convenient at times.
I disagree with comment 21 because dragging to a not-mozilla-window is dropping
somewhere that mozilla doesn't control, and might be hard to implement. I
instead prefer comment 34 's approach (double clicking), but that might be hard
to do with multiple tabs. So I like the idea of being able to select multiple
tabs, right clicking on them, and selecting "Open tab(s) in New Window" (as I
believe comment 43 proposed).
Before anything can be done on this bug, we need to agree on what exactly needs
 to be done. I suggest:

-Ability to move tab(s) to a (new) window and vice-versa
-(It has been requested that the above be done without remaking the content, to
preserve dynamic content, but it has also been stated that doing so is "nigh
impossible")
-Ability to rearrange order of tabs
John: Not as an argument, just devil's advocacy, dragging a tab up would turn it
into a de-linked window, so it'd be just like dragging a window around. But I
can see how this would be an aggravation to people doing it by accident. Think
about detachable menus, and docking, its the same deal. We have to be very
careful how we go about this.

Now, with that being said, I have to agree I like the selecting multiple tabs
idea. Don't forget swapping them to already existing windows, that's where we
could apply the "Cut tabs", "Paste tabs" idea.

Rearranging tabs, otoh, could easily be a dragging operation. It could be done
much like the Launcher panels on the Gnome and KDE bars (or like you move icons
around in Quicklaunch on Windows) When you drag a tab far enough, they switch,
but the document content wouldn't be changed -- i.e. the selected tab would stay
selected.
Brian,
What do you mean by 'up'? Where exactly would the user drop the tab? Do you mean
that as soon as the user grabs the tab and pulls it away from the tab bar it
becomes a new window that the user is still holding (or a window with multiple
tabs)? I'd find that kinda annoying. What I would want is to hold only the
actual tab, not the content (the content would be moved afterward). That way I
could drag and drop to new windows more easily. Because if they detached to a
new window by default, then the user would have to take another step to attach
them to a window, and attaching them to another window is likely the users goal
if using the drag and drop method. Maybe there should be a detach button next to
the close button (probably an up arrow, and a 'dock' or 'attach' button, which
could be a down arrow). But if not, I think the cut/copy and paste would just be
more easy to implement than drag and drop. And probably more user friendly
because by definition the user would have to be going to a different/new window,
which is harder when holding something.
>What do you mean by 'up'? Where exactly would the user drop the tab? Do you mean
>that as soon as the user grabs the tab and pulls it away from the tab bar it
>becomes a new window that the user is still holding (or a window with multiple
>tabs)? I'd find that kinda annoying.

That is exactly what I meant, and I'd find it annoying and clunky too in many
cases. This would still be a 1-step operation because the drag operation would
not seize when the content area appeared outside the window. And then you'd dock
it in another window. Not very useful when the window you want to place it in is
not visible. This would be a cutesy thing that could be done much better.

As for dragging just the tab, that would be doable by making the tab become a
window instead of a drag icon, but still would not be very useful if the other
window were minimized or not visible.

I do not find dragging a good idea for this behavior at all. Its a cutesy thing
that would be less user friendly than something like the cut/paste method you
mentioned. I only wanted to say that it would be doable, not that I like it.

All we need to do is put "Cut tabs", "Send tabs to new window" and "Paste tabs"
in the context menu. We don't need any more buttons taking up the space tabs
could be filling, confusing users that don't know what they eman, and making it
possible to accidentally close the tabs instead of de-linking them.
Brian,

>As for dragging just the tab, that would be doable by making the tab become a
>window instead of a drag icon, but still would not be very useful if the other
>window were minimized or not visible.

(win32 - under X i am not sure, never tried it actually - never needed such an
option :)) it is possible to drag something onto a taskbar to make window rise
(and still, i think that for moving tabs around between windows it is better
using context menu)

>I do not find dragging a good idea for this behavior at all. Its a cutesy thing
>that would be less user friendly than something like the cut/paste method you
>mentioned. I only wanted to say that it would be doable, not that I like it.

how about reordering tabs inside same window?
it is possible to have drag-n-drop for the tab work
1. only inside the tab-bar itself to enable reordering the tabs inside it. 
2. inside window*

possible use example:
when searching, you have a lot of tabs open with search results, this option
would let user resort the tabs - lets say once found some useful link, drag it
to a corner for later use and keep looking at the rest of the results on the
other side of tabbar...

*this may be used to have the ability to dock tabs into different locations (tab
bars?) - like on any edge of the window... etc.
> (win32 - under X i am not sure, never tried it actually - never needed such an
> option :)) it is possible to drag something onto a taskbar to make window rise

I don't think we can count on this being a portable behavior.

> how about reordering tabs inside same window?
> it is possible to have drag-n-drop for the tab work

I have already said this is doable and is, imho, a good idea and could be done
much like the moving of icons around in the Quicklaunch bar on Windows (or for X
users, like rearranging the launcher panels).  

Hold on, though. If drag-and-drop is possibly not going to be what delinks a
tab, then we are really talking about different behaviors. We are going to have
to make this a META bug, or decide upon which behavior this talks about.

Does this bug talk about reordering tabs, or de-linking them? Seems to me by the
first comment and the subject that ordering tabs is a different bug.

If there is no bug filed for that, can someone please file one on ordering tabs?
*** Bug 243331 has been marked as a duplicate of this bug. ***
*** Bug 248464 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
For moving a selected tab or tabs to another window, we can implement this in
two ways, dragging and dropping the tabs as mentioned many times, and as a
backup for OSes that don't support that well, we can use a cut/paste behavior
(comment #48). I don't think we should call this "Cut Tab" and "Paste Tab",
though, because that might confuse people. Since a tab can be selected in each
window, we should probably have an option that says something like, "Flag
selected tabs in this Window" and then we could have an option, "Move flagged
tabs here"
Select multiple tabs is bug 132674
netdragon,

You could just do it in one swift move instead of having to flag a tab for move
and then making the request in the window it's moving too.

The dialog (presumably as part of the tabs right click context menu) could just
include:

Move tab to a new Window, or
Move tab to Window 1 (List of current pages)
            Window 2 (List of current pages)
            Window 3 (List of current pages)
            .....

or alternatively:

Move Tab to...
    New Window
    Window 1
        Tab 1-1
        Tab 1-2
        Tab 1-3
        ...
    Window 2
        Tab 1-1
        Tab 1-2
        Tab 1-3
        ...
    ...        

The window names and tab names would take a little thought, but shouldn't be to
hard.  This would mean that moving tabs could be done in one swift move.  I like
the second option more because you could place the tab being moved after the tab
the user selects (to place a the start of the tabs you would select the
Window??? - is this possible).

I'm also assuming that if it's going to be possible to move tabs from one window
to another it will be possible to reorder tabs in the same window too.
*** Bug 255177 has been marked as a duplicate of this bug. ***
*** Bug 261636 has been marked as a duplicate of this bug. ***
*** Bug 243331 has been marked as a duplicate of this bug. ***
*** Bug 277161 has been marked as a duplicate of this bug. ***
Blocks: 243331
No longer blocks: majorbugs
In my opinion 'Detach Tab' option in context menu would be nice too. Detaching 
by dragging outside is also good idea, but not always one have some free space 
to drag to. Moreover dragging is very unpleasant operation to perform using 
touchpad so should never be the only way to do some thing.  
Ugh, my comment was intended for some other bug, missed that bugzilla moved me. 
ALthough ... it can be somehow related to this bug, since I have laptop I hate 
dragging ;-) 
*** Bug 314972 has been marked as a duplicate of this bug. ***
As a final remark and the icing on the cake, we could assign a shortcut to merge (reattach) all tabs from all windows back to one window. One way could be by selecting the tabs from the operating system task bar, right-clicking it, and then clicking Merge. I welcome your suggestions!
Agreed!

I like the syntax
   "right click"->"Move tab to new window".
Then
   "Window"->"Move window into new tab".

The new tab would come in the most recently selected tab group.
Are you doing anything to add this feature? Come on, even Konqueror is better in this case and has had this for a long time... open Konqueror, open two tabs in it, right click on a tab, select "Detach Tab (Ctrl+Shift+B)", and the tab is detached and appears as a new window. Is it really that hard to implement that?...

Look at the number of votes and CCs on this bug...
Jakub: so you're volunteering, then?
Eh... well... it's not what I meant :) I've never worked with Mozilla code, so it would take me a lot of time to learn how to do this. It's rather a job for someone who knows how Mozilla works internally...

I'm sorry if my previous post sounded more like a demand than a feature request - I just wanted to remind the developers of this bug, it was first reported 6 years ago, and since 2005 there was only one post besides mine, so it seems like nobody remembers about it or no one cares.
FWIW, Galeon also supports this feature, using Gecko
There's an easy part and a hard part to this feature. The easy part is taking a tab and moving it to another window (bug 113934) or making it its own window (this bug). The hard part is to not lose your current state (e.g. JS modifications made to the DOM, your current score in that Flash game, form state), though with the fast-back cache some of that can be worked around. See also bug 113934 comment 37 and on.
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
It seems Konqueror doesn't support the "hard part", just the "easy part" (if I write something in a form and select detach tab, it shows a dialog which says "This tab contains changes that have not been submitted. Detaching the tab will discard these changes."). So I think it would be enough for now to implement just the detaching at first, and think about restoring the state of the page later.
What is this FR calling for that is not already supported by Firefox 2 with Tab Mix Plus add-on installed? https://addons.mozilla.org/en-US/firefox/addon/1122
I admit I didn't know about this plugin... The "Move to new window" feature does exactly what I wanted. Thanks!
stripping it off using your mouse and ALT, e.g. would be even better.

how about a feature instead of just an extension? would show innovative GUI thinking that would leverage firefox as opposed to ie7/opera.

if not, let's close this feature request.
PS I think the extension is called Tab to Window: https://addons.mozilla.org/en-US/firefox/addon/2062
(In reply to comment #76)
> how about a feature instead of just an extension? would show innovative GUI
> thinking that would leverage firefox as opposed to ie7/opera.

The idea of this bug IS to make it a feature, but not the way that the extension does it, and it's going to take more time to do it right than we have for Firefox 3 (read comment 72 again). So please leave it open.
> how about a feature instead of just an extension? would show innovative GUI
> thinking that would leverage firefox as opposed to ie7/opera.

Wasn't one of the features of Firefox supposed to be that it would be smaller and lighter without the bloat that Mozilla used to be? A user can add the add-ons/extensions for the features they want, without having to be burdened with all the features someone else can't live without, but this user will never touch.

Perhaps what is needed is a better process of advertising and promoting "standard extensions", and ensure that they are managed with the main codebase. That's outside the scope of a bug report though.
I think, before assuming that this will cause bloat, we should analyze benefit versus effort and bloat impact.

If this is a small effort and has little bloat impact, we may be ahead of other browsers by offering such an user-friendly, intuitive and original experience.
> There's an easy part and a hard part to this feature. The easy part is taking
> a tab and moving it to another window (bug 113934) or making it its own
> window (this bug).

Perhaps one might also consider implementing what is easy and filing a new bug for the hard part. Doing the easy part now will expose other problems that may arise in the implementation.

> The hard part is to not lose your current state (e.g. JS
> modifications made to the DOM, your current score in that Flash game, form
> state), though with the fast-back cache some of that can be worked around.
> See also bug 113934 comment 37 and on.

Firefox already saves the states of each tab in the session restore. I don't think it will restore a game score but may just be a limitation of the way firefox saves states.

Let us use the saved state and then file a new bug for each "state" that isn't saved. This will also improve the session restore, and any other feature that relies on the saved state of the pages.

At some point in the last several months, the first option (moving a tab between windows) has been implemented.  The second one (creating a new window from a tab) has not.  Gruber recently complained about the lack of this feature.  http://daringfireball.net/2008/04/firefox_3_safari_3http://daringfireball.net/2008/04/firefox_3_safari_3
And as he points out, Safari already does it.

Not sure how invasive this is to implement, it might be better as wanted-next, but Bugzilla isn't letting me request that.
Flags: wanted1.9.0.x?
Whiteboard: [tabbrowser] → [tabbrowser] [parity-safari]
Depends on: 113934
Product: Core → SeaMonkey
We don't typically add features in maintenance releases, so not wanted1.9.0.x, but requesting wanted1.9.1.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
(In reply to comment #87)
> *** Bug 452169 has been marked as a duplicate of this bug. ***

This bug is about Seamonkey, almost every bug that has been marked a duplicate of this one is about Firefox. These bugs should be marked as a duplicate of bug 225680 instead.(In reply to comment #87)
Flags: wanted1.9.1?
Changing summary to make this findable and show what needs to be done (port bug 225680).
Summary: Ability to move content areas from tabs into windows (Link/delink tabs) → Ability to move content areas from tabs into new windows (Link/delink/detach tabs, port bug 225680)
Wow, it looks like after all this time (8 years!) it has been finally fully implemented in Firefox. Nice...
I hate this! Please remove this feature or add an option to switch modes. I like more as it was before - to move links from tabs to Desktop as URL FILE!
Sorry the previous was about Firefox, I didn't note that it is SeaMonkey product.
I think that this bug should relate to Firefox, not seamonkey.

But if you want to drag URL's to the desktop, shouldn't this be done from the location bar (in the same way it works for bookmarks) and not from the tab handle (which is more about 'windows' and less about 'urls')
Rodd, this bug was filed years before Firefox existed. I think it absurd that any bug that was filed before Firefox existed is ever allowed to have its product changed to Firefox. Such bugs should either be changed to core or suite or expired. If the same bug does apply to Firefox and not core, then a new bug should be filed against Firefox.
Bug 225680 is that "new" bug.  Hence the summary line here.
Or, given that when this bug was filed, mozilla was the product, and that now that firefox is the main product, maybe it makes sense that the the product is changed to firefox (and not the highly less used seamonkey).

I'm not sure how it got to be listed under seamonkey since it was a bug filed against mozilla, but if it can change once, why not again.
Already asked and answered.  If you want a Firefox specific bug, that you think doesn't already exist, file a new one.
"shouldn't this be done from the location bar and not from the tab
handle?"
Probably should, but it does not work so.
Depends on: 449728
No longer depends on: 113934
No longer blocks: 243331
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-safari
Whiteboard: [tabbrowser] [parity-safari] → [tabbrowser]

Comment 100 is spam, but it looks like I don't have privs to tag comments here. Same MO as Bug 27493 comment 47, different login.

Attachment #9386401 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: