Open Bug 301888 Opened 19 years ago Updated 2 years ago

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)

Categories

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

Product:
Firefox
Component:
Bookmarks & History
Type:
defect

Tracking

()

People

(Reporter: armanmail, Unassigned)

References

Details

(Keywords: ux-consistency, ux-error-prevention, Whiteboard: see comment #13)

Attachments

(1 file, 1 obsolete file)

change accesskey of openLinkCmdInTab and openLinkCmd
849 bytes, patch
faaborg
: ui-review-
Gavin
: feedback-
Details | Diff | Splinter Review 
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.
*** Bug 326850 has been marked as a duplicate of this bug. ***
*** Bug 330361 has been marked as a duplicate of this bug. ***
Component: Bookmarks → Places
OS: Windows XP → All
QA Contact: bookmarks → places
Hardware: PC → All
Summary: Bookmarks cut instead of opened in new tab from Boomkars Toolbar Folder → Bookmarks cut instead of opened in new tab from Boomkarks Toolbar Folder
Version: unspecified → 2.0 Branch
Assignee: nobody → bugs
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2
Summary: Bookmarks cut instead of opened in new tab from Boomkarks Toolbar Folder → Bookmarks cut instead of opened in new tab from Bookmarks Toolbar Folder
Fixed, branch and trunk (323812)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 338304 has been marked as a duplicate of this bug. ***
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [wontfix?]
Target Milestone: Firefox 2 alpha2 → Firefox 3
Version: 2.0 Branch → Trunk
*** Bug 349938 has been marked as a duplicate of this bug. ***
*** Bug 318706 has been marked as a duplicate of this bug. ***
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.
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?




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?
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.
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.
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.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
Bug 214922 for the bug tracking ctrl + letter
Whiteboard: [wontfix?]
*** Bug 355083 has been marked as a duplicate of this bug. ***
*** Bug 355400 has been marked as a duplicate of this bug. ***
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.
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?

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

Apparently over two years of duplicated bug reports are not enough to warrant even a simple usability survey?
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?
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.
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.
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!!!

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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
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.
Target Milestone: Firefox 3 → ---
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).
Assignee: bugs → nobody
Whiteboard: [good first bug]
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.
What about a confirmation dialog that can be dismissed with the keyboard?
Assignee: nobody → ddahl
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).
Status: REOPENED → NEW
+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.
Assignee: ddahl → nobody
Whiteboard: [good first bug] → [good first bug][patches welcome]
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?
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.
(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.
Whiteboard: [good first bug][patches welcome] → [good first bug][patches welcome] see comment #13
(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!
Depends on: 416459
bug 416459 will solve the dataloss part, that is the worse effect of this bug.
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 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.
Attachment #556789 - Flags: ui-review?(faaborg)
Attachment #556789 - Flags: feedback?(gavin.sharp)
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.
Attachment #556789 - Flags: feedback?(gavin.sharp) → feedback-
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 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.
Attachment #556789 - Flags: ui-review?(faaborg) → ui-review-
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.
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.
Whiteboard: [good first bug][patches welcome] see comment #13 → see comment #13
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?
Summary: Bookmarks cut instead of opened in new tab from Bookmarks Toolbar Folder → 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)
Priority: P2 → P3

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.

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

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

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

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.

Flags: needinfo?(mozilla)

Cancelling NI as that seems to be an incorrect alert.

Flags: needinfo?(mozilla)
Attachment #9089237 - Attachment is obsolete: true
Severity: trivial → S4

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.

Flags: needinfo?(mak)

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.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: