Open Bug 135225 Opened 22 years ago Updated 16 years ago

don't mix selection and non-selection context menus (accesskey dups)

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

mozilla1.1alpha

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: access, Whiteboard: [adt2])

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.
Keywords: adt1.0.0, nsbeta1
QA Contact: zach → sairuh
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=.  
Keywords: adt1.0.0
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).
Keywords: access
>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.
Assignee: marlon → blaker
Component: User Interface Design → XP Apps: GUI Features
Summary: need context menu spec for selection with links/images (accesskey dups) → remove context menu portions for selection with links/images (accesskey dups)
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.
Blocks: 105580
Summary: remove context menu portions for selection with links/images (accesskey dups) → don't mix selection and non-selection context menus (accesskey dups)
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
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
Depends on: 135813
Blocks: 135841
-> morse
Assignee: blaker → morse
Target Milestone: --- → mozilla1.0
OS->All.  ->ben
OS: Linux → All
removing plus for retriage
Keywords: nsbeta1+nsbeta1
nsbeta1- per Nav triage team.
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1alpha
reassign to component owner
Assignee: morse → blaker
QA Contact: sairuh → paw
*** Bug 152846 has been marked as a duplicate of this bug. ***
nominating...
Keywords: nsbeta1-nsbeta1
*** Bug 175271 has been marked as a duplicate of this bug. ***
nsbeta1- per the nav triage team.
Keywords: nsbeta1nsbeta1-
*** Bug 187224 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Assignee: bross2 → guifeatures
QA Contact: pawyskoczka
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.