Closed Bug 135264 Opened 23 years ago Closed 21 years ago

don't show selection context menu for static text

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
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: nsbeta1nsbeta1-
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.3
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: 21 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: 21 years ago21 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.