Open Bug 135813 Opened 22 years ago Updated 5 years ago

selection context menu appears even when right-clicking outside of selection

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: WONTFIXME?)

Attachments

(1 file)

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.
Blocks: 135225, 135264
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
QA Contact: paw → tpreston
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.
Keywords: nsbeta1
OS: Windows 98 → All
Hardware: PC → All
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
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.1alpha
*** 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)
Attached patch proof-conceptSplinter Review
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
QA Contact: tpreston → pmac
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.
Keywords: nsbeta1-nsbeta1
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.
Keywords: nsbeta1nsbeta1-
Nav triage team: nsbeta1-
Keywords: mozilla1.3
*** Bug 191695 has been marked as a duplicate of this bug. ***
*** Bug 193162 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.1alpha → Future
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.
Assignee: firefox → guifeatures
Target Milestone: Future → ---
Component: XP Apps: GUI Features → Autocomplete
Product: Browser → Firefox
Version: Trunk → unspecified
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.)
Assignee: guifeatures → neil.parkwaycc.co.uk
Component: Autocomplete → XP Apps: GUI Features
Product: Firefox → Browser
Whiteboard: WONTFIXME?
Version: unspecified → Trunk
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
Product: Core → Mozilla Application Suite
(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


Assignee: neil → guifeatures
Severity: major → minor
QA Contact: pmac
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"
Severity: minor → normal
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: