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

NEW
Unassigned

Status

SeaMonkey
Tabbed Browser
--
enhancement
15 years ago
7 years ago

People

(Reporter: Hermann Schwab, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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:
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?
(Reporter)

Comment 2

15 years ago
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.

*** This bug has been marked as a duplicate of 102132 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
reopening.  See comment 1.  This bug is easy to fix for anyone who cares, unlike
bug 102132.
Status: RESOLVED → UNCONFIRMED
Keywords: helpwanted
Resolution: DUPLICATE → ---

Comment 5

15 years ago
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

15 years ago
Note that if either bug 191492 or bug 191818 gets fixed, this bug will not be
necessary.
(Reporter)

Comment 7

15 years ago
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.

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Replace "Close Other Tabs" by "Move Tab to New Window" → "Move Tab to New Window" option in tab bar context menu

Comment 8

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

Comment 9

14 years ago
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.
Created attachment 140387 [details] [diff] [review]
proposed patch

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

Updated

14 years ago
Attachment #140387 - Flags: review?

Comment 11

14 years ago
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)

Updated

12 years ago
Attachment #140387 - Flags: review? → review?(beng.bugs)

Updated

11 years ago
Attachment #140387 - Flags: review?(beng.bugs)
(Assignee)

Updated

9 years ago
Product: Core → SeaMonkey
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser

Comment 12

8 years ago
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
Status: NEW → UNCONFIRMED
Do anyone know the equivalent bug of this one that targets Firefox instead of Seamonkey?
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.
Keywords: helpwanted
Whiteboard: [CLOSEME INVA/WONT?]
(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.)
Depends on: 449728

Comment 16

7 years ago
Marking as new for the time being.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [CLOSEME INVA/WONT?]
You need to log in before you can comment on or make changes to this bug.