Open Bug 997741 Opened 11 years ago Updated 9 years ago

Make 'Copy Image' popup menu item less ambiguous

Categories

(SeaMonkey :: General, enhancement)

Product:
SeaMonkey
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

Details

In doing a little research for a bug I was about to post as "Add 'Copy Image Location' popup menu item for images" (given that Firefox has this but not SeaMonkey), I discovered that the current behaviour seems to be "by design", a design that I think is ambiguous and could do with improvement. The main discussion on this was done a long time ago, in bug #135300. The current behaviour of 'Copy Image' is this: When the 'Copy Image' popup item is clicked for an image in an HTML document's contextual popup menu, code gets executed in utilityOverlay.js: http://mxr.mozilla.org/comm-central/source/suite/common/utilityOverlay.js#1807 ... that ultimately (after a VERY long trip through the rabbit warren) gets to nsDocumentViewer here: http://mxr.mozilla.org/comm-central/source/mozilla/layout/base/nsDocumentViewer.cpp#2594 ... and calls ImageCopy here: http://mxr.mozilla.org/comm-central/source/mozilla/content/base/src/nsCopySupport.cpp#395 Now ImageCopy is called with its copy flags set to COPY_IMAGE_ALL; they are defined here: http://mxr.mozilla.org/comm-central/source/mozilla/docshell/base/nsIContentViewerEdit.idl The thing is, I think this behaviour is unintuitive. When I read 'Copy Image', I just imagined that the raw bitmap data would be copied to the clipboard; instead, as can be seen from the code, SeaMonkey copies three 'flavors' of data to the clipboard at once: HTML, text, and the raw bitmap. When I try to then paste into, say, LibreOffice Writer, it actually favours the HTML, meaning that I get a reference to the image that has to be loaded from the internet, rather than the bitmap data, pasted into the document. I would expect this if I had included the image as part of a highlighted selection of the webpage, then copied, but I would not expect it when just right-clicking on the image; I want the image data, not a reference to it. Nor do I find it intuitive that the text data that will be copied to the clipboard will be the image's URL; it could equally make sense to put a base64-encoded version of the image into the clipboard as text data, as can be generated (for example) here: http://software.hixie.ch/utilities/cgi/data/data Sure, you can use "paste special" to get at the version of the data you want, but not all applications will have that option, and it's just unintuitive; if I copy an image, I expect the image data to be pasted by default, not some HTML reference to it. OK, putting the URL in as plain text for convenience at the same time as copying the image makes sense, but there should still be a more intuitive way to get at the URL. So I propose that 'Copy Image' be turned into a submenu, with a structure similar to this: Copy Image -> Copy Image as Bitmap Copy Image Location Copy Image HTML --- Copy all of the above * * same behaviour as 'Copy Image' now That way the user is basically given the option to choose which copy flags get passed to ImageCopy, and this is much clearer. It's not too hard for the user to figure out what's going on, even though it involves a slight popup menu change. Right now, Firefox actually has more flexibility in what a user can copy because it has both 'Copy Image' and 'Copy Image Location' entries. Wouldn't it be nice for SeaMonkey to have this flexibility (and more) too?
AFAIK, "Copy Image" puts all those flavors onto the clipboard, it's more a problem what's pasted into the receiving application to pick the desired flavor (which sometimes isn't the case). In contrast, "Copy Image Location" only copies the URL as text (which technically is on the clipboard already but only chosen if you paste, let's say, into Wordpad; pasting into MS Paint takes the Bitmap; pasting into Thunderbird takes the HTML code, though the bitmap may be better here, but that's another bug; etc.). Thus, I'd rather think of more flexibility with a "Paste As" feature to actually pick the "right" one from the flavors available on the clipboard (that may be pending as another bug already).
(In reply to Jeremy Morton) > Sure, you can use "paste special" to get at the version of the data you > want, but not all applications will have that option, and it's just > unintuitive; if I copy an image, I expect the image data to be pasted by > default, not some HTML reference to it. Eh, ok. I should have read more carefully, you've considered that in your description already. Nevertheless, it looks more like a workaround to accommodate limitations of applications which are unable to explicitly pick a flavor on their own (including Gecko applications, unfortunately).
Well, I'm not sure I agree with the 'workaround' characterization; even if all applications did give you the option to select what flavour to paste each time you pasted, that would still be a potentially annoying extra step when pasting. And, as you said, some applications don't, and almost all applications that have a "paste special" option will still have a default "paste" option that will just choose one of those flavours, which may be an unexpected one.
Point taken, though the context menu is quite a bit crowded already, especially if a link is associated with the image. "Copy Image Location" should be readily available as it's used by Firefox, I don't know if the core code provides for a plain "Copy as Bitmap" already. I don't see the purpose of a separate "Copy as HTML" which in general resolves just to <img src="Image Location"> and is present as flavor on the combined version anyway already.
Our context menu is big enough already without extra items being added to it. However I would consider a preference for which flavours to copy.
I thought you'd say something like that, which is why my proposal is for a submenu, not just new menu items. Come on, it's not that bad! :-) Anyway, SeaMonkey is meant to have more options than Firefix, it's not meant to be minimalist.
I meant Firefox.
(In reply to Jeremy Morton from comment #6) > I thought you'd say something like that, which is why my proposal is for a > submenu, not just new menu items. Come on, it's not that bad! :-) Anyway, > SeaMonkey is meant to have more options than Firefix, it's not meant to be > minimalist. Freudian slip? I'd vote for a submenu too. I know Neil doesn't like context submenus, but a one level deep submenu isn't too bad and I can think of ways this can be used in the context menu. I think utility outweighs theoretical UX considerations here.
Since we were wondering in the morning about the acceptable style of context submenus, there actually is a precedence in the Toolkit code with the about:config context menu. If you open it, you can select New > { String, Integer, Boolean }. Not a context menu, but Thunderbird has special cases in their [≡] application button. The "Options" or "Preferences" menuitem (depending on the platform) will open the pref dialog by default, but also has a submenu associated with it for further functions. Translating the latter into the context here (no pun intended), if you stop at the "Copy Image" you'll get the default action (put all flavors onto the clipboard), otherwise slide to the right to open the submenu and pick the specific flavor you want the image to copy in.
(In reply to rsx11m from comment #9) > Translating the latter into the context here (no pun intended), if you stop > at the "Copy Image" you'll get the default action (put all flavors onto the > clipboard), otherwise slide to the right to open the submenu and pick the > specific flavor you want the image to copy in. Sounds like that would require some kind of special type of popup menu. Normal popup menus are either links to submenus, or command items; they can't be both.
Maybe, I don't know how Thunderbird implemented that.
(In reply to Jeremy Morton from comment #10) > Sounds like that would require some kind of special type of popup menu. > Normal popup menus are either links to submenus, or command items; they > can't be both. You can put a listener on the menu and then check if the target is the menu itself or from the submenu->menuitems. Also I vaguely remember seeing a Firefox Australis screenshot with some sort of fancy panel-like context menu.
(In reply to rsx11m from comment #11) > Maybe, I don't know how Thunderbird implemented that. It's called a split menu. Originally from Firefox. Another way of avoiding a submenu: https://addons.cdn.mozilla.net/img/uploads/previews/full/134/134088.png?modified=1397418977
Another option is to have the main action as the top item in the submenu (followed by a separator), as when navigating the mailbox hierarchy with "Copy To" or "Move To": if a folder is further subdivided, "Copy Here" or "Move Here" stands at the top of the list.
You need to log in before you can comment on or make changes to this bug.