Firefox 4 change: input type image only submits x and y, not name when clicked. Keyboard as before

(This post is partly a note to self, and a place to further describe the Firefox bug I raised.)

Update 1 30th July, 2010: “not a bug, it’s a feature”! See below for more, but the gist of it is that Firefox’s behaviour here is right according to the HTML 5 specs, but not according to the HTML 4.01 specs…

Update 2 25th May, 2015: There’s a video at the end of this article demonstrating one of the workarounds I listed, courtesy of CSS training company, Webucator.

The problem change

Firefox 4.0 beta — as well as IE and Opera — do not send name/value for input type=”image”; only .x and .y coordinates are sent.

Note, this is when clicking the input image with a mouse. When navigating using keyboard, focusing on it, and pressing enter, then the name does get submitted.

Earlier Firefox, Chrome (latest) do send name/value, which is what we’d expect…


This form submits using a GET so you can see the submitted name/value pairs in the querystring:

Click this:

What does W3C spec say?

17.4.1 Control types created with INPUT says this for input type image:

When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where “name” is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.

The previous quote implies name=value should not be sent for input type=image

But 17.4 The Input Element says this as part of the input name attribute formal definition:

 name        CDATA          #IMPLIED  -- submit as part of form --

That implies the name should be submitted too, even for input type=image (and assuming that, then the value of the input should be submitted too, which seems to be confirmed by section 17.13.2 Successful controls in the spec, which notes: A successful control is “valid” for submission. Every successful control has its control name paired with its current value as part of the submitted form data set.)

So, I think Firefox 4 has introduced a bug…?

Update: not a bug

The bug I raised has been updated and turns out that this is per HTML 5 spec, while I was comparing what I saw with the implementations in earlier versions of Firefox and with the HTML 4.01 spec…

IE (and Opera) also only send .x and .y, so I guess they settled on that given most sites are probably still catered for/assume IE as the predominant browser…


One possible workaround is this, but ugly:

  1. Detect the browsers to do this for (feature detection would be better…)
  2. Capture the form submit event and find the button that caused this, or capture the button click event
  3. Append a hidden input like this (jQuery example, assuming button is the button you have captured):

    $(form).append('<input type="hidden" name="' + + '" value="' + + '" />').submit();

If you’ve already been working around this for IE, as the problem has been there for ages, then apply this for firefox 4 too (annoying and ugly to do browser specific code, I know)

Third workaround: don’t use input type=image, use input type=submit + CSS, or button etc.

Update: May 2015: Nat Dunn of Webucator, a company that provides CSS training, has created a video demonstrating the problem and using the input type=submit + CSS alternative:

Thanks for the mention, Nat!

6 thoughts on “Firefox 4 change: input type image only submits x and y, not name when clicked. Keyboard as before

  1. That was quick. The bug was marked as invalid because their behaviour follows the HTML 5 spec, whereas I was looking at the HTML 4.01 spec…

    This is the comment in the bug report:

    However, our behavior is correct according to HTML5, which we’re tracking:, step 7, substep 3 requires just image-button.x and image-button.y to be appended to the /form data set/, which will be submitted.

    It looks like the specification follows IE and Opera in this case. If you’d like to see this changed, please submit a bug to, component “HTML5 spec (editor: Ian Hickson)”, or send an email to [email protected].

    Given IE (and Opera) do it this way anyway while webkit and gecko did not, I guess it was choosing one way or the other and with IE being still so popular many existing sites might not break as a result…

    So one of the above workarounds it is then… or ponder on whether it is worth getting this changed…?

    So, updating title to reflect this is a change to be aware of…!

  2. I had this issue with submit just after updating to Firefox 4. My workaround was a little more simple (in my opinion)…it also works across the browsers. I just made the submit button into just that…a button.
    Notice the class. I didn’t like the automatic styling that the browsers give to buttons so I stripped the background, margin, padding, and border in a simple style sheet. Now it works just great! Hope this helps someone!

Comments are closed.