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

VERIFIED FIXED in Firefox 3.6a1

Status

()

defect
VERIFIED FIXED
11 years ago
7 years ago

People

(Reporter: adelfino, Assigned: kliu)

Tracking

({verified1.9.1})

Trunk
Firefox 3.6a1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
blocking-firefox3.5 -
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

11 years ago
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
Reporter

Updated

11 years ago
OS: OpenBSD → All
Hardware: PC → All
Version: unspecified → Trunk
Reporter

Updated

11 years ago
Flags: blocking-firefox3?
Reporter

Updated

11 years ago
Summary: Inputs with type image don't give a context menu to save it → Inputs with type image don't give a context menu to save the image
You can get at the resources other ways, like with Page Info. The design decision in bug 404536 is sound.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → INVALID
Reporter

Comment 2

11 years ago
Seems reasonable to me.

Updated

11 years ago
Duplicate of this bug: 426896

Updated

11 years ago
Duplicate of this bug: 439659

Comment 5

11 years ago
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?
Duplicate of this bug: 440795
Assignee

Comment 7

11 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Assignee

Comment 8

11 years ago
Assignee: nobody → kliu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #326047 - Flags: review?(mano)
Assignee

Updated

11 years ago
Attachment #326047 - Flags: ui-review?(beltzner)
Reporter

Comment 9

11 years ago
(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.
Assignee

Comment 10

11 years ago
(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.  :)
Reporter

Comment 11

11 years ago
(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?
Assignee

Comment 12

11 years ago
(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 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)?
Attachment #326047 - Flags: review?(mano) → review+
Assignee

Comment 14

11 years ago
Oops, forgot about that; thanks Gavin.
Attachment #326047 - Attachment is obsolete: true
Attachment #326072 - Flags: ui-review?(beltzner)
Attachment #326047 - Flags: ui-review?(beltzner)
Assignee

Updated

11 years ago
Duplicate of this bug: 441577
Assignee

Updated

11 years ago
Duplicate of this bug: 441577

Comment 17

11 years ago
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

11 years ago
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

11 years ago
*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.
Reporter

Comment 20

11 years ago
If extensions need it, they can use their own magic; right?
Assignee

Comment 21

11 years ago
(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.
Reporter

Comment 22

11 years ago
(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.
Reporter

Comment 23

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

Sorry.
Assignee

Comment 24

11 years ago
(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

11 years ago
(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".
So _this_ is why I have been able to copy some images but not others!  This has been driving me nuts for months.
Blocks: 404536
Flags: blocking-firefox3.1?
(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?
Kai: what of comment 7 does this patch actually implement?

Comment 29

10 years ago
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
(In reply to comment #28)
> Kai: what of comment 7 does this patch actually implement?

The first option.

Comment 31

10 years ago
> 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.
Attachment #326072 - Flags: ui-review?(beltzner) → ui-review+
Flags: blocking-firefox3.1? → blocking-firefox3.1-
> 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

10 years ago
(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.
Attachment #326072 - Flags: review?(mconnor)
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 on attachment 326072 [details] [diff] [review]
w/ comment fix

Sorry, I didn't note that.
Attachment #326072 - Flags: review?(mconnor)
http://hg.mozilla.org/mozilla-central/rev/8b9317b5ab2e
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago10 years ago
Flags: in-litmus?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
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.
Attachment #326072 - Flags: approval1.9.1?
Duplicate of this bug: 480772
Comment on attachment 326072 [details] [diff] [review]
w/ comment fix

a191=beltzner
Attachment #326072 - Flags: approval1.9.1? → approval1.9.1+
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.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Posted patch TestSplinter Review
Browser chrome test to ensure the correct behavior on all form elements (including <input type=image>).
Attachment #369161 - Flags: review?(gavin.sharp)
Flags: in-litmus? → in-litmus-
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.
Attachment #369161 - Flags: review?(gavin.sharp) → review+
I'll address all of the comments upon landing.
Flags: in-testsuite? → in-testsuite+

Updated

10 years ago
Duplicate of this bug: 485675

Updated

10 years ago
Blocks: FF2SM

Comment 48

10 years ago
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

10 years ago
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
(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

10 years ago
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"
(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

10 years ago
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.

Updated

10 years ago
Duplicate of this bug: 487815

Updated

7 years ago
No longer blocks: FF2SM
You need to log in before you can comment on or make changes to this bug.