Open Bug 562711 Opened 12 years ago Updated 12 years ago
Investigate which context menu items can be hidden in which cases
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: --- email@example.com --- 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. --- firstname.lastname@example.org --- 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.) [...] --- email@example.com --- 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 ;-)
You need to log in before you can comment on or make changes to this bug.