Klaas Heidstra Reporter
	Description • 16 years ago

This adds the clone tab item and the command key that were first in the patch in bug 225680.

	Dave Garrett
	Comment 2 • 16 years ago

The bugs for this are bug 432094 and bug 433518.
(if lands you may was well dupe the older bugs to here)

It should probably be labeled "Duplicate Tab", not "Clone Tab", as that has been used in this context before and would probably be more familiar to most users.

	Klaas Heidstra Reporter
	Comment 5 • 16 years ago

(In reply to comment #2)
> The bugs for this are bug 432094 and bug 433518.
> (if lands you may was well dupe the older bugs to here)
> 
> It should probably be labeled "Duplicate Tab", not "Clone Tab", as that has
> been used in this context before and would probably be more familiar to most
> users.
In this patch I'm now using "Duplicate Tab", the reason I used Clone Tab was because I use the ctrl+shift+c commandkey (D isn't available).

	Dave Garrett
	Comment 6 • 16 years ago

(In reply to comment #5)
> In this patch I'm now using "Duplicate Tab", the reason I used Clone Tab was
> because I use the ctrl+shift+c commandkey (D isn't available).

Makes sense. ctrl+shift+c still sounds logical to me for this, seeing as ctrl+c is standard for "copy", so I think this is probably good.

	Klaas Heidstra Reporter
	Comment 7 • 16 years ago

One question remains, should the duplicated tab appear next to the "original" tab or should it appear at the end of the tabbar. When I have a lot of tabs opened, I found out that placing it at the end didn't work very well, and perhaps it would be better to place it next to the tab you're duplicating.

	Dave Garrett
	Comment 8 • 16 years ago

Yeah, I think it makes more sense for duplicates to appear directly after the original. However, I'm sure you could make an argument for either method.

	Klaas Heidstra Reporter
	Comment 9 • 16 years ago

This screenshot shows the tab context menu with Duplicate Tab instead of Clone Tab.

I'm not sure what direction Asaf Romano is going with bug 225680, so I don't know if the duplucateTabIn stuff should move to this bug or not. This means I can't change the position where the cloned tab is moved to until I know more about. As soon as Mano has posted a first patch in that bug, I will upload a new patch here with the "place duplicated tab next to original tab"-behavior

	techtonik
	Comment 10 • 16 years ago

Looking on the screenshot - would it be more appealing to the eye if the text "Tab(s)" is removed from each menu entry and placed vertically in the bar to the left?

	Klaas Heidstra Reporter
	Comment 11 • 16 years ago

(In reply to comment #10)
> Looking on the screenshot - would it be more appealing to the eye if the text
> "Tab(s)" is removed from each menu entry and placed vertically in the bar to
> the left?

Maybe, but you should open a new bug for that. Because it doesn't directly have anything to do with the requested feature here. If yoy do open a new bug for that you could refer to the screenshot here.

	motohoss
	Comment 12 • 16 years ago

I entered a wishlist bug report in debian BTS before I found this report.
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501381
thank you

	eyal gruss
	Comment 13 • 16 years ago

since F5 = refresh
and middle-click/ctrl-click on refresh = duplicate tab (with Bug 448546)
perhaps the shortcut should be: ctrl-F5 ?

	Klaas Heidstra Reporter
	Comment 14 • 16 years ago

(In reply to comment #13)
> since F5 = refresh
> and middle-click/ctrl-click on refresh = duplicate tab (with Bug 448546)
> perhaps the shortcut should be: ctrl-F5 ?

Ctrl+F5 is for reloading the page bypassing cache, so that's not an option.

Now that Bug 225680 is resolved using a different approach, this bug has to be done in another way. This means the current patch can't be used anymore.

	Axel Hecht [:Pike]
	Comment 15 • 16 years ago

What would an updated patch look like over here?

It'd be good to know on whether we intend to go down this route here, or if taking bug 482450 makes any sense.

Beltzner, UI goddess of ours, mind making the call here?

	Mike Connor [:mconnor]
	Comment 16 • 16 years ago

Comment on attachment 339244 [details]
screenshot with patch v2 applied

Some obvious things wrong here:

* don't use l as an accesskey, it's really not easy to tell what it is.  Why not use D, which is most obvious?
* Don't show keyboard shortcuts in context menus.  Every interface guideline we care about (and more we don't) universally say "don't do this"
* What about the detach action, which this seems to replace?

	klonos
	Comment 17 • 16 years ago

lots of people using tab mix plus or similar extensions already have the commands 'duplicate tab' and 'duplicate to new window' available. So perhaps we should use the term duplicate instead of clone?

	Dave Garrett
	Comment 18 • 16 years ago

klonos: Yes, that's one of the reasons why I said as much in comment 2 and it was subsequently changed. The word "duplicate" is already used in the most recent patch. (also see screenshot attachment 339244 [details]) To make this more clear I guess I'll update the bug title.

	cbolin
	Comment 20 • 15 years ago

This functionality has been in other browsers for a long time.  It is in 3.5x (maybe earlier) if you drag and drop a tab to a blank space while holding CTRL (although it doesn't work in OSX this way)

Why isn't it added to the main trunk?  This is already in the browser as shipped just not exposed in the menu this way.

Please add it?  No bloat, common functionality across several other browsers, useful and already there but exposed a different way.

	cbolin
	Comment 21 • 15 years ago

One more comment.  IE and Opera have "Duplicate Tab" built in as a popup item for tabs.  There are a number of extensions that add this also.

	eyal gruss
	Comment 22 • 15 years ago

as in bug 539594, duplicate tabs should open next to the current tab.
can this be landed to expose this useful UI?

	Michael Monreal [:micmon]
	Comment 24 • 14 years ago

This sounds like a "because we can" thing that can (and has been) implemented easily by extensions. Personally I cannot think of a practical use for this and the tab context menu is already very crowded...

	Francesco Cosoleto
	Comment 25 • 14 years ago

I am an user of this duplicate function provided by a extension. Often you want to keep the current tab and to open a similar tab, for example an already seen page of this site in the history. You can do that quickly using a duplication menu item because you gets history duplicated as well. History duplicated helps also if you don't use it, due to improved accessibility and order.

Using this function happens to me a lot of times. Shortcuts aren't so user-friedly for some non expert users, so I support adding a menu utem.

	Staś Małolepszy :stas
	Comment 26 • 14 years ago

I find this useful for javascript links or links created with forms that I want to open in a new tab. It seems to be easily achievable with a jetpack, though.

	Dave Garrett
	Comment 27 • 14 years ago

The reasons for this are very simple:
1) Consistency across different vendors helps ease of use & migration
2) Keyboard & menu access is needed for everything, if just for the disabled

	Frank Yan (:fryn)
	Comment 28 • 14 years ago

This simply adds an item to the tab context menu labeled 'Duplicate Tab'.
In context, it looks like:
--------------------
  Duplicate Tab
  Make into App Tab
...
(See bug 593646 for related tab context menu item adjustments.)

We'll need this menu item once we implement animations for dragging-and-dropping tabs (bug 455694), since we'll likely no longer be able to support modifier+drag as a method of tab duplication. Plus, this helps with ux-discovery issues.

Discussing the addition of a keyboard shortcut will simply result in bikeshedding, so let's leave that to another bug.
Plus, I don't think a keyboard shortcut is even necessary in this case, especially since we plan to inherit history when modifier+clicking back/forward and when opening links in new tabs/windows.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 29 • 14 years ago

Comment on attachment 472220 [details] [diff] [review]
patch v3 (see comment #28 for UI)

I don't think the usage on this will be that high, but we do need to get it out of the way of the awesome tab dragging behaviors Frank is working on.

	eyal gruss
	Comment 30 • 14 years ago

does the duplicated tab open next to the current tab?

	Dão Gottwald [:dao]
	Comment 31 • 14 years ago

Note that this should be using duplicateTabIn(tab, "tab") when bug 448546 lands.

	Dão Gottwald [:dao]
	Comment 32 • 14 years ago

Also, Klaas was obviously waiting for bug 448546 to land. It seems pretty rude to steal this bug from him right now.

	Frank Yan (:fryn)
	Comment 33 • 14 years ago

(In reply to comment #32)

It wasn't obvious. His last patch was 2 years old and had ui-review-. Thank you for clarifying what wasn't explained in this bug. I'm happy to rewrite my patch to match his new method signatures or have him take this bug back.

	Klaas Heidstra Reporter
	Comment 34 • 14 years ago

(In reply to comment #33)
> (In reply to comment #32)
> 
> It wasn't obvious. His last patch was 2 years old and had ui-review-. Thank you
> for clarifying what wasn't explained in this bug. I'm happy to rewrite my patch
> to match his new method signatures or have him take this bug back.

As this is quite a trivial patch I have no problem with you writing a new patch using duplicateTabIn(tab, "tab"). Perhaps you could also add  the command key (ctrl+shift+c) back, as that part wasn't denied in the ui-review of comment #16?

	Frank Yan (:fryn)
	Comment 35 • 14 years ago

(In reply to comment #30)
> does the duplicated tab open next to the current tab?

Yes.

(In reply to comment #34)
> As this is quite a trivial patch I have no problem with you writing a new patch
> using duplicateTabIn(tab, "tab"). Perhaps you could also add  the command key
> (ctrl+shift+c) back, as that part wasn't denied in the ui-review of comment
> #16?

filed bug 594217, since i think it is more important that this get into firefox 4 (string freeze coming so soon!), even if we can't decide on a keyboard shortcut.

	Justin Dolske [:Dolske]
	Comment 36 • 14 years ago

This seems like a _really_ uncommon action to me, and not at all worth the context menu clutter. I would have WONTFIX this right off the bat, but frankly I'm a bit shocked that mconnor, beltzner, and faaborg have all touched this bug without doing so. Mass insanity, or am I missing some super-compelling use case here? :)

AIUI, fryn's current interest in this (as the ui-r+ in comment 29 alludes to) is that changes being considered for tab dragging may need to remove/repurpose alt/opt-drag, which is how this action is currently possible. I don't think moving this to a context menu is the right answer -- just kill it (this is what addons are for), or possibly use a different modifier.

	u88484
	Comment 37 • 14 years ago

(In reply to comment #36)
> This seems like a _really_ uncommon action to me, and not at all worth the
> context menu clutter. I would have WONTFIX this right off the bat, but frankly
> I'm a bit shocked that mconnor, beltzner, and faaborg have all touched this bug
> without doing so. Mass insanity, or am I missing some super-compelling use case
> here? :)
> 

I completely agree!  No one has even give specific examples on why this is needed.  I can't think of one reason why I would want or need to duplicate a tab and have never even though about doing so before.  Plus adding an extra (I'm sure to be barely used) option to the tab context menu is going to clutter it even more after the little bit of cleanup that has happened in the menu recently.

	u88484
	Comment 38 • 14 years ago

I found two add-ons that do this and the first isn't supported anymore since Firefox 3.1.  The second add-on only has 11,209 downloads.  <sarcasm>That figure alone is enough argument for needing this option</sarcasm>

	Frank Yan (:fryn)
	Comment 39 • 14 years ago

Dolske understands me correctly. I'm not arguing for tab duplication to be a built-in feature in Firefox, but if it has enough value to be one, it ought to be discoverable, and the tab context menu does much better than ctrl+drag (or opt+drag on OS X). Tab drag-and-drop animations will also require removing existing modifier+drag shortcuts.

(In reply to comment #38)
> I found two add-ons that do this and the first isn't supported anymore since
> Firefox 3.1.  The second add-on only has 11,209 downloads.  <sarcasm>That
> figure alone is enough argument for needing this option</sarcasm>

This point is a logical fallacy. There are many add-ons that implement this feature as part of their feature sets. Also, many Firefox features were, at their time of creation, completely new or were similar to very obscure add-ons.

	eyal gruss
	Comment 40 • 14 years ago

this could alternatively be solved by bug 593673 - middle click on "reload tab" in tab context menu to duplicate tab

	u88484
	Comment 41 • 14 years ago

(In reply to comment #39)
> Dolske understands me correctly. I'm not arguing for tab duplication to be a
> built-in feature in Firefox, but if it has enough value to be one, it ought to
> be discoverable, and the tab context menu does much better than ctrl+drag (or
> opt+drag on OS X). Tab drag-and-drop animations will also require removing
> existing modifier+drag shortcuts.
> 

There still isn't convincing use cases described here that makes this bug worth fixing and thus further cluttering the tab context menu with another very seldom used function.

> (In reply to comment #38)
> > I found two add-ons that do this and the first isn't supported anymore since
> > Firefox 3.1.  The second add-on only has 11,209 downloads.  <sarcasm>That
> > figure alone is enough argument for needing this option</sarcasm>
> 
> This point is a logical fallacy. There are many add-ons that implement this
> feature as part of their feature sets. Also, many Firefox features were, at
> their time of creation, completely new or were similar to very obscure add-ons.

Very true but a lot of those were because of the extension developer thinking out of the box and the extension was found to be very useful for the mass, not a specific type of user, whoever that may be, but I'm betting not grandma and grandpa or the general end-user.

	Dave Garrett
	Comment 42 • 14 years ago

In reply to any advanced users who don't see the need for this: you already know it's there. The ONLY way a normal user is going to ever find out this feature really exists is to see it in the standard context menu for a tab. We do not expect users to rely on digging through help docs to find a feature you don't yet know exists and might need.

The second reason for this bug, as filed, was the need for a keyboard shortcut, which was moved to another dependent bug. There are obvious usability and accessibility reasons to add this. Not everyone does use or can use a mouse for everything.

These two points should apply to every single built-in feature in Firefox that is not inherently mouse requiring. The fact that the tab duplication feature was snuck in with an incantation was frankly quite wrong. (though I really do like the feature, and believe it warrants built-in status)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 43 • 14 years ago

The only reason I can see for taking this is to get "parity" with other browsers (see software whiteboard).

The use cases for this are all pretty weak and developer centric, IMO, I'd support WONTFIX or WILLFIXBYJETPACKOKLOL!

	u88484
	Comment 44 • 14 years ago

(In reply to comment #42)
> In reply to any advanced users who don't see the need for this: you already
> know it's there. The ONLY way a normal user is going to ever find out this
> feature really exists is to see it in the standard context menu for a tab. We
> do not expect users to rely on digging through help docs to find a feature you
> don't yet know exists and might need.

So expose it just because we can?  I really didn't know this feature existed and now that I do, it doesn't change my workflow or current thinking.  Your argument has been tried with many a features that aren't exposed in the top level UI (yeah I know context menus aren't top level UI) and I can safely state that most have not received UI for the reasons that your argued.

I will say that I can't think of a better way of exposing this feature but that is probably because I have no need to use it and neither do general end-users so I can't think of how I'd like to use it if I needed to.

You could help your argument out by stating actual real world use cases for end-users like grandma and grandpa.  Give at least some type of example because I still can't think of one.

(In reply to comment #43)
> The only reason I can see for taking this is to get "parity" with other
> browsers (see software whiteboard).
> 
> The use cases for this are all pretty weak and developer centric, IMO, I'd
> support WONTFIX or WILLFIXBYJETPACKOKLOL!

Who's going to make the final call?

	cbolin
	Comment 45 • 14 years ago

This discussion seems like a bunch of developers who don't use a feature and then say it isn't useful.  Why does EVERY other browser have it?

Want a very compelling use case that would make better discover-ability useful?

Use an online app - say gmail.  Now while typing a message say you want to look up a previous message to retrieve some text or information to use.  I can refer back and forth between two views of the same app.

And drag and drop duplication doesn't even work reliably on my mac and is NOT intuitive at all.  Drag and drop to duplicate?

And as stated above MANY rollup addons have this feature included.  Saying stand alone addons are dead or not used is a useless argument.

	cbolin
	Comment 46 • 14 years ago

This discussion seems like a bunch of developers who don't use a feature and then say it isn't useful.  Why does EVERY other browser have it?

Want a very compelling use case that would make better discover-ability useful?

Use an online app - say gmail.  Now while typing a message say you want to look up a previous message to retrieve some text or information to use.  My choice is to close the editing I have done in the current window or reload, relogin to the same website.  Duplicating tabs means I can refer back and forth between two views of the same app.

And drag and drop duplication doesn't even work reliably on my mac and is NOT intuitive at all.  Drag and drop to duplicate?

And as stated above MANY rollup addons have this feature included.  Saying stand alone addons are dead or not used is a useless argument.

	Justin Dolske [:Dolske]
	Comment 47 • 14 years ago

Checked with limi, this is indeed not wanted. See comment 36 and 43.

We don't implement things just because other browsers do; everything gets considered on its merits, and the case for implementing this is weak.

	Francesco Cosoleto
	Comment 48 • 14 years ago

I think those developers comments aren't strong. "View Source" menu item is really non common and developer centric, but it's there. Some functions can be even getting poorly used but be simple, clear, immediate and helpful when applied. I think "Duplicate" deserves be included in this category.

For many reasons users may wish to duplicate a tab (even to edit the URL partially only for example, or to examine a long page in two different areas, or to re-open the previous page without closing the current one, and so on...). So, they have to perform some actions to do that which are resulting a bit frustrating compared to this simpler alternative. I see the problems related in adding a new menu item, but the benefit-cost ratio is in my opinion for adding it.

	Dave Garrett
	Comment 49 • 14 years ago

(In reply to comment #47)
> We don't implement things just because other browsers do

Sure we do, all the time, and they do too. (not that I'm really against the WONTFIX here, but every browser has borrowed good ideas from every other one, and rightly so)

> Checked with limi, this is indeed not wanted. See comment 36 and 43.

If we're going this far to reduce menu clutter, so be it. Bug 448546 should be helpful enough to be a better way to do this than the ctrl+drag method.

What about mouseless people? Is bug 594217 still FIXable?

	cbolin
	Comment 50 • 14 years ago

(In reply to comment #47)
> Checked with limi, this is indeed not wanted. See comment 36 and 43.
> 
> We don't implement things just because other browsers do; everything gets
> considered on its merits, and the case for implementing this is weak.

So you got use cases in the past few posts - but you don't agree with those.

Every other browser has it for a reason, even if you don't agree.  FF nor any other browser implements features because others do (cough)

I'm done with the conversation.  Thanks for deciding for everyone what is useful.   Clearly there are more important things to do to get back to parity with the just over a year-old Chromium project.

	techtonik
	Comment 51 • 14 years ago

Yea, Chrome rulez. But it doesn't have a duplicate tab shortcut though - only menu item.

	heraldo
	Comment 52 • 14 years ago

typical use cases: 

1. Log in to a forum like eg. mozillazine.org and read some thread
2. Hit the "post reply" button on page 7
3. Go to page 5 in that thread as you want to reread a post there while replying

1. Browse a web shop
2. Pick up some items and go to the checkout
3. Go back to the web shop to look at something else or recheck what you have added to your cart without leaving the checkout page

	heraldo
	Comment 53 • 14 years ago

Also I am impressed by the ignorance shown by the devs here. "The Back button is used far more often than any other navigation element"(1). Most users go back in tab history a lot, but as the use case above shows, in order not to jeopardise progress made in a tab, duplicating the tab solves the issue.
Has anybody in the UX team commented in this bug?


(1) http://blog.mozilla.com/metrics/2010/07/01/firefox-main-window-study-a-heatmap-visualization/

	motohoss
	Comment 54 • 14 years ago

I do quite a bit of this( Comment 52 and 53) in comparing different versions of websites(during live updates and in doing research. I am currently using an outdated version of a browser( and the XUL stuff that goes with) that has the feature in the UI. I sacrifice the advantages of what some developers are referring to as parity. What I am really losing is the other good stuff in FF(moz) that has came about since I reported (albeit incorrectly) a bug in iceweasel(1). All parity aside it only makes sense to have this feature where grandma and grandpa can use it if they want to(and easily find that it even exists)... I have pointed this feature out(in my old version) to a number of folks I know and they use other browsers(that have this) because of it. If I could just find out how to clone/duplicate/replicate a tab and keep it's history in the current version that would be helpful as well. I do appreciate the dev(s)'s time and efforts; Regarding this as 'won't fix' seems 'cruel and unusual punishment' for a crime that hasn't been committed. ;-)'vbg'

(1)http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501381 

(In reply to comment #53)
> Also I am impressed by the ignorance shown by the devs here. "The Back button
> is used far more often than any other navigation element"(1). Most users go
> back in tab history a lot, but as the use case above shows, in order not to
> jeopardise progress made in a tab, duplicating the tab solves the issue.
> Has anybody in the UX team commented in this bug?
> 
> 
> (1)
> http://blog.mozilla.com/metrics/2010/07/01/firefox-main-window-study-a-heatmap-visualization/

	u88484
	Comment 55 • 14 years ago

(In reply to comment #53)
> Also I am impressed by the ignorance shown by the devs here. "The Back button
> is used far more often than any other navigation element"(1). Most users go
> back in tab history a lot, but as the use case above shows, in order not to
> jeopardise progress made in a tab, duplicating the tab solves the issue.
> Has anybody in the UX team commented in this bug?
> 
> 
> (1)
> http://blog.mozilla.com/metrics/2010/07/01/firefox-main-window-study-a-heatmap-visualization/

Ctrl+click/middle-clicking the back/forward buttons opens in a new window with all the relevant history.

This bug has been resolved WONTFIX so take any further discussion to the newsgroups.

	cbolin
	Comment 56 • 14 years ago

it says don't post here as a decision has already been made despite several valid use cases and the fact that every other browser sees it as useful.

Last night I went to imdb to look up a movie.  I wanted to read the page, but found an actor I wanted to view.  I duplicated the tab (using Chrome) and then found I wanted to drill down and read several links on the actor's page.  I then closed the actor tab and continued reading the movie tab.

Sure there are other ways of doing this... but none as easy.  None as prevalent in UI as in other browsers.
CTRL+click is discoverable?  Documented?  ugh.

Too bad a few people decide what is and isn't useful.  Guess that is why browsers change usage percentage every so often.   Even if this isn't a good idea, one guy made the decision.  And there are many, many examples in bugzilla where this is true.

Maybe you should let users vote on their priorities in an easy to access/use page instead of debating in a defect database or forums that are often not read/ignored or even easy to follow.

Don't listen to the customer...  I love FF.  I love it less and less over time.

	heraldo
	Comment 57 • 14 years ago

Funny enough, a similar enhancement was just added to Firefox, Bug 492544. A dupe of that bug was WONTFIX'ed, see https://bugzilla.mozilla.org/show_bug.cgi?id=216667#c15

	u88484
	Comment 58 • 14 years ago

(In reply to comment #57)
> Funny enough, a similar enhancement was just added to Firefox, Bug 492544. A
> dupe of that bug was WONTFIX'ed, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=216667#c15

Those were added to the location bar and the search bar context menus, not the tab context menus.  Plus, that feature has a heck of a lot more use cases that actually make sense for everyone.

	heraldo
	Comment 59 • 14 years ago

I should have been more clear, I meant similar as in a context menu item for parity with the other browsers. Well, it took 7 years to implement paste and go, and as seen in the comment I linked to, that feature didn't make sense to Mike Beltzner either.

Current state is that you can dupe a tab by Ctrl + drag which is not discoverable and more cumbersome than clicking a context menu item or using a keyboard shortcut.

	Dave Garrett
	Comment 60 • 14 years ago

(In reply to comment #59)
> Current state is that you can dupe a tab by Ctrl + drag which is not
> discoverable and more cumbersome than clicking a context menu item or using a
> keyboard shortcut.

Yep, that sucked. The new method for Firefox 4.0, however, is much better. Cloning can be done by ctrl+clicking on refresh as if you just wanted to open that "link" in its own tab. Much nicer. You can also do this for back/forward. (see bug 448546)

	Carlos Alén Silva
	Comment 61 • 14 years ago

(In reply to comment #60)

Ctrl+clicking/middle-clicking on refresh seems to work here on Fx 3.6.x. There are several buttons and menu options that work with middle-click.

----

Suggestion for the discoverability issue: Modify the Refresh button tooltip to read something like "Click to reload current tab. Middle-click to clone current tab".

	eyal gruss
	Comment 62 • 14 years ago

i suggested bug 593673 - middle click on "reload tab" in tab context menu should duplicate tab

	Lars Petersen
	Comment 63 • 14 years ago

Status: RESOLVED
resolved as WONTFIX 

Really? This is very odd. CTRL+drag is not very intuitive at all. Firefox *really* needs a "Duplicate" tab context-menu item. I use this feature almost every day. Middle-clicking reload tab is also non-intuitive.

	heraldo
	Comment 65 • 13 years ago

To sum up, a user can duplicate current tab in Fx4 by:

1. Ctrl + click on the reload button (no tooltip)
2. Ctrl + drag the tab somewhere else on the tab bar (no tooltip)

Where is the discoverability? Please reconsider or at least add a tooltip to the reload button. Valid use cases have been presented here after it got wontfixed.

	techtonik
	Comment 66 • 13 years ago

How about opening new enhancement about mouseless tab duplication?

	Lars Petersen
	Comment 67 • 13 years ago

CTRL+whatever doesn't duplicate a tab. It opens a new tab with the address of the tab. Tab history is not duplicated. I use this very often.

	eyal gruss
	Comment 68 • 13 years ago

(In reply to comment #66)
> How about opening new enhancement about mouseless tab duplication?

unfortunately this was wont fixed as well, see bug 594217


(In reply to comment #67)
> CTRL+whatever doesn't duplicate a tab. It opens a new tab with the address of
> the tab. Tab history is not duplicated. I use this very often.

this was fixed in bug 448546, and now works on 4.0

	heraldo
	Comment 69 • 13 years ago

While middle-clicking, Bug 448546, is useful for mouse users, despite lacking discoverability, it is not useful for the growing crowd of touchpad users without a middle-click button. Now that the dragging animations landed we have Bug 675438 and Bug 676686. 11 year old Customizable menus Bug 57805 or the soon 12 year old Bug 18808 looks like duplicate tab fans best bet :P

	Richard Benton
	Comment 70 • 12 years ago

Well I think that it is time for a re-think on this matter.  Google Chrome (version 19.0.1084.56) has both "New Tab" and "Duplicate" included in the context menu when you right-click an existing tab.  The duplicate does include the history too, so for example if you type the word "test" in the google search page and duplicate the tab, the duplicated tab also includes "test" in it.

There are a LOT of users (like myself) who like to browse using only the mouse, not also the keyboard and need those functions.

Although there is a workaround using an Addon, Mozilla code should support these function by default. See my post here:

https://support.mozilla.org/en-US/questions/903583#answer-343306

	Haik Aftandilian [:haik]
	Comment 75 • 9 years ago

This is another request to reconsider adding this feature. Specifically, to add an option to duplicate a tab in the the tab's right-click menu. i.e., the menu you get when you right-click on the name of a tab. I use option-drag (on OS X) to duplicate tabs, but only found that method after doing an internet search. It's useful to me for the same reasons others have mentioned.

	Dave Garrett
	Comment 76 • 9 years ago

(In reply to Haik Aftandilian [:haik] from comment #75)
> This is another request to reconsider adding this feature. Specifically, to
> add an option to duplicate a tab in the the tab's right-click menu. i.e.,
> the menu you get when you right-click on the name of a tab. I use
> option-drag (on OS X) to duplicate tabs, but only found that method after
> doing an internet search. It's useful to me for the same reasons others have
> mentioned.

I suggest you directly contact whomever is currently in charge of making UI/UX changes like this. I very much agree that this needs to be exposed in the menu properly; its current discovery is non-existent. I'm not going to reopen this myself, though, as that does nothing unless those in the decision making process here will actually do something with it.

	Kestrel
	Comment 77 • 9 years ago

Reopening would at least make this bug more visible.

	heraldo
	Comment 78 • 7 years ago

Reopening as an enhancement. Please take into account that all other major and minor browsers in the parity list have this feature, in Chrome this tab context menu item was the most used item based on recent data:

Quoting (discussion about removing "Close other tabs" and "Close tabs to the right":

"Since we're debating removing this to free up space on the tab context menu, we really need to look at the relative usage of the context menu items.

- Duplicate: 23.21%
- Reload: 22.74%
- Pin / Unpin tab: 13.12%
- Close tab: 9.68%
- Reopen closed tab: 8.92%
- New tab: 6.63%
- Close tabs to the right: 6.06%
- Mute tab: 5.38%
- Close other tabs: 2.20%
- Unmute tab: 1.41%
- Bookmark all tabs: 0.64%
"
https://bugs.chromium.org/p/chromium/issues/detail?id=515930#c7 

Firefox already has this feature, it just needs to be exposed in the relevant UI element, which most likely is a tab context menu.

	:Gijs (he/him)
	Comment 79 • 7 years ago

Ni Stephen about whether we need to revive this based on comment #78.

	Stephen Horlander [:shorlander]
	Comment 80 • 7 years ago

Even though it's going to make that menu even more populated I think it makes sense to expose this in the context menu. Ctrl/Cmd + Drag is pretty hidden and awkward.

	IdmFoundInHim
	Comment 82 • 7 years ago

> +1 for reconsidering this feature. I installed an add-on for it and I use it
> frequently when I need to "make a snapshot" of my browsing history, or when
> I need to modify the current url and keep the original at the same time.

I cannot find an extension using WebExtensions (compatible with 57+) that serves the purpose of duplicating tabs.  I am open to suggestions.(In reply to petr.pavel from comment #74)

	Richard Benton
	Comment 84 • 7 years ago

OK so I was incorrect.  In my last comment I talked about "Tab Mix Plus 0.5.0.4" being my current workaround for the lack of "Duplicate" tab functionality in the standard code, but did not appreciate that Firefox Addon Technology was changing "Starting in Firefox 57", which I understand is happening in November 2017.

This morning, on opening Waterfox, I received this page from Tab Mix Plus, saying that their code needs to be completely rewritten to support the upcoming version:

http://tabmixplus.org/version_update2.htm?version=0.5.0.4

(which apparently, may or may not happen, depending on donations)

So this makes the getting the core code right to provide a Duplicate context menu item in this "enhancement" all the more vital (at least to some of us).

	dalley
	Comment 85 • 7 years ago

TenCapsule.com, A few webextensions addons exist for this functionality (e.g. https://addons.mozilla.org/en-US/firefox/addon/duplicate-tab-shortcut/) but it's still not an ideal solution.  Context menu entries provided by webextensions addons are placed at the very bottom of the context menu.  Going by the data provided in comment #78, that's a terribly inconvenient location for an action that is used more than any other context menu action.

Current legacy addons usually place "Duplicate Tab" right below "Reload Tab", which personally feels like the most natural place to put it.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 86 • 7 years ago

There seem to be two separate topics here:

1) Adding the feature to Firefox
2) Extending the WE API to allow for the functionality to be achieved with WE

This bug is about (1). Please, try to not add content that is not directly related to it.
I understand that most of content about (2) is added here to justify why (1) is needed at all, but I think it would be more productive to file a bug for (2).

It seems that wrt. (2) there is already a feature that should make the item show up in the "tab" related items context: https://github.com/stefansundin/duplicate-tab/blob/master/firefox/background.js#L22

Maybe additionally there could be a best-effort parameter that allows adding the item at the top or the bottom of the context, so that Duplicate tab can be added at the top if that's what the users want.
Either way, I recommend filing a separate bug about (2) and stick to (1) in this bug.

	Tom S [:evilpie]
	Comment 87 • 7 years ago

So I see the 7 years old patch has "Duplicate Tab" under "Reload all tabs". I think it would be better to move this further up.  Chrome has it has the third item: 1. New Tab 2. Reload 3. Duplicate. I think for us after Mute Tab would make sense, or before  Pin Tab, depending on how we want to split the menu with those separators. Additionally the access key "D" is sadly already taken by "Send Tab to Device".

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 89 • 7 years ago

Based on comment 80, I updated the patch to central.

Notice - I'm not in a position to make any decisions here, just am willing to drive the patch to landing if the decision is made by the stakeholders.

	bbell
	Comment 90 • 7 years ago

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #89)
> Based on comment 80, I updated the patch to central.
> 
> Notice - I'm not in a position to make any decisions here, just am willing
> to drive the patch to landing if the decision is made by the stakeholders.

We have a consensus around adding "Duplicate Tab" to the tab contextual menu. 

If you have the cycles, could you please go ahead and add it? 


TLDR: https://cl.ly/061t0L3d3H2h/Do-it-Bridge.gif

	bbell
	Comment 91 • 7 years ago

Here's a Mockup of where to add it.

	IdmFoundInHim
	Comment 92 • 7 years ago

Did we reach a consensus on where to position the option in the menu?  The latest comment on this topic suggested "after Mute Tab would make sense, or before  Pin Tab, depending on how we want to split the menu with those separators."  I would agree with the latter, seeing as the option modifies the tabbed browser (by adding a tab) as opposed to modifing the page content as reload or mute do.
Also, is Firefox 57 our target or are we shooting for getting this into a 55 or 56 release?

	bbell
	Comment 93 • 7 years ago

(In reply to TenCapsule.com from comment #92)
> Did we reach a consensus on where to position the option in the menu? 

You may not have seen the mockup in comment #93, but placing "Duplicate Tab" right after "Pin Tab" in the second grouping makes sense. 

> Also, is Firefox 57 our target or are we shooting for getting this into a 55
> or 56 release?

Firefox 57 is a reasonable target because this addition would fit right in with the other changes we've made to the product, but feel free to push this out the door earlier, if doable.

	Francesco Lodolo [:flod]
	Comment 94 • 7 years ago
mozreview-review

Comment on attachment 8902915 [details]
Bug 455722 - Add context menu item to duplicate (clone) tab.

https://reviewboard.mozilla.org/r/174632/#review179856

::: browser/locales/en-US/chrome/browser/browser.dtd:26
(Diff revision 1)
>  <!-- Tab context menu -->
>  <!ENTITY  reloadTab.label                    "Reload Tab">
>  <!ENTITY  reloadTab.accesskey                "R">
>  <!ENTITY  reloadAllTabs.label                "Reload All Tabs">
>  <!ENTITY  reloadAllTabs.accesskey            "A">
> +<!ENTITY  duplicateTab.label                 "Duplicate Tab">

Please add a comment explaining that's a command to duplicate a tab (i.e. that's a verb, not an adjective).

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 96 • 7 years ago

Thank you :bbell and :flod!

I updated the patch and verified that it works.

The remaining issue is that the key (D) is already used by "Send to Device" so we either have to change that, or pick a different one for this.
My pick would be to change the accesskey for "Send to Device", but I'd prefer for :dao or :bbell to decide.

	bbell
	Comment 97 • 7 years ago

> My pick would be to change the accesskey for "Send to Device", but I'd
> prefer for :dao or :bbell to decide.

I concur.  Assign "D" to Duplicate, and "S" to Send to Device.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 98 • 7 years ago

That's almost going to just work.

There are there "Send *" options - one for a tab, one for a link and one for a page context menu:

http://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#47

If I'm moving their access keys to "S", I believe it makes sense to move all three. And this will work for Tab and for Page.
Unfortunately, for Link, we already have "S" accesskey for "Search $engine for 'query'".

Which accesskey I should switch that to? :)

	bbell
	Comment 99 • 7 years ago

Would removing Send To Device from the tab contextual menu help? Now that Send to Device has a prime position in Page Action Menu, its presence in the Tab Contextual Menu is no longer required. 

For now, feel free to use any of the following options.  

1. E
2. V
3. N

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 100 • 7 years ago

> Would removing Send To Device from the tab contextual menu help?

Only if we removed it from all three types of context menus. Is that what you suggest?

> For now, feel free to use any of the following options.  

So:

 - Duplicate Tab (D)
 - Send to ... (S)
 - Search {engine} for "{query}" (E)

?

	bbell
	Comment 101 • 7 years ago

> Only if we removed it from all three types of context menus. Is that what
> you suggest?

When these contextual menus get a cleaning pass, Send to devices is going to be the most likely candidate for removal. But we can do that another time. 

> So:
> 
>  - Duplicate Tab (D)
>  - Send to ... (S)
>  - Search {engine} for "{query}" (E)
> 
> ?

Since Send to Device is the most likely to be depricated, it's the one that should get the weirder access keys. I would Keep whatever Search has already, and pick for Send to Device any available letter that coincides with a letter in its name. 

- Duplicate Tab (D)
- Send to ... (E)
- Search {engine} for "{query}" (S)

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 103 • 7 years ago

Thank you!

Patch updated to your feedback and ready for review.

	Francesco Lodolo [:flod]
	Comment 104 • 7 years ago
mozreview-review

Comment on attachment 8902915 [details]
Bug 455722 - Add context menu item to duplicate (clone) tab.

https://reviewboard.mozilla.org/r/174632/#review180130

::: browser/locales/en-US/chrome/browser/browser.dtd:48
(Diff revision 3)
>  <!ENTITY  pinTab.label                       "Pin Tab">
>  <!ENTITY  pinTab.accesskey                   "P">
>  <!ENTITY  unpinTab.label                     "Unpin Tab">
>  <!ENTITY  unpinTab.accesskey                 "b">
>  <!ENTITY  sendTabToDevice.label              "Send Tab to Device">
> -<!ENTITY  sendTabToDevice.accesskey          "D">
> +<!ENTITY  sendTabToDevice.accesskey2         "E">

Do not rename keys when changing access keys for English. Each locale needs to find their own set of non conflicting access keys.

	Dão Gottwald [:dao]
	Comment 106 • 7 years ago
mozreview-review

Comment on attachment 8902915 [details]
Bug 455722 - Add context menu item to duplicate (clone) tab.

https://reviewboard.mozilla.org/r/174632/#review180346

::: browser/locales/en-US/chrome/browser/browser.dtd:52
(Diff revision 4)
>  <!ENTITY  sendTabToDevice.label              "Send Tab to Device">
> -<!ENTITY  sendTabToDevice.accesskey          "D">
> +<!ENTITY  sendTabToDevice.accesskey          "E">
>  <!ENTITY  sendPageToDevice.label             "Send Page to Device">
> -<!ENTITY  sendPageToDevice.accesskey         "D">
> +<!ENTITY  sendPageToDevice.accesskey         "E">
>  <!ENTITY  sendLinkToDevice.label             "Send Link to Device">
> -<!ENTITY  sendLinkToDevice.accesskey         "D">
> +<!ENTITY  sendLinkToDevice.accesskey         "E">

lowercase "e" in all three cases

Thanks!

	Pulsebot
	Comment 108 • 7 years ago

Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/38f284a549c5
Add context menu item to duplicate (clone) tab. r=dao

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 109 • 7 years ago

Backed out for failing mochitest-clipboard browser/base/content/test/general/browser_contextmenu.js: menuitem context-viewpartialsource-selection has same accesskey as context-sendlinktodevice:

https://hg.mozilla.org/integration/autoland/rev/af5b5368de5c65a629efa479378f9d19e392571c

Push which ran failing tests: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=10bb5830a5b218241b9831826baea0e38dfcc7de&filter-resultStatus=testfailed&filter-resultStatus=runnable&filter-resultStatus=busted&filter-resultStatus=usercancel
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=127696195&repo=autoland

02:56:27     INFO - TEST-PASS | browser/base/content/test/general/browser_contextmenu.js | menuitem context-viewpartialsource-selection has an access key - 
02:56:27     INFO - Buffered messages finished
02:56:27     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_contextmenu.js | menuitem context-viewpartialsource-selection has same accesskey as context-sendlinktodevice - 
02:56:27     INFO - Stack trace:
02:56:27     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/contextmenu_common.js:getVisibleMenuItems:78
02:56:27     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/contextmenu_common.js:checkMenu:195
02:56:27     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/contextmenu_common.js:checkContextMenu:141

	Dão Gottwald [:dao]
	Comment 110 • 7 years ago

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #98)
> That's almost going to just work.
> 
> There are there "Send *" options - one for a tab, one for a link and one for
> a page context menu:
> 
> http://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/
> browser/browser.dtd#47
> 
> If I'm moving their access keys to "S", I believe it makes sense to move all
> three. And this will work for Tab and for Page.
> Unfortunately, for Link, we already have "S" accesskey for "Search $engine
> for 'query'".

Looks like things are a bit more complex than that. Unless you find a reasonable way to resolve the conflicts in the content context menu, I'd suggest changing only the access key in the tab context menu and leaving the rest as is.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 112 • 7 years ago

Sorry Aryx! I didn't notice there's a separate bunch of context options for selection only.

I changed the accesskey for "Sent to" from "e" to "n" (second option in comment 99 from :bbell) and it seems to not conflict with anything.
I'll wait for try before relanding.

	Pulsebot
	Comment 113 • 7 years ago

Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c49c61106fe2
Add context menu item to duplicate (clone) tab. r=dao

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 114 • 7 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/c49c61106fe2

	IdmFoundInHim
	Comment 115 • 7 years ago

Thank you for getting this added to the UI!  Since many of us have noticed the crowded tab context menu, I have proposed a solution in Bug 1394125 that you may want to check out.

I would also like to point out that discussion over this feature has been going on for 10 years.  Back then, George W. Bush was president, Nightly was called Minefield, and releases did not come out every six weeks.  Special thanks to heraldo for the Chrome stats that made everyone reconsider this; bbell for voicing our decision; and aryx, gandalf, and dao for putting together the patch.  Just remember everyone, patience and persistence.

	Richard Benton
	Comment 116 • 7 years ago

(In reply to TenCapsule.com from comment #115)
> Thank you for getting this added to the UI!  Since many of us have noticed
> the crowded tab context menu, I have proposed a solution in Bug 1394125 that
> you may want to check out.
> 
> I would also like to point out that discussion over this feature has been
> going on for 10 years.  Back then, George W. Bush was president, Nightly was
> called Minefield, and releases did not come out every six weeks.  Special
> thanks to heraldo for the Chrome stats that made everyone reconsider this;
> bbell for voicing our decision; and aryx, gandalf, and dao for putting
> together the patch.  Just remember everyone, patience and persistence.

I would also like to express my grateful thanks to all involved in implementing this feature!  I am writing this using Firefox Nightly, 57.0a1 (2017-09-02) (64-bit), having just tried Duplicate.  Thank you again!

	eyal gruss
	Comment 118 • 7 years ago

i reopened https://bugzilla.mozilla.org/show_bug.cgi?id=594217 - to add a keyboard shortcut

	Sajedul Islam
	Comment 119 • 7 years ago

This bug was about "adding context menu item to duplicate (clone) tab" and I have seen the feature being implemented with latest Beta in Windows 10, 64-bit !


Build ID   : 20171005195903
User Agent : Mozilla/5.0 (Windows NT 10.0; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0

	Mohammad Maruf Rahman
	Comment 120 • 7 years ago

This bug was about "adding context menu item to duplicate (clone) tab" and I have seen the feature being implemented with latest Beta in Ubuntu 16.04 LTS!

Build ID   : 20171005195903
User Agent : Mozilla/5.0 (X11;Linuxx86_64; rv:57.0) Gecko/20100101 Firefox/57.0

[bugday-20171004]

	Sajedul Islam
	Comment 121 • 7 years ago

as par comment 119 & comment 120 , I am marking this bug as verified fixed.

	Worcester12345
	Comment 122 • 7 years ago

Will this now allow the Duplicate Tab extension located here work again?
http://twanno.mozdev.org/

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 123 • 7 years ago

The extension you listed is not a web extension, so it won't work in Mozilla 57+.

This provides a context menu item for duplicating a tab, so one feature of that extension is now part of Firefox.