Add context menu item to duplicate (clone) tab

VERIFIED FIXED in Firefox 57

Status

()

Firefox
Tabbed Browser
--
enhancement
VERIFIED FIXED
9 years ago
a month ago

People

(Reporter: Klaas Heidstra, Assigned: gandalf)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {uiwanted, ux-discovery})

Trunk
Firefox 57
uiwanted, ux-discovery
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.6 -

Firefox Tracking Flags

(firefox57 verified)

Details

(Whiteboard: [parity-ie][parity-chrome][parity-opera][parity-edge])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

9 years ago
Created attachment 339070 [details] [diff] [review]
patch - add a clone tab to the tab context menu

This adds the clone tab item and the command key that were first in the patch in bug 225680.
Attachment #339070 - Flags: ui-review?(beltzner)
Attachment #339070 - Flags: review?(dao)
Flags: wanted-firefox3.1?
(Reporter)

Updated

9 years ago
Whiteboard: [225680 must land first] [parity-ie] [parity-chrome] [parity-opera] [has patch] [needs review beltzner]
(Reporter)

Comment 1

9 years ago
Created attachment 339072 [details]
Screenshot with the patch applied
Attachment #339072 - Flags: ui-review?(beltzner)

Comment 2

9 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.
(Reporter)

Updated

9 years ago
Duplicate of this bug: 433518
(Reporter)

Updated

9 years ago
Duplicate of this bug: 432094
(Reporter)

Comment 5

9 years ago
Created attachment 339084 [details] [diff] [review]
patch v2 - useDuplicate Tab instead of Clone Tab

(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).
Attachment #339070 - Attachment is obsolete: true
Attachment #339084 - Flags: ui-review?(beltzner)
Attachment #339070 - Flags: ui-review?(beltzner)
Attachment #339070 - Flags: review?(dao)

Comment 6

9 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.
(Reporter)

Comment 7

9 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.

Comment 8

9 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.

Updated

9 years ago
Hardware: PC → All
(Reporter)

Comment 9

9 years ago
Created attachment 339244 [details]
screenshot with patch v2 applied

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
Attachment #339072 - Attachment is obsolete: true
Attachment #339244 - Flags: ui-review?(beltzner)
Attachment #339072 - Flags: ui-review?(beltzner)

Comment 10

9 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?
(Reporter)

Comment 11

9 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.

Comment 12

9 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

Comment 13

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

Updated

9 years ago
Attachment #339084 - Attachment is obsolete: true
Attachment #339084 - Flags: ui-review?(beltzner)
(Reporter)

Comment 14

9 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.

Comment 15

9 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?
Whiteboard: [225680 must land first] [parity-ie] [parity-chrome] [parity-opera] [has patch] [needs review beltzner] → [225680 must land first] [parity-ie] [parity-chrome] [parity-opera] [needs review beltzner]

Updated

9 years ago
Whiteboard: [225680 must land first] [parity-ie] [parity-chrome] [parity-opera] [needs review beltzner] → [parity-ie][parity-chrome][parity-opera][needs review beltzner]

Updated

9 years ago
Keywords: late-l10n

Updated

9 years ago
Attachment #339244 - Flags: ui-review?(beltzner) → ui-review-
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?

Comment 17

9 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?

Comment 18

9 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.
Summary: Add a clone tab menu item to the tab context menu, and a clone tab command key → Add duplicate (clone) tab context menu item and command hotkey

Updated

9 years ago
Keywords: late-l10n
Whiteboard: [parity-ie][parity-chrome][parity-opera][needs review beltzner] → [parity-ie][parity-chrome][parity-opera]

Updated

9 years ago
Flags: blocking-firefox3.6?

Updated

8 years ago
Duplicate of this bug: 509580

Comment 20

8 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.

Comment 21

8 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.
Flags: wanted-firefox3.5?
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
(Reporter)

Updated

8 years ago
Depends on: 448546

Comment 22

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

Updated

8 years ago
Duplicate of this bug: 559235

Updated

8 years ago
Blocks: 565512
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...

Comment 25

7 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.
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.

Comment 27

7 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

Comment 28

7 years ago
Created attachment 472220 [details] [diff] [review]
patch v3 (see comment #28 for UI)

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.
Assignee: klaas1988 → fryn
Attachment #339244 - Attachment is obsolete: true
Attachment #472220 - Flags: ui-review?(faaborg)
Attachment #472220 - Flags: review?(dao)

Updated

7 years ago
Blocks: 455694
No longer depends on: 448546, 225680
Keywords: ux-discovery
Summary: Add duplicate (clone) tab context menu item and command hotkey → Add duplicate (clone) tab context menu item
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.
Attachment #472220 - Flags: ui-review?(faaborg) → ui-review+

Updated

7 years ago
Summary: Add duplicate (clone) tab context menu item → Add context menu item to duplicate (clone) tab

Comment 30

7 years ago
does the duplicated tab open next to the current tab?

Updated

7 years ago
Attachment #472220 - Flags: review?(dao) → review?(dolske)
Note that this should be using duplicateTabIn(tab, "tab") when bug 448546 lands.
Also, Klaas was obviously waiting for bug 448546 to land. It seems pretty rude to steal this bug from him right now.

Comment 33

7 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.
Depends on: 448546

Updated

7 years ago
Attachment #472220 - Attachment is obsolete: true
Attachment #472220 - Flags: review?(dolske)
(Reporter)

Comment 34

7 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?

Updated

7 years ago
Blocks: 593673

Updated

7 years ago
Blocks: 594217

Comment 35

7 years ago
Created attachment 472861 [details] [diff] [review]
patch v4 [ui-r=faaborg]

(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.
Attachment #472861 - Flags: review?(dao)

Updated

7 years ago
Attachment #472861 - Attachment description: patch v2 [ui-r=faaborg] → patch v4 [ui-r=faaborg]

Updated

7 years ago
Attachment #472220 - Attachment description: patch (see comment #28 for UI) → patch v3 (see comment #28 for UI)

Updated

7 years ago
Attachment #472861 - Flags: review?(dao) → review+

Updated

7 years ago
Attachment #472861 - Flags: approval2.0?
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.

Comment 37

7 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.

Comment 38

7 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>

Comment 39

7 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.

Comment 40

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

Comment 41

7 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.

Comment 42

7 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)
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!

Comment 44

7 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?

Comment 45

7 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.

Comment 46

7 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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Attachment #472861 - Flags: approval2.0?

Comment 48

7 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.

Comment 49

7 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?

Comment 50

7 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.

Comment 51

7 years ago
Yea, Chrome rulez. But it doesn't have a duplicate tab shortcut though - only menu item.
(Reporter)

Updated

7 years ago
No longer blocks: 593673
(Reporter)

Updated

7 years ago
No longer blocks: 594217

Comment 52

7 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

Comment 53

7 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/

Comment 54

7 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/

Comment 55

7 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.

Comment 56

7 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.

Comment 57

7 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

Comment 58

7 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.

Comment 59

7 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.

Comment 60

7 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)

Comment 61

7 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".

Updated

7 years ago
Blocks: 594217

Comment 62

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

Updated

7 years ago
Assignee: fryn → nobody

Updated

7 years ago
No longer blocks: 455694

Comment 63

7 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.
Duplicate of this bug: 620581

Comment 65

7 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.

Comment 66

7 years ago
How about opening new enhancement about mouseless tab duplication?

Comment 67

7 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.

Comment 68

7 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

Comment 69

6 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

Comment 70

6 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

Updated

4 years ago
Duplicate of this bug: 958801
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (me-too)
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.

Comment 76

2 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.

Comment 77

2 years ago
Reopening would at least make this bug more visible.

Updated

8 months ago
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [parity-ie][parity-chrome][parity-opera] → [parity-ie][parity-chrome][parity-opera][parity-edge]

Comment 78

8 months 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.
Ni Stephen about whether we need to revive this based on comment #78.
Flags: needinfo?(shorlander)
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.
Flags: needinfo?(shorlander)
Comment hidden (me-too)

Comment 82

3 months 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)
Comment hidden (advocacy)

Comment 84

3 months 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).

Comment 85

3 months 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.
(Assignee)

Comment 86

3 months 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.
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".
(Assignee)

Updated

3 months ago
Assignee: nobody → gandalf
Status: REOPENED → ASSIGNED
Comment hidden (mozreview-request)
(Assignee)

Comment 89

3 months 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.

Comment 90

3 months 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

Comment 91

3 months ago
Created attachment 8902947 [details]
Mockup.png

Here's a Mockup of where to add it.

Comment 92

3 months 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?
Flags: needinfo?(bbell)

Comment 93

3 months 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.
Flags: needinfo?(bbell)
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).
Comment hidden (mozreview-request)
(Assignee)

Comment 96

3 months 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.
Flags: needinfo?(bbell)

Comment 97

3 months 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.
Flags: needinfo?(bbell)
(Assignee)

Comment 98

3 months 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? :)
Flags: needinfo?(bbell)

Comment 99

3 months 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
Flags: needinfo?(bbell)
(Assignee)

Comment 100

3 months 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)

?
Flags: needinfo?(bbell)

Comment 101

3 months 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)
Flags: needinfo?(bbell)
Comment hidden (mozreview-request)
(Assignee)

Comment 103

3 months ago
Thank you!

Patch updated to your feedback and ready for 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.
Comment hidden (mozreview-request)

Comment 106

3 months 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!
Attachment #8902915 - Flags: review?(dao+bmo) → review+
Comment hidden (mozreview-request)

Comment 108

3 months ago
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/38f284a549c5
Add context menu item to duplicate (clone) tab. r=dao
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
Flags: needinfo?(gandalf)
(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.
Comment hidden (mozreview-request)
(Assignee)

Comment 112

3 months 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.
Flags: needinfo?(gandalf)

Comment 113

3 months ago
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c49c61106fe2
Add context menu item to duplicate (clone) tab. r=dao
https://hg.mozilla.org/mozilla-central/rev/c49c61106fe2
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago3 months ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57

Comment 115

3 months 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.

Updated

3 months ago
Depends on: 1396375

Comment 116

3 months 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!
Duplicate of this bug: 1387756

Comment 118

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

Comment 119

a month 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
QA Whiteboard: [bugday-20171004]
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]

Comment 121

a month ago
as par comment 119 & comment 120 , I am marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
status-firefox57: fixed → verified

Comment 122

a month ago
Will this now allow the Duplicate Tab extension located here work again?
http://twanno.mozdev.org/
(Assignee)

Comment 123

a month 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.
You need to log in before you can comment on or make changes to this bug.