Steps to reproduce: 1. Select some text. 2. Right-click somewhere else. Quoting mpt from bug 135264: "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." If you right-click on a page, the normal page items (such as back and bookmark) won't be there. If you right-click on a link, a link context menu will appear, but some options related to the selection will be added to it, making the menu a lot longer. See also these two bugs, which disagree with each other: bug 135225 don't mix selection and non-selection context menus bug 135264 don't show selection context menu for static text Bug 135225's approach requires that this be fixed. Bug 135264's approach might not.

Marlon said in bug 135264 comment 9 that clicking in the "horizontal vicinity" of the selection should still bring up the selection context menu. That makes sense, because it's easy for the cursor to be just to the side of a selection right after making the selection.

I'm skeptical about this -- I don't want to have to very precisely hit the selected area -- both horizontal and vertical "vicinity" should be taken into account. But where does one draw the line?

qa --> tpreston@netscape.com

Here's a start. If the selection is not visible in the viewport, we should not be showing the selection context menu. Nominating, since this is a source of incredible confusion to users and makes the context menus very difficult to use -- you have to remember at all times whether you have the selection active or not.

Additional issue with the context menu that comes up when text is selected: if I have selected text for whatever reason (including accidental), getting out of the text selection context menu is difficult. Left-clicking outside of the menu gets rid of the menu, but does not de-select the text (which most other text displays of any sort that I have do). An additional click is needed for that. However, a double click will often re-select a new set of text, putting you right back where you started. This could get very frustrating very quickly.

nsbeta1- per Nav triage team

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

I have been wandering in that code lately to fix bug 122524. Someone willing to have a go at this could try s/isTextSelected/onSelection/g in nsContextMenu.js (i.e., the current logic is based on whether or not there is an active selection, rather than on whether or not the user clicked on the selection). Then |onSelection| could be set by testing (still in nsContextMenu.js): var selection = focusedWindow.getSelection(); selection.containsNode(target, false /* for wider 'vicinity'... per nsISelection.idl */); (assuming the necessary tests for a non-null/empty selection are also made)

After my checkin for bug 122524, I quickly made this a proof of concept. Most of the patch is the substitution, and the essential part is in @@ -685,36 +685,31 @@ with: + var focusedWindow = document.commandDispatcher.focusedWindow; + var selection = focusedWindow.getSelection(); + if (selection.containsNode(this.target, false)) { [...] } After experimentation, it seemed to me that a more intuitive behavior is really to ignore the "vicinitity" and instead require a direct hit on the selection (even if it is a single character, hitting a single character is unambiguous). However implementing a true |onSelection| would require a more precise test than the mere selection.containsNode() because the selection can be a fragment inside a large <p>...</p> and when clicking anywhere in the <p>...</p>, containsNode() gives true. Anyway, the patch is a start if a tacker wishes to iterate to implement a more precise selectionContainsPoint().

Suggesting WONTFIX based on actual experimentation (once you have a patch, you really get further insights into things). Novice users wouldn't easily discover that they have to make sure to right-click on the selection. Whereas, it is easy to understand that new options show up when something is selected, and one just have to unselect to recover the other options.

> Novice users wouldn't easily discover that they have to make sure to right-click > on the selection. Are you kidding? Novice users will expect that your program behaves like any other program. It's not that Mozilla does it right and all the other 99.9% of programs do it wrong, it's rather the other way IMHO. A context menu is a menu that alteres depending on which context you have clicked and when clicking on a selected text, it's not the same context as when clicking somewhere else two pages below.

qa->Patty Mac

I run into this problem when using the "Find" command. The "Find" command highlights the text I'm looking for. Now I want to go back to the previous page, so I right click...oops, no "Back" item.

Please, don't make behivior dependent on hit I into selection or not if selection exists. I'm not sniper. If IE have some non-optimal behavior this should not be mater for mozilla to replace own optimal (or "in right way to optimal") behavior to non-optimal.

What means you are not a sniper? You were able to target the text to mark it and now you are not able to target it anymore to click on it? Sorry, that makes no sense to me. When I select text on top of a page and scroll to the very bottom and right-click on a link, there is copy link in the context menu, but a user may overlook that and just see "copy" and be very surprised that they just copied some text, marked somewhere on the page (they already may have forgotten that they marked it), instead of copying the link they just clicked on. When I click on a link or picture, the only copy that should be in the context menu is copying of link or picture address. Everything else is out-of-context and the reason why the [Back] was removed of the context menu and now the same principle shouldn't apply to Copy/Cut/Paste?

nominating.

I agree with Matt Seitz of comment 13. I just submitted comments on bug 135264 that said the same thing: I'd argue that Back, Forward, Stop, and Reload should be available on -all- context menus because the "context" menu has evolved into something people use for both context-sensitive tasks and basic web navigation tasks which are not necessarily context-sensitive.

Nav triage team: nsbeta1-

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

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

retargeting

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

spamcop@tgos.org: don't move a bug w/o reassigning, and if you're going to move a bug please provide a comment explaining *why* you're moving it. i'd suggest that people who want something changed in some other product file a new clean bug with a clean description and explanation. they're welcome to cross reference that bug if they like. lastly, i can't imagine why this would be a bug in firefox's autocomplete component. i'm moving this bug back to seamonkey. note that notepad lets me click anywhere in the document to get clipboard items. it's late so the following may be less coherent than the preceding, but... if i context click on an image or link which does not intersect with the selection, then i think i might like not having the selection items displayed. rbs: would that be reasonable? they would still be displayed if i right click on random whitespace, or static text. when context clicking on unrelated static text or random whitespace, i think i'd like the normal context menu + the selection stuff. we currently are willing (or perhaps through bad codepaths happen by default) to show a much longer menu (16 for context clicking a linked image while a selection exists) vs. normal menu (11) + selection (4) -> total (15). i think bz's suggestion (comment 4) is reasonable. i suppose the edge case is that i select something in a flying div and it races offscreen before i have a chance to right click. if that happens, i'll have to use the main menus, which is fine by me. (i should probably also press <esc> but somehow i doubt that works.)

Hmm... Word and IE cancel the selection if you don't right-click on it.

as does explorer fwiw... i'm clearly torn. but clearly at least some of our menu choices are wrong

(Timeless writes in comment #25) > i'm clearly torn. but clearly at least some of our menu choices are wrong KISS (not that anyone is stupid) - mouse click not over selection = not display copy/cut IMO wontfix

OTOH, it appears FF boldly does it (allows copy)

Actually this is very abnormal behavior. I've tested a lot of the apps I have (not all Microsoft) and not one of them preserves selection when you right click outside the selection. We should be killing the selection when you right click out of it. This causes problems when you want to write extensions that do different things when you right click on the document vs. right clicking on selection. Since the way you find out is by saying "is there selection"

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