Closed Bug 135264 Opened 22 years ago Closed 20 years ago

don't show selection context menu for static text

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.1alpha

People

(Reporter: deanis74, Assigned: neil)

References

(Depends on 1 open bug)

Details

Steps:
1. browse to a web page, any web page
2. Select some text
3. right-click

Expected results: The context menu is the same as when no text is selected,
except that Copy is disabled.

Actual results: A different context menu displays with disabled Undo, Cut,
Paste, and Delete items.  These items are useless when static text is selected.
 This appears to be the same context menu as for text fields, but I can't see
how these four menu items would ever be enabled when static text on a page is
selected.

Build: 2002040303 on Win2K
It's worse, actually.  As long as any text is selected anywhere on the page
(even if it's not in view) none of the regular context menu options are
available!
Yes, you're right.  Why didn't I just say that in the first place?  :)

This looks to be the wrong context menu.
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.

The text field menu should be used only for text fields; the page content area 
menu should be used in all non-field/link/image/frame areas, with the `Copy' 
item being enabled if text is selected. If you really do want to copy the text, 
the `Copy' item is in the same position (two items plus one separator down from 
the top of the menu) whether you're copying from a field or from the page text, 
so you don't have to stop to think about where you are. --> XP Apps: GUI.
Component: User Interface Design → XP Apps: GUI Features
>Yes, this is bad because many people have an odd habit of selecting text 
>randomly with the mouse while reading Web pages.

Mozilla should only show the selection context menu when you right-click on a
selection.  That's what IE does, and is also how I suggested we fix bug 135225.
 I think this bug should be fixed by fixing bug 135225, not by re-merging the
selection context menu with the main browser context menu.
Summary: Undo, Cut, Paste, and Delete menu items in browser context menu → selection context menu appears even when right-clicking outside of selection
<aside> Interestingly enough, Select All doesn't appear until I have some text
selected.  </aside>
QA Contact: zach → sairuh
*** Bug 135573 has been marked as a duplicate of this bug. ***
This is not good.  The back and forward option should Always appear when
right-clicking on a webpage.   
As well as when text is selected, the "back" option is not available when you
right click on an image, a link or in a text box (like the one I'm typing this
message in).  This is most annoying because now I have to worry about where I'm
right-clicking to get the "back" option.   I find this behaviour in the context
menu annoying in IE. *rant*
Keywords: mozilla1.0, nsbeta1
Actually, I don't like the new summary.  This was my bug initially, and the new
summary is not what I intended when filing.
Summary: selection context menu appears even when right-clicking outside of selection → don't show selection context menu for static text
the context ambiguity for this menu is fairly low, because 2  certain conditions must be met: 1) highlighting a selection; 2) right clicking 
within the selection or in the 'horizontal vicinity' of that selection. Right clicking outside of selection would still bring up a menu pertaining 
to the text portion of the selection unless it were outside the 'horizontal region' (check out the IE behavior). if outside this horizontal 
region, then we would *deselect*, and produce the more immediate context underneath the cursor.  this is the best way to deal with 
forgotten or accidental highlighting (user scrolled out of view)

if another contextual node were contained within a selection, such as a link or an image within a selection, then right clicking directly on 
that element should produce the context menu for that element combined with a *core* Selected Content menu, and while keeping the 
selection (so not exclusively the [selected content] menu). 

Sorry for the morph, filed bug 135813 for "selection context menu appears even
when right-clicking outside of selection".

Dean, I'm still not sure what you want.  Do you want the context menu for
selected text to be...
- exactly the same as a normal context menu,
- a normal context menu with Copy and Search added in random locations (like in
the old context menus), or
- one similar to what we have now but without Cut, Undo, Paste, and Delete?

Xah, since you nominated this bug for mozilla1.0, do you agree with Dean?
Depends on: 135813
There is definitely a need for context sensitive menu similar to IE. However, IE
is not perfect.  My monitor resolution is set to "1024 X 768" and mozilla is not
maximized and the sidebar viewable. If you visit www.palm.com and right-click to
go back a page, you may find that "back" is not available because the page has
many images.  This takes away the convenience of right-clicking to go back a
page as in IE.  
> right clicking within the selection or in the 'horizontal vicinity' of that
> selection. 

Either this is not working correctly or our definition of "horizontal vicinity" 
is very very screwy...

> outside this horizontal region, then we would *deselect*

Not on Linux we should not, since deselecting should clear PRIMARY and thus is 
a somewhat destructive behavior (what if the user selected that text because 
they actually meant to paste it somewhere?)
I liked it the way it was before, with the right-click menu only slightly
modifying itself depending on content, rather than completely become a different
menu.

At the very least, navigation options should always be available -- this is one
of my top 10 annoyances with internet explorer. I feel less strongly about the
view source, etc. options, but I kinda think those should remain too. 

Rationale: navigation options and other choices which pertain to the whole page
are still relevant even when you've clicked on a sub-element of that page.
Nothing is particularly different about an image in a page vs. some text in that
page vs. any other page element when it comes to navigation, or view source, or
save-the-whole-page. Therefore, those options should always be available.

Also, I'm pretty sure that right clicking should never deselect. Selecting is a
left-button operation and the right-button should stay out of it. One shouldn't
have to be precise -- or even close to precise -- when trying to bring up the
copy options.
> I liked it the way it was before, with the right-click menu only slightly
> modifying itself depending on content, rather than completely become a 
> different menu.

I didn't like it for several reasons:
* It made the selection context menu so long that it was difficult to find
"Copy" and "Search Web for ...", the only two useful options on the old
selection context menu.
* It made it difficult to add more useful commands to the selection context
menu, like "Look up in Dictionary" and "Open Selected Links", because those
would clutter an already cluttered menu.
* It made the normal context menu less predictable, because it would change
depending on whether you had selected text *anywhere* on the page.

> At the very least, navigation options should always be available

So don't right-click on a selection if you want to navigate.  See bug 135813,
"selection context menu appears even when right-clicking outside of selection".
Jesse -- as I said, navigation should *always* be available. "Don't click on
items of type x, y, or z" shouldn't come into it.

Bug 135813 might help, but still.

I think the issues in comment #7 (images, links, etc.) are probably the most
annoying, with selected text being just a small case. Bug #135331 is for the
images....
I've thought this over, I've played around with IE, and I now agree with Jesse.
 Yes, it's true, I can change my mind!

I _think_ I'd rather see bug 135813 fixed than this one.
nsbeta1- per Nav triage team. ->1.1
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1alpha
I *am* one of those people that keeps selecting and deselecting text.

IMO the selection context menu should only show when I click on selected region.
I'm another of those odd people who selects text as I'm reading it. It often
helps make legible pages with poorly chosen font/background colours.

I appreciate that the context menu in 0.9.9 was a nit long, and yes I do see
that there's merit in making it sorter and more context-specific, but  Ialso
agree that the navigation options back/forward/reload, and maybe "save page" and
"view page/frame source" should always be present. Indeed, I am so attached to
using "Back" from the context menu, while having some (or all) text highlighted
and possible alos right-clicking on an image, that I may revert to Moz0.9.9 if
these items aren't put back. It's one of the many thing I dislike about IE, and
one of the many reasons I've always used Netscape/Mozilla instead.
And another thing..... :-)

Didn't "View Image" used to include the name of the image in parentheses? That
was useful, and now it's gone, a la MSIE. Without actually clicking on the "View
Image" (or "Save Image"), how am I supposed to know the image filename? There is
no longer any way that uses just 1 mouse click.

(May I also take this opportunity to apologise for the innumerable spelling
errors in my previous message.... Forgot to proof-read, sorry! Hope it wasn't
too illegible.)
*** Bug 147040 has been marked as a duplicate of this bug. ***
*** Bug 161737 has been marked as a duplicate of this bug. ***
I just wanted to weigh in with agreement with both Matthew Miller and Dan Soper.
 As with Matthew Miller, I believe the context menu should -always- have Back,
Forward, Reload, and Stop.  I don't habitually select text while reading a web
page, but I do select text whenever I need to copy and paste.  I hate having to
deselect the text prior to using a context menu to go Back or Forward.

I also find it particularly onerous that the Back, Forward, Reload, Stop options
are no longer available if by chance I happen to right-click on an image.  When
I want to navigate Back or Forward, I will often just right-click without
spending any significant time to make sure I am aiming the mouse at the right
thing.  I just expect to see Back and Forward (especially) on the context menu,
regardless of what was under my pointer when I right-clicked.  I think what it
really comes down to is the fact that the menu that appears when you right-click
has to be -both- a context-sensitive menu -and- a common navigation tools menu.
 Too many people like myself rely on the "context" menu to navigate--something
that is not necessarily context sensitive.

And Dan Soper's comment #20 really hits home.  I have no idea why something that
provides additional utility and is already implemented, such as an image's
filename being shown in the context menu, would be removed.  As a web developer,
seeing the name of an image on the context menu is often very useful.
I agree wholeheartedly with Brian Hauer.
Nominating...
Keywords: mozilla1.0 → mozilla1.0.2, mozilla1.2
Keywords: mozilla1.3
Keywords: mozilla1.0.2, mozilla1.2
Grr.  Well, I see very little has happened on this issue, and I have more
important bugs to vote for now (e.g., bug 204374, windows not even repainting
correctly--bad stuff!).  Besides, I have completely thrown out the default
context menu via installation of Jenz Tins' "RadialContext."  Yes, it's
context-sentitive in the purist sense, meaning Back and Forward aren't always
available, but at least it appears on mouse-down rather than mouse-up (my
goodness!) and is reasonably easy to learn.

I still hold out hope that the "context" menus will be changed (is that the
right word?  Maybe "corrected" or "returned to their previous functionality
level") for the vast majority of folks out there who don't want to install
RadialContext.

Good luck!
retargeting
Target Milestone: mozilla1.1alpha → Future
I have an idea. :-) But I haven't a clue about C++ or coding for Mozilla, so
I'll have to leave it for someone else to make it work....

But here it is: The normal page context menu includes Back, Forward, Stop and
Reload. These should always be present, IMO. The menu also includes Select All.
How would it be if, when there was any text selected in the page, the context
menu is unchanged *except* for "Select All" being replaced by a sub-menu which
contains everything that is currently in the selection context-menu (Copy,
Select All, etc)?

This way context menus are kept short, and everyone gets what they want in the
menu. Something similar is already done for pages/sites that use iframes/frames.


And maybe the same thing could be done for images, so that Back, Forward, etc.
could be put back into the context mejnu when right-clicking on an image?
Dan, the context menu is implemented completely in JS -- there is no C++
involved.  See nsContextMenu.js and contentAreaContextOverlay.xul
Target Milestone: Future → mozilla1.1alpha
I still can't help - my JS is only marginally better than my C++ :-D


d.
You don't really have to understand a language to make changes to
things written in the language.

That said if you ignore the frameset context submenu (and there are
reasons to ignore it), we have ui advisors who tell us that cascading
menus for context menus are bad.

Personally I'd rather replace context menus with some other ui
element which is friendly and conducive t something like cascades.

I believe there's a bug w/ patch + reviews which will change the
context menu. i'll try to commit it asap, but i'm drowing in bugmail
like the one you caused me to get.
Assignee: blake → neil.parkwaycc.co.uk
I don't see this bug anymore. With Mozilla 1.7RC2, context menu on static text
shows Copy, Select All, Search Web for, View Selection Source. Clicking on blank
space doesn't show those selection items. By clicking on a text area, the
editing context menu comes up (as it should be). Resolving as wfm according to
the current bug description.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Reopening.  The steps in comment 0, if followed, most definitely show the
problem, as described in comment 1.

Please read the bug, not just the summary, before resolving it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Keywords: mozilla1.3
>Please read the bug, not just the summary, before resolving it
By no means I want to be inflammatory but where it is indicated that I didn't
read anything but the summary? The original testcase is not reproducible for me
(unless the 3rd step becomes "right click on somewhere else"). I think that what
you mean is bug 135813.
Hmm.. right you are.  my apologies.  Re-resolving.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.