Detaching and clonong of tabs
Klaas Heidstra
possibility to detach a tab by either dragging a tab to the desktop or
by adding an option to the right-click tab menu. Dragging a tab to the
desktop currently creates a shortcut on the desktop, so the drag part
isn't really an option.
My latest patch in that bug adds the following command-keys:
* Ctrl+Shift+C - to clone a tab
* Ctrl+Shift+N - to clone a tab in a new window
* Ctrl+Shift+M - to move a tab to a new window(detach tab)
Besides that these items are added to the tab context menu (see
https://bugzilla.mozilla.org/attachment.cgi?id=333582 for a
screenshot):
* Clone Tab
* Move Tab To New Window (detach tab)
There are some problems with this approach (that's why I'm opening
this topic). First the tab context menu gets 10 items in this way, is
there a way to reduce this or is the tab menu even the right place?
Second is there a way to make it possible to detach a tab by dragging
it somewhere? And I would also like to ask what the people here think
about the commandkeys I'm using.
Klaas Heidstra
to not add new tab menu items and commandkeys. Instead the best way to
make it possible to detach a tab is by dragging it to the desktop
(saving a shortcut to desktop will be made impossible in this way).
But there are other ways to duplicate a tab, there are a lot of
duplicates in Bugzilla for letting middle-clicking on the back and
forward duplicate the tabs history (this can also be done for middle-
click on the reload button). This will make it possible to middle-
click the forward button, then in the new tab it creates you can
navigate session history in the same way as in the original tab.
Some questions about this are (© Mike Beltzner):
- was not cloning the tab deliberate behaviour?
- if so, why?
- if not, should we do it?
The bug for implementing this is: https://bugzilla.mozilla.org/show_bug.cgi?id=448546
John J. Barton
> After some talking with Mike Beltzner the outcome was that it is best
> to not add new tab menu items and commandkeys. Instead the best way to
> make it possible to detach a tab is by dragging it to the desktop
> (saving a shortcut to desktop will be made impossible in this way).
Desktop? Wasn't that something they had back in the 20th century? I
haven't seen one in years. ;-)
If the menu on the tab only operated on the tab, then the number of
entries in that menu would be very manageable: reload, bookmark, clone,
move, close and perhaps new. clone+move supports clone-into-new-window.
Its the non-tab items that clutter the menu (xxx All Tabs).
jjb
Klaas Heidstra
wrote:
> ...
> If the menu on the tab only operated on the tab, then the number of
> entries in that menu would be very manageable: reload, bookmark, clone,
> move, close and perhaps new. clone+move supports clone-into-new-window.
> Its the non-tab items that clutter the menu (xxx All Tabs).
>
> jjb
True, but those features are very useful, when you can detach a tab by
just dragging it to the desktop, a "detach tab" tab menuitem becomes
less important. As for cloning tabs I think it would be very handy
when you could duplicate a tab (and retain it's history) by just
middle-clicking the reload-button, the same applies to the back and
forward buttons. But for that to happen the above questions from Mike
Beltzner need to be answered. Making the tab menu have less items is
something for another bug I think.
John J. Barton
> On Aug 23, 6:18 pm, "John J. Barton" <johnjbar...@johnjbarton.com>
> wrote:
>> ...
>> If the menu on the tab only operated on the tab, then the number of
>> entries in that menu would be very manageable: reload, bookmark, clone,
>> move, close and perhaps new. clone+move supports clone-into-new-window.
>> Its the non-tab items that clutter the menu (xxx All Tabs).
>>
>> jjb
>
> True, but those features are very useful, when you can detach a tab by
> just dragging it to the desktop, a "detach tab" tab menuitem becomes
For me, dragging to the desktop is an impractical and counterintuitive
way to create a new window with a tab. Impractical because the desktop
is invisible behind forty windows; counterintuitive because we already
use drag to the desktop to store short cuts to web pages. Maybe Mac
users still use their desktop in their work, but I bet Windows desktop
is used mostly as a TEMP dumping ground.
jjb
Klaas Heidstra
> For me, dragging to the desktop is an impractical and counterintuitive
> way to create a new window with a tab. Impractical because the desktop
> is invisible behind forty windows; counterintuitive because we already
> use drag to the desktop to store short cuts to web pages. Maybe Mac
> users still use their desktop in their work, but I bet Windows desktop
> is used mostly as a TEMP dumping ground.
>
> jjb
It could be made in such a way that dragging the tab to the content
part of the browser also detaches the tab. In fact dragging it to
parts of the screen where currently nothing happens could detach the
tab (this is also how it works in Safari and Opera).
Nevertheless I must say that I agree with you that detaching/cloning
items in the tab menu would be nice, but the people at mozilla don't
want to make that menu larger then it already is. So that menu needs
to be cleaned up first before something new can be added, but that
should be done in another bug(I don't know if there already is one on
file).
But what do you think about cloning a tab by middle-clicking the
reload-button, and letting middle-click on the back/forward buttons
retain it's history (because those are the real questions that need to
be answered in this topic)?
Gervase Markham
> True, but those features are very useful, when you can detach a tab by
> just dragging it to the desktop, a "detach tab" tab menuitem becomes
> less important.
Except that many people (including me) operate in "single-app mode",
where all of their apps are maximised, and they switch-between them
using Alt-Tab. As John said, I only ever see my desktop when I boot up.
I've never actually _used_ it for anything in years.
Gerv
Mike Beltzner
We can revisit the idea of a shortcut on the tab menu, but that's not
really what this thread is supposed to be about.
Does anyone know why the decision was made for cmd+back/forward/reload
to open the URL in a new window without cloning history as opposed to
carrying the history over?
cheers,
mike
Boris Zbarsky
> Does anyone know why the decision was made for cmd+back/forward/reload
> to open the URL in a new window without cloning history as opposed to
> carrying the history over?
I suspect the only way to answer that is to do the CVS archeology to see
the bug it was checked in under. But I suspect the answer is "it was
easier that way".
-Boris
Klaas Heidstra
> I suspect the only way to answer that is to do the CVS archeology to see
> the bug it was checked in under. But I suspect the answer is "it was
> easier that way".
>
> -Boris
A comment in gotoHistoryIndex says:
> // Modified click. Go there in a new tab/window.
> // This code doesn't copy history or work well with framed pages.
duplicateTab didn't exist when this was implemented, so I guess the
reason is that is was technically to complicated to implement. But
looking at that comment copying history was the preferred way to do it.