424101 - Inputs with type image don't give a context menu to save the image

Status: VERIFIED FIXED

(Firefox :: Menus, defect)

Description

[Andrés Delfino]

User-Agent:       Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.8.1.6) Gecko/20070819 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.8.1.6) Gecko/20070819 Firefox/2.0.0.6

After bug 404536 being fixed, inputs with type image don't give a context menu to save it. This is a regression from Firefox 2.0.

Reproducible: Always

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

You can get at the resources other ways, like with Page Info. The design decision in bug 404536 is sound.

Comment 2

[Andrés Delfino]

Seems reasonable to me.

Comment 5

[Mike Todd]

So this was a purposeful design decision?  That doesn't make sense to me -- why would you want to make it harder for a user to view/copy an image, even one that is a form input?  I use the "View image" context item for form images very frequently in web development work, and I see no reason to remove all context menus from image input elements.  Is there at least some option to make it to where these images will bring up the standard image context menu?

Comment 7

[Kai Liu]

I really think we should revisit this bug.  I don't think that INVALID is the right thing here: being able to accomplish things via the media tab can only be classified as a cumbersome workaround.  At the very least, we should except image submit buttons from the menu hiding because image submit buttons do have relevant contextual actions, and the impetus of bug 404536 was that the menu should not be shown because there are no relevant contextual actions, and there clearly are here.

But on a more general level, I think it may be worthwhile for us to consider other cases as well where there could be relevant contextual actions, such as when an extension adds them (see bug 433168).

So here's what I propose:
1) Re-open this bug so that we can exempt image submit buttons from the menu hiding because this is one case where there will always be relevant contextual action.
2) Explore ways to take care of the cases where there might be relevant contextual actions in bug 433168.

Comment 8

[Kai Liu]

Attachment: input type="image" has relevant context

Comment 9

[Andrés Delfino]

(In reply to comment #7)
> I really think we should revisit this bug.  I don't think that INVALID is the
> right thing here: being able to accomplish things via the media tab can only be
> classified as a cumbersome workaround.  At the very least, we should except
> image submit buttons from the menu hiding because image submit buttons do have
> relevant contextual actions, and the impetus of bug 404536 was that the menu
> should not be shown because there are no relevant contextual actions, and there
> clearly are here.

No. The reason behind bug 404536 was operative system consistency, to blend off-line applications better with the OS.

Comment 10

[Kai Liu]

(In reply to comment #9)
> No. The reason behind bug 404536 was operative system consistency, to blend
> off-line applications better with the OS.
> 

1) We should not blindly follow that because an online app is not necessarily the same paradigm as an offline app; there needs to be a better reason than just "consistency" (such as, "why show a menu when there is no contextual action").

2) Offline apps don't have image submit buttons.  :)

Comment 11

[Andrés Delfino]

(In reply to comment #10)
> 2) Offline apps don't have image submit buttons.  :)

Aren't off-line apps nothing more than Web pages tweaked to work off-line?

Comment 12

[Kai Liu]

(In reply to comment #11)
> (In reply to comment #10)
> > 2) Offline apps don't have image submit buttons.  :)
> 
> Aren't off-line apps nothing more than Web pages tweaked to work off-line?
> 

Er, sorry, I meant native OS applications by that.  However you slice it, I still don't think that hiding the context menu when there are relevant items is the right thing to do.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 326047 [details] [diff] [review]
input type="image" has relevant context

>diff -r ac94b12c2800 browser/base/content/nsContextMenu.js

>   // Returns true if aNode is a from control (except text boxes).
>   // This is used to disable the context menu for form controls.
>   isTargetAFormControl: function(aNode) {
>     if (aNode instanceof HTMLInputElement)
>-      return (aNode.type != "text" && aNode.type != "password");
>+      return (aNode.type != "text" && aNode.type != "password" &&
>+              aNode.type != "image");

Update the comment as well (text boxes and images)?

Comment 14

[Kai Liu]

Attachment: w/ comment fix

Oops, forgot about that; thanks Gavin.

Comment 17

[Brian Wright]

There are plenty of reasons to show a contextual menu on an input type image.  The least of which showing the menu would allow the copying of the image's URL for use in other contexts (i.e., blogs, twitter, wikipedia or in emails)... even if the menu doesn't allow saving the image.  Not to mention, as was suggested above, that any add-on may add additional menu services.  

As of now, you can't drag an input type image out of the window (like you can with an actual image) and create a link or copy it and, as I said, you can't copy the URL of the image for later use.  I also think that the contextual menu should at least appear (even if everything is greyed out).  This at least gives consistency to the user experience so that you know a menu will appear when you right click on anything.  For certain things to not show a menu seems inconsistent.

Further, once sites know they can embed images in an input type image to prevent copying, sites will start using this (if they haven't begun already).  MSIE will likely follow suit and institute this same behavior preventing most image copying (or even copying the image's URL) on the web.  I can easily see sites like Flickr begin to embed their images on the page as an input type image preventing any downloads of images with the exception through an explicit download link.

If the Firefox developers really want to give the image holders a real methodology to protect their images, then the better design principal is to provide an actual extension to any img tag or input type image tag (or any other tag to embed images) to prevent copying and also prevent display of the image URL in show source. For example, IMG SRC="http://blablah/foobar.jpg" PROTECT=ON ... Using a design like this would grey out the ability to save the image from the contextual menu and also prevent the source from showing the URL. This system gives content holders a valid mechanism to control the use of their images and also gives the user a consistent contextual menu experience throughout Firefox.

Thanks.

Comment 18

[Pedro De Almeida]

Another relevant reason is that some extensions interact with inputs through the contextual menu. For example, developers use the contextual menu to rapidly "inspect" inputs (particularly with the great Firebug extension). Removing this accessibility seriously decreases development productivity.

Comment 19

[Tim McCormack]

*Not* having a context menu will be a jarring user experience. I know this because it happened to me, when I was trying to inspect something with Firebug.

Offline apps should have their own logic. Online apps will not only *always* have something in the context menu (Back/Forward/Stop/Reload), but you never know what future extension might put something in there.

Comment 20

[Andrés Delfino]

If extensions need it, they can use their own magic; right?

Comment 21

[Kai Liu]

(In reply to comment #20)
> If extensions need it, they can use their own magic; right?
> 

No, that would be bug 433168.  The difference between this bug and 433168 is that for form buttons, there are no associated contextual actions unless they are added by an extension.  <input type="image"> should have (and always used to have) the same contextual actions as <img>; these contextual actions are not added by extensions.  See comment 7.

Comment 22

[Andrés Delfino]

(In reply to comment #21)
> (In reply to comment #20)
> > If extensions need it, they can use their own magic; right?
> > 
> 
> No, that would be bug 433168.  The difference between this bug and 433168 is
> that for form buttons, there are no associated contextual actions unless they
> are added by an extension.  <input type="image"> should have (and always used
> to have) the same contextual actions as <img>; these contextual actions are not
> added by extensions.  See comment 7.
> 

So your answer should have been, per: "there are no associated contextual actions unless they are added by an extension".

Users can always save images trough page info, the proposed solution is inconsistent with native forms.

Comment 23

[Andrés Delfino]

> So your answer should have been, per: "there are no associated contextual
> actions unless they are added by an extension", Yes.

Sorry.

Comment 24

[Kai Liu]

(In reply to comment #23)
> So your answer should have been, per: "there are no associated contextual
> actions unless they are added by an extension", Yes.
> 
No.  That's the exact opposite of what I said.  There ARE associated contextual actions for <input type="image">, which is what this bug is about.

> Users can always save images trough page info
>
Which is cumbersome and represents a regression of usability from Firefox 2.  And it's not just image saving--there are other image-related contextual actions that are lost.

> the proposed solution is
> inconsistent with native forms.
> 
I'm not sure what you mean by this.  As I emphasize, this bug only affects <input type="image"> and will not affect "native" form elements.  There are other form elements that retain their context menus because they still have inherent contextual actions (e.g., text boxes).  Image-based submit buttons have traditionally been presented to the user no differently than an image-based link, and why shouldn't it?  Just because it submits information to a URL instead of directly going to a URL doesn't change the fact that it's still an image, and the user may wish to do certain things to this image.  Killing the context menu when there are useful, relevant contextual actions just because of a distinction between an image link and and image submit makes no sense.

I wonder if there is something being lost in the translation here, because your comments seem to suggest that you are talking about bug 433168, which is a different, though slightly related, issue--I don't understand why we are talking about extensions in this bug, as they are irrelevant here.  The point still remains that, unlike other form elements, <input type="image"> DOES have native, inherent contextual actions, and that all of these actions (including, but not limited to, image saving) have been lost.

Comment 25

[Simon]

(In reply to comment #22)
> Users can always save images trough page info, the proposed solution is
> inconsistent with native forms.

If it can be done simple, why make it so complicated?
To be honest, I went back to FF 2.0 just because of this new "feature".

Comment 26

[Boris Zbarsky [:bzbarsky]]

So _this_ is why I have been able to copy some images but not others!  This has been driving me nuts for months.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #26)
> So _this_ is why I have been able to copy some images but not others!  This has
> been driving me nuts for months.

You try to copy a lot of images that are actually form input types? Really?

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Kai: what of comment 7 does this patch actually implement?

Comment 29

[Patrick Franklin]

This isn't just about copying images.  Extensions don't work when you right click on the image.   The impact is far greater than just copying images.  I don't care if "Copy Image" doesn't show up, but I would like the event to be fired. 

Thanks,
Patrick

Comment 30

[(no longer active)]

(In reply to comment #28)
> Kai: what of comment 7 does this patch actually implement?

The first option.

Comment 31

[Simon]

> No. The reason behind bug 404536 was operative system consistency, to blend
> off-line applications better with the OS.

People around keep asking me how to save images because of this. I explained that there was something called input-typed image and they all got confused. To the end users, both types of images look the same and they SHOULD have the same response. This is what "consistency" means.

Comment 32

[Boris Zbarsky [:bzbarsky]]

> You try to copy a lot of images that are actually form input types? Really?

Not a lot, but some, yes.  Of course there's no way for me to tell up front what sort of image it is; all I know is it's an image linking somewhere.

Comment 33

[Brian Wright]

(In reply to comment #32)
> > You try to copy a lot of images that are actually form input types? Really?
> 
> Not a lot, but some, yes.  Of course there's no way for me to tell up front
> what sort of image it is; all I know is it's an image linking somewhere.

I think this is probably the strongest point.  Users cannot distinguish the difference between an <a><img></a> and an <input type=image> in nearly every case.  Both types of images look identical in the browser and both may ultimately link you to something else.  Input images don't always look like buttons or have unique distinguishing characteristics.  Unless the web designer specifically indicates that the image is an input type, users can't tell the difference on a page.

Because there is no clearcut visual distinction between the two images when rendered, it is completely confusing to a user why a context menu appears in one case, yet not in another (even on the same page).  Few people will know to come here to this site and dig through these myriads of bugs to find this thread and understand this specific design choice.

The shear confusion surrounding this bug should be enough to show that this code change, while somewhat understandable, was not the best design choice.  Sometimes you have to admit that even though a code change has a valid and logical reasoning, the ultimate outcome does not work as intended.

Comment 34

[Nochum Sossonko [:Natch]]

Comment on attachment 326072 [details] [diff] [review]
w/ comment fix

This has r+ from gavin already, the new patch is just a comment fix, why the extra review?

Comment 35

[(no longer active)]

Comment on attachment 326072 [details] [diff] [review]
w/ comment fix

Sorry, I didn't note that.

Comment 36

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/8b9317b5ab2e

Comment 37

[(no longer active)]

Comment on attachment 326072 [details] [diff] [review]
w/ comment fix

This is a very simple fix for an issue which has annoyed many users (including bz!).  Requesting approval to land on 1.9.1.

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 326072 [details] [diff] [review]
w/ comment fix

a191=beltzner

Comment 40

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a0e5d1df07d2

Comment 41

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with builds on Windows and OS X:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre ID:20090318052249

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090322 Shiretoko/3.5b4pre ID:20090322140038

Ehsan, I believe that this should be possible to test with an automated test.

Comment 42

[(no longer active)]

Attachment: Test

Browser chrome test to ensure the correct behavior on all form elements (including <input type=image>).

Comment 43

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 369161 [details] [diff] [review]
Test

>diff --git a/browser/base/content/test/browser_bug424101.js b/browser/base/content/test/browser_bug424101.js

>+  newBrowser = gBrowser.getBrowserForTab(newTab);

not declared?

>+      if (expected)
>+        ok(contextMenu.shouldDisplay, "The context menu should appear on an input with " + type + " type");
>+      else
>+        ok(!contextMenu.shouldDisplay, "The context menu should not appear on an input with " + type + " type");

I'd just do:
is(expected, contextMenu.shouldDisplay, "context menu behavior for <input type=" + type + "> is wrong");

(for both methods)

>+  newBrowser.contentWindow.location = "data:text/html,test";

Kind of odd to start the load this way instead of using loadURI, guess it doesn't really matter.

Comment 44

[(no longer active)]

I'll address all of the comments upon landing.

Comment 45

[(no longer active)]

Test landed on mozilla-central: <http://hg.mozilla.org/mozilla-central/rev/a8b2f37e0348>

Comment 47

[(no longer active)]

Test landed on mozilla-1.9.1: <http://hg.mozilla.org/releases/mozilla-1.9.1/rev/17d024152d0a>

Comment 48

[Markus Peter]

Just for the record, I wanted to add another argument about why input type="image" should not be treated like other form controls: While it is indeed usually abused for showing buttons, it's not its intention and not its sole purpose. The original change obviously assumed, all elements of this type are buttons anyway. input type="image" is for image maps, and then, of course, a image should still have its context menu, even though it acts like a server-side image-map.

We for example have a site with even photos where people can mark themselves on the photos. For simplicity, we used server-side image maps - now, with the Firefox 3.0 behaviour, we'd either have to use ugly JavaScripts for sending the coordinates to the server or users cannot use their context menus anymore to save the images.

Comment 49

[L. Mohan Arun]

I use Input type image for submit buttons in shopping cart, and every browser user like myself needs to see any image properties through a right click, or to save the image being used for the submit button. If it is an image, it should behave like any other image on the page, i.e., open context menu on right click. I guess this bug has been fixed now, in the next release of FF

Comment 50

[(no longer active)]

(In reply to comment #48 and comment #49)
Please check the status of the bug before commenting here.  This bug is fixed, and the fix will be included in the upcoming Firefox 3.5.  Please stop posting comments on this bug unless you have something to say about the fix.  Thanks!

Comment 51

[L. Mohan Arun]

There is no rule that says, one cant comment on a "fixed" bug, it is there for the record, in combination with the other earlier comments, about how and why the bug went from "wontfix" to "fixed"

Comment 52

[(no longer active)]

(In reply to comment #51)
> There is no rule that says, one cant comment on a "fixed" bug, it is there for
> the record, in combination with the other earlier comments, about how and why
> the bug went from "wontfix" to "fixed"

I did not say that _no_ comment should be posted on a fixed bug.  Please see <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> section 1.1.

Comment 53

[L. Mohan Arun]

It says "Unless you have something constructive and helpful to say, do not add a comment to a bug." In comment 49 I have said how input type image is used by me, related to topic of bug. It goes further as to *why* this is necessary option for input type image, so if somebody decides in the future this is against the 'standards' they can read through all the reasoning posted.