191752 - "Move Tab to New Window" option in tab bar context menu

Status: NEW

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Hermann Schwab]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030202
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030202

That means, move, copy or reload the contents of a tab into another tab in a new
window.
That´s not a dupe of bug 102132, which proposes transfer Tab <==> Window.

You get the advantage of "Close Other Tabs" without the hassle of inadvertently
closing all other tabs. I´m often switching between tabs, comparing, so it is no
option for me to close each tab after I´ve read it, I always have to close a lot
of tabs.

My workaround now is:

1. copy the URL from the tab I want to hold
2. create new window
3. paste URL and select
4. press Enter.

Implementation of this RFE would give me the functionality I had,
plus the advantage that I could repeat this process with the old window for
another tab, and a single click to close the old window when I`m sure I don´t
need it anymore.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

So this is not a duplicate because you're willing to have the page be reloaded
from the server in thise move to a window?

Comment 2

[Hermann Schwab]

Yes, it doesn´t matter, I´ve got to reload the page anyway, as of now.
I´m used to reading long articles with lots of links, and open the links in tabs
loading in the background. 
Also if I do a query in bugzilla, I´ve got the list with 44 bugs in my first
tab, and open some of the bugs in other tabs, then close the bug tabs, and
create some new from the list.
Mostly I want to get rid of the rest of the tabs, but hold to one, old or new,
to continue from there, and open new tabs.

I´ve got a problem, and I suggest a solution, imho a simple solution,
but that´s an uneducated guess.
My problem was created by removing a valuable function which was catastrophic to
those not using it, and invoking it by accidentily.
Ok, I also crashed my tabs sometime, but that was less of a problem to me than
these workarounds, or deleting 20 tabs one after another.

The other bug was some solutions searching for a problem,
and so I insist on this little difference.
Make it a dupe or not, I would like to see it solved soon,
because I think that this function was the most valuable in using tabs.
What can I do with tabs I can´t do with windows?
Opening a group of windows from bookmarks is faster than closing a group of tabs
one by one. That function was my swiss tool of file handling,
- close all but one
- close all but one, and then the one, so I didn´t need to restart mozilla.
- used it with multiple windows.

Would you remove the sidebar, because I´m not used to it, find it disturbing,
taking to much room of the browser window?
Bad comparison?
No, I don´t use sidebar, because I got no use for it, or I´m not used to it.
But I saw some nice applications for sidebar, maybe, I will care about it
sometime when I´ve got an hour to play with it, to get aquainted.
That´s my last statement to this bug, if I´m not asked about it,
I don´t want to write a novel in bugzilla, it´s for bugs not for novels.

Comment 3

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 102132 ***

Comment 4

[Boris Zbarsky [:bzbarsky]]

reopening.  See comment 1.  This bug is easy to fix for anyone who cares, unlike
bug 102132.

Comment 5

[Jason Bassford]

Stating an assumption: If this is done, the focus should shift to the new window
with the single tab (this would most closely emulate closing all other tabs) in
spite of any "load in background" prefs set.

Comment 6

[Jason Bassford]

Note that if either bug 191492 or bug 191818 gets fixed, this bug will not be
necessary.

Comment 7

[Hermann Schwab]

If this one RFE gets implemented, these two other bugs don´t have to be fixed ;-)
"Close Other Tabs" will always lead to loss of tabs. In the past it had hurt
all, who didn´t use this feature and clicked the wrong line, in the future it
will hurt those, who inadvertently press the metakey when they only want to
delete one tab.

Splitting this action, by saving the tab you want to save,
and killing a whole window in a second action,
gives you back the advantage of the old function,
and takes away the risk of inadvertently clearing your tabs.
Only the first function has to be implemented,
move, clone, load, whatever is the easiest way,
the second function, killing the window, exists in various known ways.

Comment 8

[Andrés G. Aragoneses]

I was thinking about inserting this RFE in buzilla. Interesting feature! Adding
me to the CC list.

Comment 9

[John]

Shouldn't the OS be changed to all?
Also, this bug asks for the ability to "move, copy or reload the contents of a
tab into another tab in a new window". This really isn't that much different
from bug 102132 because this bug is asking for the ability to "transfer Tab <==>
Window", at least in the tab->window direction, isn't it? Also, if (like me) the
user has tabs enabled by default what exactly is the difference? Also, your
workaround doesn't _____ the contents "into another tab in a new window" unless
you open a tab as step 3.

Comment 10

[Andrés G. Aragoneses]

Attachment: proposed patch

This is my proposal for the patch. I think it is quite simple.
Please, review it.

Comment 11

[John]

hermann,
I'm not sure if this patch will work or if this bug will be fixed soon, but in
case you don't want to wait, and in case you'd rather spend your time surfing
than filing bugs, you might just want to download multizilla from
multizilla.mozdev.org/installation.html
It solves this bug and many others right out of the box. With a little
customization in can do even more. Try it; it makes bugzilla.mozilla.org a waste
of time.
(Pulling vote to do fact that I can already do this)

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Andrés G. Aragoneses]

Do anyone know the equivalent bug of this one that targets Firefox instead of Seamonkey?

Comment 14

[Bruno 'Aqualon' Escherl]

The functionality is partly implemented. You can drag a tab to another window and it's loaded there. I'm not sure if we want to have this kind of functionality in the tab context menu, especially without having bug 449728.

Comment 15

[[e-mail]]

(In reply to comment #14)
> The functionality is partly implemented. You can drag a tab to another window
> and it's loaded there. I'm not sure if we want to have this kind of
> functionality in the tab context menu, especially without having bug 449728.
That just means that this bug seems to be dependent on bug 449728. (Or it may indeed get fixed as part of that bug, depending on whoever ports it.)

Comment 16

[Philip Chee]

Marking as new for the time being.