562711 - Investigate which context menu items can be hidden in which cases.

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Robert Kaiser]

In 487692, we found out that sometimes it's hard to find correct accesskeys for some items and started thinking of possibly hiding some entries in some cases to make the whole context menus less cumbersome and possibly a bit less overloaded.

Note that we need to base arguments on actual use cases, not on potentially clashing accesskeys or unbased personal likings.

I'm copying the relevant comments here:

---  [e-mail]  ---  2010-04-23 12:59:21 PDT --- Comment 14

Created attachment 441117 [details] [diff] [review]
More juggling

[...] But I then had to tweak nsContextMenu.js so that View Selection Source
didn't appear on an image, Reject popup windows didn't appear on a textbox and
Copy didn't appear on an image, and also I made it so Search web for... didn't
appear on a link (they both use S). [...]

---  Robert Kaiser --- 2010-04-24 08:34:54 PDT --- Comment 17

[...]

I'm now going through all cases the patched test after my
attachment 440918 [details] [diff] [review] would cover, and try to reason about all entries we're
showing there at the moment, listing all IMHO questionable ones here.

So, here's my result and questions:

// Context menu for plain text

Looks reasonable.

// Context menu for text link

"context-bookmarkpage", "context-savepage", "context-sendpage"

Are those reasonable here? Shouldn't people always easily be able to click
outside of a link to do those instead? Can't they even be confusing due to
their similarity to the same actions on the link target?

// Context menu for text mailto-link

Same as for text links, though less confusion.

// Context menu for text input field

Looks reasonable.

// Context menu for an image

"context-bookmarkpage", "context-savepage", "context-sendpage" are again
somewhat questionable, but thinking about popups having an image (even a linked
one?) over their whole size and no top-level menu, I can see some reasoning for
wanting this.
I also disagree with removing "View Selection Source" from images, as I tend to
use that point to see the markup behind certain elements on screen, and that
includes images.

Note: No selections in the test so far, so "View Selection Source" is UNTESTED
right now.

// Context menu for an image with a link

Do we really need the whole list of image items here? I wonder if it would be
OK to just leave "View Image" here and remove all other image-related items
(context-*image, contest-setWallpaper). People wanting those actions can always
"view image" and do those things from there.

// Context menu for an image with a mailto: link

Same as above, can we remove all image items except "View Image"?

// Context menu for a canvas

Looks reasonable (mostly, after comparison with FF).

// Context menu for a video

Looks reasonable.

// Context menu for an iframe

Looks reasonable.

--- Robert Kaiser --- 2010-04-24 08:45:27 PDT --- Comment 18

(From update of attachment 441117 [details] [diff] [review])
As said in comment #17, I don't agree with the change to
"context-viewpartialsource-selection", I'm also not convinced by the
"context-searchselect" change as I can easily come up with use cases where I'd
want that.
The "popupwindow-reject/allow" change seems reasonable, though, but
"context-sep-popup" needs to be hidden on text inputs as well, then.
I'm also not sure about removing "context-copy" from images, I don't see why it
would be less useful there than elsewhere.

--- [e-mail] --- 2010-04-24 12:30:31 PDT --- Comment 19

(In reply to comment #18)
> The "popupwindow-reject/allow" change seems reasonable, though, but
> "context-sep-popup" needs to be hidden on text inputs as well, then.
Good point.

> I'm also not sure about removing "context-copy" from images, I don't see why it
> would be less useful there than elsewhere.
I thought it was justified on the basis that "Copy Image" already copies it in
text and HTML format. (I can't justify the other changes.)

[...]

--- [e-mail] --- 2010-04-24 15:32:19 PDT  --- Comment 21

[...]

(In reply to comment #17)
> Shouldn't people always easily be able to click
> outside of a link to do those instead?
But then again this is almost justification for not allowing Search Web on a
link or View Partial Source on an image ;-)