34357 - All context menu functionality not accessible by other means

Status: VERIFIED INVALID

(SeaMonkey :: General, defect, P3)

Description

[Johnny Stenback (:jst)]

AFAIK things like "Copy link location", "Copy image location" and "Open link
in new browser" are *only* accessible from the context menus, this is wrong,
context menus should only be "shortcuts", but everything you can do from the
context menus should be possible to do without them.

Comment 1

[jglick]

Reassign to German for now.  I'm not sure what to do about this one.  I'm 
assuming this involves all components (Browser, Mail, AIM, AB, etc.)

As far as the examples, i'm not sure how you select a link without opening it, 
so you can access a menu item?

There generally are other ways to do theses things they are just more 
complicated. The context menu provides an easier way/or shortcut.

"Copy link location" - open link, then copy URL
"Copy image location" - open image location, then copy URL
"Open link in new browser" - ?

Comment 2

[Johnny Stenback (:jst)]

It is (or should be, and has been) possible to navigate between links on a page
with the "tab" key, so to "open link in new window" you tab to the link of
interest and push the alt key to get to the normal menu and select "open link in
new window" from there, I would imagine that this is really important to people
who are unable to use a pointing device (and also for keyboard only web-tv like
devices).

Comment 3

[jglick]

Cc'ing Lake, who is resonsible for the Keyboard navigation spec.

http://gooey/client/5.0/specs/keyboard/kybdnav2.htm

Comment 4

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to [e-mail].)

Comment 5

[Matthew T (active 1999-2002)]

`IMPORTANT: Contextual menus should never supersede menu bar items; there 
shouldn't be any items in a contextual menu which are not also accessible through 
the menu bar' <http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-56.html>.

`Right-click context menus are a useful addition to interfaces. They are intended 
to be an alternative means of accessing functions; as shortcuts, primarily for 
advanced users. They should never be required, and should always be used in 
conjunction with conventional menus. Otherwise, new users might never realize the 
functions are available, and they will have no keyboard access to the functions 
once they find them' <http://iarchitect.com/controls.htm#CONTROLS4>.

However, no Web browser that I know of has ever actually managed to follow this 
guideline, because there are a huge number of context menu items which apply only 
to (for example) an image which is part of a link, and putting them in the main 
menus could cause a fair bit of clutter with items which are hardly ever enabled. 
And to some extent, this bug would be solved by bug 36665, `Keyboard access to 
context menu' -- that still wouldn't work for the context menu for images though, 
since images in themselves are not something you can tab to.

If German accepts this bug, it will probably become a tracker for finding places 
in the main menus for all the various context menu items.

Comment 6

[shuang (gone)]

set to M18 for after PR2 fix.

Comment 7

[german]

For the reasons Matt mentions in his last paragraph I think contextual menus have 
been used in browsers to not only provide shortucts to otherwise accessible items 
but also to provide target specific options.
The older guidelines from MacOS make sense but Browsers are different from other 
apps like e.g Word or Draw programs as many items on a document cannot be 
selected without activating them, hence there is not main menu way of reflecting 
the selection and enabling the appropriate commands.
It otherwise would result in enourmous menu clutter if we had to make every 
single option accessible to say a region which is in an image map in an image 
which is in a cell which is in a table which is in a frame etc etc. 
So I agree that while not strictly conformant it provides the most usable 
solution.

Comment 8

[german]

I think this bug is invalid for the aformenetioned reasons. there will always be
items that only apply to the item being moused over and would overly cluttere
the menu as they are too specific.

Comment 9

[Matthew T (active 1999-2002)]

Verified invalid.

This is ok on an acessibility level only as long as it is possible to access all 
the context menus using the keyboard, by giving focus to them and then using bug 
36665. I've just filed bug 58997 for giving focus to images in Web pages for this 
purpose; please file other bugs if there are other areas where it is not possible 
to give focus to a particular area which has its own context menu. (Toolbars 
don't count.)

Comment 10

[Peter Trudelle]

So what is the reasoning here, is it that selecting/focussing them is
impossible, or that the menus would be too cluttered?  We have to do the
keyboard focus work for accessibility, so it will not be impossible. Some of
these items have been selectable/focussable all along, so I don't understand how
that argument ever applied. The clutter argument sounds like it could be better
solved by either trimming some feature bloat, or only offering the menu item
when the element is focussed.  The invalid resolution makes me wonder if UE just
disagrees that significant common features should be in the main menus.  If that
is the case, why not say so?  Just curious...

Comment 11

[Matthew T (active 1999-2002)]

The menus would become too cluttered. Consider, for example, where you'd put 
`Copy Image Location', or `Add Bookmark for Link', or `Show Only this Frame', 
in the main menu bar.

> Some of these items have been selectable/focussable all along, so I don't
> understand how that argument ever applied.

Because you have never been able to focus images (bug 58997).

> The clutter argument sounds like it could be better solved by either trimming
> some feature bloat,

If you tried to remove such features as `Copy Image Location', or `Add Bookmark 
for Link', or `Show Only this Frame', I think people would scream.

>                     or only offering the menu item when the element is
> focussed.

If you mean enabling/disabling the menu items, that wouldn't save any clutter. 
And if you mean actually showing/hiding the menu items, I imagine that would 
contravene just as many HIGs as the current behavior. :-)

Comment 12

[Nicolas Barbulesco]

(In reply to Matthew Paul Thomas from comment #11)

> The menus would become too cluttered. Consider, for example, where you'd put 
> `Copy Image Location', or `Add Bookmark for Link', or `Show Only this
> Frame', 
> in the main menu bar.

In an "Item" or "Object" menu, rather on the right.
A nice way to provide the contextual menu actions related to the right-clicked item to the people who cannot right-click.

Comment 13

[Philip Chee]

> A nice way to provide the contextual menu actions related to the right-clicked item to > the people who cannot right-click.

Shift-F10 opens the context menu. Also most Wintel keyboards have a context menu key these days.