tested using 2002.04.03.09-static mozilla build on linux rh7.2. i ran into some menu accesskey duplications while looking at the selection context menu --when the selection includes link or image content. the current spec doesn't quite take these cases into account (hence this bug :). to repro, highlight some content that includes (a) a link, (b) an image or (c) a linked image. results: a. selection with linked text: _Copy Link Location . . _Copy b. selection with an image: _Copy Image (*) . . _Copy c. selection with an linked image: _Copy Link Locaton . . _Copy Image (*) . . _Copy (*) - "Copy Image" is currently not in the context menus not sure if it's missing because of lack of backend implementation, or if it's really a bug.

these items were left out of the spec because there wwere too many possibilites for the selected content case. what happens if you have selected *multiple* links, or multiple links and images, or every possible context on a page... You cannot provide a subset of all of those menus reasonably in one menu, so i chose to provide a minimal, set of items which aren't all inclusive, but provide what most other apps do in selected content context menus. that is, to provide an extended set of clipboard features, and few innovative, complementary items. Right clicking on the specific object you want to copy is the most direct and intuitive way to perform an operation on an element.

Mozilla shouldn't mix normal context menus and selection context menus. Right- clicking on the selection should give a selection context menu, and right- clicking outside the selection should give a normal context menu (possibly clearing the selection at the same time like in IE). See bug 105580.

Removing adt1.0.0. No patch, r= and sr=.

marlon, thx for the explanation --that makes sense. but, one remaining question: how should we resolve the duplicate menu accesskeys i'm currently seeing? should we just remove the link and image specific items, and keep it down to the simple selection items you have at http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-3.html#Anchor-52467 ? if yes, let me know, and i could either resummarize this bug (the accesskey duplication was the main reason why i filed), or file a new one (and wontfix this one).

>should we just remove the link and image specific items, and keep it >down to the simple selection items you have at.... yes the menu wouldn't have any colliding access keys if the only the items specified were in place. Those link and image items shouldn't be in the selected content menu.

thanks again, marlon! resummarizing, and over to blake. intriguing observation: if the mouse pointer is over the link/image/linked image ***while bringing up the context menu***, you'll see the additional menu items. but if the mouse pointer is just over the text portion of the selection, you won't see the additional items. this would mean removing the following items in the above cases: a. remove for selection with linked text: Open Link in New Tab Open Link in New Window Bookmark This Link Save Link Target As... Copy Link Location b. remove for selection with an image --additionally, these extra items are *also* seen when i do a selection for the "image as url" context menu: View Image Block Images from this Server (mozilla only) Copy Image Location Save Image As Send Image c. remove for selection with a linked image: Open Link in New Tab Open Link in New Window Bookmark This Link Save Link Target As... Copy Link Location View Image Block Images from this Server (mozilla only) Copy Image Location Save Image As side note (*): the "copy image" issue (referred to in original comment) has been filed as bug 135300.

This bug occurs when you have a selection and right-click on an image or link, regardless of whether the image or link is contained in the selection. To fix this bug correctly, we should detect whether the user right-clicked within the selection. This should be possible, because the selection is cleared onmousedown if you left-click outside of it but not if you left-click inside of it.

Bug 135264 directly opposes this approach.

This will make the context menu useless in many cases. From bug 135264: ------- Additional Comment #3 From Matthew Thomas (mpt) 2002-04-03 18:44 ------- Yes, this is bad because many people have an odd habit of selecting text randomly with the mouse while reading Web pages. (Full disclosure: I'm not one of those people.) If, after selecting such text, they try to use the shortcut menu to go Back or Forward -- whether or not they happen to be over the selected text when they mousedown -- Mozilla will stuff them up.

Dean: this would not "make the context menu useless in many cases". See my comment 3 and comment 7 in this bug.

I don't like that. The relevant portion of the selection context menu is two items, Copy and Select All, and I guess Search. Undo, Cut, and Paste have no place in a context menu for static text. So you'd end up with a three-item context menu.

Having a three-item context menu would be better than having those three items mixed in randomly with 6 or 10 items from the normal browser context menu. But you shouldn't worry that a selection context menu would "look too short", because it would eventually include commands like "look up ... in dictionary" (part of bug 105580) and "open /n/ selected links" (bug 9274). (I don't think "Select All" should be included in the selection context menu. How is "Select All" more relevant to a selection than to an unselected part of the page?)

Nav triage team: nsbeta1+/adt2

-> morse

OS->All. ->ben

removing plus for retriage

nsbeta1- per Nav triage team.

reassign to component owner

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

nominating...

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

nsbeta1- per the nav triage team.

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

Filter "spam" on "guifeatures-nobody-20080610".