301888 - Bookmarks cut instead of opened in new tab from Bookmarks Toolbar Folder (shortcut key "t" in the right-click context menu is inconsistent with that of links)

Status: NEW

(Firefox :: Bookmarks & History, defect, P3)

Description

[Arman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

When right-clicking on a bookmark in the Bookmarks Toolbar Folder, a sub-menu
appears. Many options appear, including "Open in New Tab" and "Cut". The "Open
in New Tab" option can be activated by pressing the "w" key, and the "Delete"
option can be activated by pressing the "t" key.

This behavior is confusing because the "t" key is used to open HTML links in new
tabs. The "Cut" option should have some other activator, such as the "w" or "x"
keys.

Reproducible: Always

Steps to Reproduce:
1. Right-click on any bookmark in the Boomkars Toolbar Folder.
2. Press "t". Normally, since HTML links open in new tabs, one would expect the
same behavior.
3. The bookmark disappears.

Actual Results:  
After closer scriutny, I realized that the "t" stands for "Cut" in that context
menu and I pasted back the link.

Expected Results:  
It would be helpful if Firefox kept consistency in its menus. In this case,
right-click followed by "t" should open the bookmark in a new tab instead of
cutting it.

Comment 1

[Phil Ringnalda (:philor)]

*** Bug 326850 has been marked as a duplicate of this bug. ***

Comment 2

[zug_treno]

*** Bug 330361 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Fixed, branch and trunk (323812)

Comment 4

[Phil Ringnalda (:philor)]

*** Bug 338304 has been marked as a duplicate of this bug. ***

Comment 5

[Phil Ringnalda (:philor)]

No, it wasn't fixed by bug 323812 - that made "w" the "open in a new tab" accesskey, freeing "cut" from any competition for "t", putting Places in the same state 1.0.x was in when this bug was filed - this bug is asking for the accesskey to *be* "t" for "open in a new tab" on bookmarks just like it is on links, forcing "cut" to have a different accesskey for bookmarks than it has for text. wontfix, maybe, but not fixed.

Comment 6

[Phil Ringnalda (:philor)]

*** Bug 349938 has been marked as a duplicate of this bug. ***

Comment 7

[Phil Ringnalda (:philor)]

*** Bug 318706 has been marked as a duplicate of this bug. ***

Comment 8

[Majken Connor [:Kensie]]

While consistency is a good idea, these are access keys and not keyboard shortcuts.  Middle clicking, or ctrl+clicking on bookmarks and links have the same behavior, which is to open the link in a new tab.  I'd back a decision to wontfix, as a) as phil pointed out this would break "cut's" consistency and b) given the nature of access keys it'd be impossible to always have the same key for the same string no matter where it is.  That's what keyboard shortcuts are for.

Comment 9

[Oleg Smirnov]

Well, I would argue that having the same key do something constructive in one context and destructive in another context is an especially annoying inconsistency, so perhaps it merits extra attention. If anything, having an inconsistent "Cut" is the lesser of the two evils: how often do people "Cut" bookmarks anyway, as opposed to opening stuff in a new tab?

Comment 10

[brodders]

Just lost two more bookmarks to the dreaded Ctrl-T > delete-not-open feature.

Hey, I wanted them! I take it they are gone forever?

The issue here is that the user thinks there is a consistent MMI across products; a concept standard since the 1980's.

I like many have been trained to expect a single action per keystroke, regardless of context. Thus Ctrl-C, Ctrl-V, Ctrl-Z, Ctrl-F, Ctrl-P are the same in the vast majority of applications.

I really object to a DESTRUCTIVE keystroke overload.

Um, why is "Cut" not Ctrl-X, like in ...everything else?

Comment 11

[Oleg Smirnov]

If you realize your mistake quickly, you can paste the cut bookmark back in. If you've cut more than one, tough luck. I've been doing a lot of bookmark re-pasting the last few weeks...

Couldn't agree more, the destructive behaviour is a serious usability issue. Whether it affects you or not depends on your typing habits; when I use a proper keyboard/mouse it's never a problem, but working one-handed on a laptop, I tend to use the context menus a lot, and that's when it keeps biting me in the posterior.

Comment 12

[Majken Connor [:Kensie]]

the fact that holding down ctrl and hitting T still uses the access key gives me pause.  Ctrl + should only do what it should.  At the same time though once you're right clicking on it you're opening up the context menu and not actually focusing the object to apply keyboard shortcuts to it. I can't imagine it's much faster to right click and then switch to the keyboard shortcut.

Brodders I think what you really want to be doing is holding ctrl and clicking on the bookmark, you really don't seem to want anything to do with the context menu and rather want the shortcut to open in new tab, which is middle click or hold ctrl and left click.

Comment 13

[Mike Connor [:mconnor]]

As it stands, this seems to be a WONTFIX.  That said, based on a quick test with some native windows apps, Ctrl+<letter> should do nothing when a menu is open.

Comment 14

[Majken Connor [:Kensie]]

Bug 214922 for the bug tracking ctrl + letter

Comment 15

[Phil Ringnalda (:philor)]

*** Bug 355083 has been marked as a duplicate of this bug. ***

Comment 16

[Phil Ringnalda (:philor)]

*** Bug 355400 has been marked as a duplicate of this bug. ***

Comment 20

[teac77]

Majken has a good point.  Ctrl + clicking the bookmark works very well.  Even so, it is an irritating surprise to those of us getting better acquainted with bookmarks and tabs.

I think Phil Ringnalda knows what I'm talking about.

Comment 23

[turningoff]

Man, how many people do you need logging duplicates of this bug before you realize it is a user interface thorn?

Esp. for people who use menus as opposed to keyboard shortcuts using control keys.  Somewhere long ago there was a user interface rule that said using a bunch of keys simultaneously was a less good thing.

Some of us do not have middle click available either, unless there is some way to do this on a touchpad.  And no I don't want to learn a bunch of esoteric multiple key multiple click ways to do something instead of having a consistent user interface with menus.

What's that I smell?  Is it a programmer's love of difficult, complex ways to do things instead of an interface that is intuitively apparent?

Comment 24

[Majken Connor [:Kensie]]

By your reasoning, the bug as filed can't be fixed.  Cut has T (in everything) and changing cut in this instance would break many more people than the current behaviour is breaking now.  I'm not sure if a bug to change the html link behaviour would be more successful.

You're already using a multiple key/multiple click way to do this.  Either you're mousing to the link, then right clicking, then hitting the letter, or you're tabbing to the link, opening the context menu, then hitting the letter.

Everyone who has filed this issue are using keyboard+mouse, not just keyboard and really want to be using ctrl+click or middle click rather than getting into the menu. Not only is it faster, it's standard (word, xchat, to name a couple off the top of my head).

If this is an accessibility problem for people who only use keyboards, then it should definitely be addressed, but, again, not as filed. Cut takes t when cut exists.

Comment 25

[Oleg Smirnov]

First of all, it definitely IS an accessibility problem when one using a laptop one-handed for whatever reason. Neither ctrl+click nor middle-click is an easy alternative.

Secondly, I don't agree with the implied assertion that Cut is so much more important than Open new tab, and that messing with Cut in this particular menu would "break many more people". It's a browser, not a text editor -- how often do you Cut bookmarks compared to Opening new tabs? I have a hard time picturing a user who sits there cutting bookmarks all day. Maybe we should do a poll about which operation is more popular.

In the third place (and this is what really gets me about the bug), it's so bleeping DESTRUCTIVE. In the opposite scenario -- if T was removed from Cut in this one menu, and assigned to Open in new tab -- the consequence for our hypothetical cut-happy user is the occasional unintended opening of a new tab. Mildly annoying, but no irreversible damage at least. At present, we have unintended destruction instead. Personally, I find the loss of a bookmark to be way more annoying than having an extra tab pop up, and much harder to undo.

Comment 33

[Steven S.]

Apparently over two years of duplicated bug reports are not enough to warrant even a simple usability survey?

Comment 35

[Jaime Alvarez]

It seems to me that a good compromise would be to add a "undo delete boookmark" menu item when right clicking on the toolbar. What do you think?

Comment 36

[Andreas]

No. Adding an additional menu item simply to fix a usability issue is definitely NOT a good idea. That is as you would add a "turn engine off when seating"-feature to your car because the engine starts when you open the door.

The main problem of this case is the differences in multi-languages. Btw... perhaps someone who knows could just add a comment and tell us: Is it a difficult issue to fix (just concerning coding). If coding is not the problem, perhaps i could help and propose a solution.

Comment 37

[Steven S.]

The main problem is not multiple languages, it's the basic Windows ui design for the accesskeys. Firefox made it so that you can right click a link within a web page and hit t to open a new tab; useful. The problem is that this does not carry over to the bookmarks, instead of t opening a new tab it cuts the bookmark, you must use w to open a bookmark in a new tab. They are being "good" in following the Windows ui where t is cut, it is just a bad decision which makes for bad continuity between the two sections, and they have refused to even consider changing that. Instead we get arguments about how people should be using control click... guess what, if you right click you see Open in new Tab, there is nothing that straight up says to hold control. I personally, even knowing it, prefer to right click as I go. I don't like holding keys.

They should either get rid of cut since it takes t, or remove the keyboard shortcut of t within a page. Take a look at IE 7 (far inferior, don't get me wrong); they avoid the whole problem by not using any of the accesskeys when you right click. I do not advocate this, I do think a little more thought should be put into the issue instead of writing it off.

Comment 41

[kai.wicker]

Count me in for the duplicates. I very nearly reported this "bug", too.
Very annoying, as I've lost quite a few bookmarks.

If they don't want to get rid of "t" for cut, how about having a different key for "open in new tab". Make it "w" in both? But be consistent!!!

Comment 42

[Alfred Kayser]

According to The Matrix:
    Ctrl              Access key for links     Access key for places
O   Open File         N/A                      Open
X   Cut               N/A                      N/A
T   Open new Tab      Open Link in New Tab     Cut
N   Open New Window   N/A                      Open in New Window  
W   Close Tab         Open Link in New Window  Open in New Tab

The problem here is that people get used to using 'T' as access key to open a link in a new tab, and then use the same key for the same purpose in the Places/Toolbar/Library/etc... (where is it defined to be 'Cut').
Note that the Windows GUI standards have 'T' defined as accesskey fo Cut a very long time...
So, T should remain Cut, but the Open in New Tab in the link popup should NOT be 'T'.

The fix would be to change the access keys for links as follows:
   N (Open Link in &New Window)
   W (Open Link in Ne&w Tab)
And actually this popup for the links ahould have as first entry:
   O (&Open Link)

So, that the matrix becomes:
    Ctrl              Access key for links      Access key for places
O   Open File        *Open Link*                Open
X   Cut               N/A                       N/A
T   Open new Tab     *N/A*                      Cut
N   Open New Window  *Open Link in New Window*  Open in New Window  
W   Close Tab        *Open Link in New Tab*     Open in New Tab

The conflict is still there on Cut (Ctrl-X versus accesskey T) such as in places, but that is according to the Windows standards. Note that Windows 

This makes the access keys for links more in line with places/toolbars/bookmark manager, and to the Ctrl keys.

So, two choices here:
1. Re-open this bug and morph to align the Links popup (as above)
2. Close this bug (as we can't solve the 'T' issue itself) and open a new one for the Links popup.

Comment 43

[Alfred Kayser]

Note that there 23 duplicates by now!

Comment 44

[Steven S.]

There is a third choice... remove cut from bookmarks in general. The functionality doesn't make very much sense. You can drag a bookmark to another place if you are trying to organize, you can click a bookmark if you are trying to go there, no need to paste a url. Cut removes a bookmark while leaving a url in the clipboard... making it easier to destructively paste into another application I suppose, as anything else can be done much simpler and quicker without.

I think a lot of people get used to the right click w for new window, right click t for new tab. It is intuitive, much more so than n for window, w for tab.

Comment 45

[Phr3d]

plus one for the "undo delete bookmark" -or-
how about a confirm dialog for the bookmark delete?

This has been described to death, but it is EASY to accidentally delete a toolbar bookmark, and very difficult to get it back.  That was why undelete/confirmations were added to applications originally, correct?

Many users (obviously) liked the right-click-t when we first started using Firefox, it is a Very difficult habit to break.  It is guaranteed that a user will delete a bookmark unintentionally due to habits ingrained by a non-matching shortcut.  Please add a safety-net.

Comment 50

[exec228]

1.sorry for dup. lazy me avoided to use non-convenient search interface.
2.devs! on the other hand my dup again votes against T for "cut"

Comment 51

[Simon Bünzli]

For all of you complaining about this bug not being fixed yet: Code-wise it's pretty simple, so please go ahead and post a patch after having made sure that you don't produce any new bugs:

(In reply to comment #42)
> The fix would be to change the access keys for links as follows:
>    N (Open Link in &New Window)
>    W (Open Link in Ne&w Tab)

You'll have to make sure that these don't clash with any of the other accesskeys already used in a webpage's context menu (of which there already is an unhealthy many possible combinations to be considered).

Comment 52

[deftective]

I reported a dup of this bug.  (Sorry!)  

I agree with the solution in comment #42.

As a user who's accidentally cut the same toolbar bookmarks dozens of times, I would be willing to relearn my firefox grammar and ctl-w to  open in new tabs.

Relearning grammar might annoy users for a short time, but ultimately and for the long term, ctl-w would maintain consistency within both access key cuts and keyboard shortcut behaviors.

Comment 55

[David Dahl :ddahl]

What about a confirmation dialog that can be dismissed with the keyboard?

Comment 56

[Arman]

I agree with Steven's suggestion in comment #44. ow about getting rid of Cut/Copy/Paste altogether from the right-click menu and replacing them with a general "Organize Bookmarks" option (and Ctrl+Shft+B shortcut)? I am guessing very few (if any?) people actually copy, cut or paste any bookmarks within the toolbar itself - most users would do that Bookmarks > Organize Bookmarks. This way there will be no need to add any confirmation dialogs (which doesn't really fix the issue that _T is useful for opening links in a new Tab).

Comment 57

[Lorin Ricker]

+1, especially Comments #41 and #56.  Please make these things consistent.  It's a usability issue that destroys user's information, sometimes without recovery.  Having Cut/Copy/Paste on a pop-up menu "just because..." simply violates the user interface "Principle of Least Astonishment".  Seems to me that the use and utility of "Open Link in New Tab" is *much* higher than that of "Cut" in these contexts, and thus argues for a comprehensive consistency change/fix.

Comment 58

[Lorin Ricker]

+1, especially Comments #41 and #56.  Please make these things consistent.  It's a usability issue that destroys user's information, sometimes without recovery.  Having Cut/Copy/Paste on a pop-up menu "just because..." simply violates the user interface "Principle of Least Astonishment".  Seems to me that the use and utility of "Open Link in New Tab" is *much* higher than that of "Cut" in these contexts, and thus argues for a comprehensive consistency change/fix.

Comment 59

[Jakob Pfender]

Ahem ... since this bug has been filed, there have been 29 duplicates of this bug, and some of you *still* think that this is *not* geting on people's nerves? How many bug reports do you think would be filed if rightclick+t was changed to "open in new tab" and rightclick+x was "cut"? Seriously?

I don't believe how stubborn the majority of developers have to be to let this trivial thing go unfixed for four years - who uses Cut in the bookmark menu?

This is clearly an accessibility issue that is stumping a lot of people, and there is no reason not to fix it. Hell, if you don't want rightclick+t to open a new tab, then at least remove "cut" from the context menu so rightclick+t does nothing.

Just my two cents.

Comment 60

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 64

[steve tozier]

Excuse me for stating the obvious, but why is this still an issue?  It's been a problem for nearly six years! I'm not a web or pc programmer but I did write mainframe software for thirty years.  If we took six months to fix a problem like this, we'd be on the streets looking for a new profession. Can someone please write a fix for this?  Thanks in advance.

Comment 65

[mike]

I am a developer, and the problem is probably that this bug is p2 trivial. It is below the threshold of bugs that they will fix. On the project that I am working on we fix p2s, but apparently firefox does not fix anything below a p1 bug. Since this bug is very annoying, it would be nice if they would fix it, but I am beginning to doubt that they ever will.

Comment 66

[deftective]

Hey mike. Thanks for the clarification. I suspected as much. Firefox's top priorities are probably security- and flash- and new standards-related. But they also have a generally good UI. How do UI features get bumped up to p1 status?

Comment 67

[Marco Bonardo [:mak]]

Resources are not infinite, so when planning stuff you have to choice where to spend them, and everything is not a good choice.
fwiw, P1 and P2 and such are not really used, it's just that there are major problems and small glitches tend to survive.

Comment 68

[mike]

(In reply to comment #66)
At the top of the page users can vote as to how important this bug is. 11 people have voted so far - so if you are not one of them you could vote it up. I personally don't consider it a p1 (p1 to me means that it is a show stopping error)

I agree with Marco Bonardo about resources not being infinite, though. Things like this tend to be overlooked no matter how annoying they are since there are workarounds.

Don't feel too bad that this bug is being ignored, though. There are 800+ bugs older than this reported, and the oldest one is approaching 10 years old.

Comment 69

[Dan Mills [:thunder]]

Votes are not a very useful data-point, mostly due to the self-selecting nature of Bugzilla users.

Having a patch in a bug, on the other hand, makes it *much* more likely to be fixed (though not guaranteed, particularly if it's not clear what the solution should be).

Comment 71

[crusher9977]

The bug is still not fixed? This is just absolutely ridiculous.

This isn't a trivial bug. It can be very crucial!!
I lost some very important bookmarks that I had to use for work, for my job!
There was NO WAY to recover the bookmarks, because I didn't know that it cuts the bookmark. I thought it's a bug that deletes my bookmark.
Who the hell would know about this?? Everyone uses ctrl+ X/C/V for cut/copy/paste, and not stupid T.

I had to stop using Firefox for serious work because of this. Can't use an unreliable browser, that deletes my data.





There are 70 comments and 13 votes now (I just did my vote).
There reason why I didn't vote before is that I filled out my own bug report- and then it was deleted.

As we can see, there have been many bug reports for this particular problem.
70 comments here.
So the only reason that it only has 13 votes must be, that people do not find this bug!!! I didn't find it when I was filling out the request.

So isn't there ANY mozilla developer who can tell the other developers how IMPORTANT this tiny thing is?
It would take 5 minutes to fix it, but you didn't fix it for years!

Comment 72

[Marco Bonardo [:mak]]

(In reply to comment #71)
> I lost some very important bookmarks that I had to use for work, for my job!
> There was NO WAY to recover the bookmarks, because I didn't know that it
> cuts the bookmark. I thought it's a bug that deletes my bookmark.

You can always recover bookmarks from the Library (bookmarks/Show All Bookmarks) using the undo menuitem. You can also restore a recent bookamrks backup from the Library. 

> It would take 5 minutes to fix it, but you didn't fix it for years!

Your patch will be welcome!

Comment 73

[crusher9977]

(In reply to comment #72)
> You can always recover bookmarks from the Library (bookmarks/Show All
> Bookmarks) using the undo menuitem. You can also restore a recent bookamrks
> backup from the Library. 
Well, thank you that helps. But back when it happend, I hadn't know about it.

> > It would take 5 minutes to fix it, but you didn't fix it for years!
> 
> Your patch will be welcome!
I'm not a mozilla developer. It obviously takes a long time to fix a small problem in someone else's project, then again it should take 5 minutes for your own project.

Many applications have the same hotkey for several menu entries. So all you really have to do is to replace the hotkey "open in a new tab".

Replacing just >>one single letter<< in the source code will fix the problem we've had for 6 years now. No offence!

If you can do this and make them publish it, you're my hero!

Comment 74

[Marco Bonardo [:mak]]

bug 416459 will solve the dataloss part, that is the worse effect of this bug.

Comment 75

[Luyun Xie[:luyunxie]]

Attachment: change accesskey of openLinkCmdInTab and openLinkCmd

This patch follows comment #42, changes access key of "Open in a New Tab" to "w" and "Open in a New Window" to "N". This is a really easy and small fix. Does it need a testcase?

Comment 76

[Jakob Pfender]

(In reply to Luyun Xie from comment #75)
> Created attachment 556789 [details] [diff] [review]
> change accesskey of openLinkCmdInTab and openLinkCmd
> 
> This patch follows comment #42, changes access key of "Open in a New Tab" to
> "w" and "Open in a New Window" to "N". This is a really easy and small fix.
> Does it need a testcase?

Yeah, 'cause that won't break with users' expectations at all ...

Comment 77

[Marco Bonardo [:mak]]

Comment on attachment 556789 [details] [diff] [review]
change accesskey of openLinkCmdInTab and openLinkCmd

(In reply to Luyun Xie from comment #75)
> This patch follows comment #42, changes access key of "Open in a New Tab" to
> "w" and "Open in a New Window" to "N". This is a really easy and small fix.
> Does it need a testcase?

it doesn't need a testcase, but it needs approval from ux and from a driver/module owner, that is probably the hardest part. The problem is that this change is going to be disruptive for muscle memory of a lot of users.
Imo the simplest solution is to revert to the original WONTFIX solution, since the dataloss issue is gone, even if it's a pity to drop this apparently correct fix.

Comment 78

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 556789 [details] [diff] [review]
change accesskey of openLinkCmdInTab and openLinkCmd

I don't think we want to change this, but it's possible I could be convinced.

Comment 79

[mike]

I was one of the dupe reporters on this bug, and my opinion _might_ be similar to most people who entered this bug:

The muscle memory for this command is already broken - we have to remember two key combinations to open in a new tab. It is hard to remember mentally do a context switch when you go to the bookmark bar, and this makes it difficult to remember that you have to use a different hotkey in that case.

If you were to change this, I agree that it would cause some trouble to some users in the short term, but muscle memory can change, and the long term result is that there will be only one hotkey that we will have to remember, and to me that is worth the minor inconvenience of updating my muscle memory.

Comment 80

[Luyun Xie[:luyunxie]]

I think this inconsistency must be fixed. Though the data loss problem has been addressed, it still causes trouble. We have lost six years argue in vain. Why not act now and prevent this confusion from more people?

Comment 81

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 556789 [details] [diff] [review]
change accesskey of openLinkCmdInTab and openLinkCmd

I didn't have a chance to read all of the comments, but here's my proposal to fix this issue: we display the normal cut/copy/paste shortcuts to the side like a traditional menu bar (control-x, control-c, control-v), and we allow but the control+ and the characters by themselves to function when the context menu is invoked.  This is consistent (in terms of shortcuts), discoverable (in that we write them out), and solves the dataloss problem.  Kind of unconventional behavior for a context menu, but I think people will figure it out.

ui-review+ with the changes listed above

Also, that's quiet a dupe count we have here.

Comment 82

[Chris Drost]

I would recommend removing the Cut/Copy/Paste functionality from bookmarks in the Bookmarks toolbar entirely, and restore "T" to "Open in new Tab" and "W" to "Open in new Window." I would keep the "Delete" key. 

One easy way to see why this is a solution is to notice that there are a bunch of nonsense posts here which say "Ctrl-X" as if that were a sensible idiom. This occurs only when right-clicking a bookmark, and you wouldn't press Ctrl-X in that context, so Ctrl-X is not a sensible idiom. But that also means that "Cut, Copy, Paste" are not sensible idioms: they are appearing as if on an alien planet with no idea how they got there.

That's not an argument, that's just the reason you should be scratching your head and saying "huh? why is that there?". As for a proper argument:

There is absolutely no usage case for cutting, copying, and pasting bookmarks in the Bookmarks Toolbar that isn't better served by either the "Delete" menu item or the drag-and-drop functionality that already exists. The drag-and-drop is also more intuitive. If you really want to move bookmarks from the Bookmarks menu to the Toolbar, drag them. If you have a lot to do, then you'd already be using the Organizer, where you can select multiple anyway -- this would still have cut/copy/paste, and Ctrl-[letter] makes perfect sense here. And if you really want two copies of the same page bookmarked on the Toolbar, drag the page to the Toolbar twice. (Or drag the same bookmarklet link twice.)

Since Cut/Copy/Paste are not supposed to be there, don't do anything, and cause problems with access keys, they should be removed.

Comment 83

[dxbugzilla]

So I have a fix that works for this bug.  Since this is my first post, I have no idea what I need to do to upload a patch.

It makes sense to me to simply change this in the context menu itself to "T" rather than "W" to match the rest of the browser.  I did some checking and I have confirmed this fixes the bug.  I have not exhaustively checked this for any other bugs.  

Here are my steps to fix:
1.  Find the "places.dtd" file in the following location of the omni.ja package:  chrome\en-US\locale\browser\places\
2.  Extract, back-up, and then open the places.dtd file for editing.
3.  Find the line that says <!ENTITY cmd.open_tab.accesskey          "w">
4.  Change the "w" to a "t" with the quotation marks.
5.  Save and readd to omni.ja file.  

Apologies if this is an improper way to post.

Comment 86

[Sepero]

As this has been open almost 10 years ago now and is still receiving new bug report dups with no clear decision, perhaps solve it democratically? Firstly, poll mozilla team members to see who uses the the keyboard shortcuts or not, and eliminate those who do not. Take the remaining members and poll them on: change, no change, or don't care.

Create a ruleset:
XX% Change    = change it
XX% No Change = won't fix

Also, set a rule for how much "don't care" votes weigh. Either bias them in favor of change, or in favor of no change.

Comment 87

[Majken Connor [:Kensie]]

Things have changed _a lot_ with browser UI since this bug was first filed. I think it makes less sense for cut/copy/paste to be options when right clicking on a bookmark. We should include "copy link location" instead and possibly "manage" which opens the bookmark in the library. We could also remove all of the "New" options when right clicking *on* a bookmark. 

If anyone from UX is reading this, maybe we should spin off another bug to fix this if it's a good idea?

Comment 88

[Sepero]

All that sounds fine. Hopefully we can just get some decision on this issue.

Comment 89

[Arman]

15 years, 35 duplicates, and no resolution? Quoting Principle 5 from The Mozilla Manifesto seems appropriate: "Individuals must have the ability to shape the Internet and their own experiences on it."

Comment 91

[Giulio Portioli [:gportioli]]

Attachment: Bug 301888 - Remove Cut/Copy/Paste items from Bookmarks context menu. Make Open Link items consistent with link context menu.

I'd like to try and bring this saga to a closure. As suggested in comment 87, the Cut/Copy/Paste menu items in the Bookmarks context menu aren't all that useful. I doubt anyone uses them from the Bookmarks Toolbar, and by removing them, the loss of functionality when using the Organizer is minimal; the user still has 3 other ways to manipulate bookmarks in the Organizer:

• Drag and Drop
• Keyboard shortcuts (Ctrl+X etc.)
• Cut/Copy/Paste items in the Organize menu from the menu bar

With those three items out of the way, the access keys for the Open Link items in the Bookmarks context menu can finally be made intuitive and consistent with the corresponding items in the Link context menu (T for tab, W for window, P for private). I've also tweaked the labels so that the wording is exactly the same as in the Link context menu.

Note that the two context menus are still not identical: the 'Open Link in New Container Tab' item is present only in the Link context menu, but at least now they are a lot more similar!

The only thing I'm not sure about is whether or not the placesContext_createBookmark menuitem element is still needed, if the Cut/Copy/Paste items are no longer there. I've deleted it on the assumption that it's not.

Comment 92

[Mark Banner (:standard8)]

(In reply to Giulio Portioli [:gportioli] from comment #91)

I'd like to try and bring this saga to a closure. As suggested in comment 87, the Cut/Copy/Paste menu items in the Bookmarks context menu aren't all that useful. I doubt anyone uses them from the Bookmarks Toolbar, and by removing them, the loss of functionality when using the Organizer is minimal; the user still has 3 other ways to manipulate bookmarks in the Organizer:

The problem is removing these from the context menu means that there would be no way of doing those actions from the bookmarks menu or the toolbar. Some users don't use the library that much, and may prefer to do their changes directly in the toolbar/menus.

This is removing functionality without providing a similar replacement.

If we could get a solution that doesn't remove without replace, then we could ask UX for their evaluation.

Comment 93

[Giulio Portioli [:gportioli]]

(In reply to Mark Banner (:standard8) from comment #92)
Admittedly, I had not considered that the Bookmarks menu and also the Bookmarks sidebar share the same context menu as the Bookmarks toolbar, so I agree about the loss of functionality. However, I question the idea that users do much cutting and pasting of bookmarks from the toolbar; they are arguably more likely to do that from the menu or the sidebar (or the Library, of course).

Therefore, how about having a dedicated, separate context menu for the Bookmarks toolbar that has the same items as the current one, minus Cut/Copy/Paste, and has the 'Open in' items (and access keys) consistent with the main window's Link context menu? That would leave the context menu unchanged for Bookmarks menu, sidebar and Library.

With such change, it would no longer be possible e.g. to cut a bookmark straight from the toolbar, but it would still be possible to cut the same bookmark from the Bookmarks menu and sidebar, from which the toolbar is readily accessible. It seems to me a small price to pay to finally restore consistency to the main window (of which the toolbar is arguably an integral, permanent feature, unlike the Bookmarks menu).

Also consider how infrequent the cutting and pasting of bookmarks is, compared to the opening of links in new tabs and windows. User experience would arguably benefit a lot more from having consistent commands for frequently performed operations, rather than having all commands available everywhere, even those ones used only once in a blue moon.

Comment 94

[Marco Bonardo [:mak]]

Without real telemetry data we can't really make any conclusion about usage of a feature, assumptions are risky.

Comment 95

[BugBot [:suhaib / :marco/ :calixte]]

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D44078	Bug 301888 - Remove Cut/Copy/Paste items from Bookmarks context menu. Make Open Link items consistent with link context menu.	gportioli	Standard8: Resigned from review
			flod: Resigned from review

:gportioli, could you please find another reviewer or abandon the patch if it is no longer relevant?

For more information, please visit auto_nag documentation.

Comment 96

[Mark Banner (:standard8)]

Cancelling NI as that seems to be an incorrect alert.

Comment 97

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 36 duplicates, 12 votes and 55 CCs.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 98

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.