Closed Bug 583211 Opened 14 years ago Closed 14 years ago

Firefox 4: Html input type image only submits x and y, not name when clicked. Keyboard is okay. Firefox 3.6 submits all 3.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: anup, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre

Firefox 4.0 beta 2 and beta3pre (nightly from 29 Jul 2010) — as well as IE — do not send name/value for input type=”image”; only .x and .y coordinates are sent.

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

More info here:
http://www.onenaught.com/posts/382/firefox-4-bug-input-type-image-only-submits-x-and-y-not-name

Reproducible: Always

Steps to Reproduce:
1.Create a form with input type image.
2.Give the input name and value (value different to name helps to see this)
3.Make form a GET for easier viewing and submit to self
4.View page in different browsers pressing the image with mouse
5.Note the querystring no longer includes the name=value querystring that is included in Firefox 3.6.* and earlier.
6.Go back to form and tab to the input and press enter (keyboard)
7.Note the name/value IS submitted.

See http://www.onenaught.com/posts/382/firefox-4-bug-input-type-image-only-submits-x-and-y-not-name for more details and example.
Actual Results:  
When using mouse, the name/value of the input image is not submitted.

When using keyboard, the name/value is submitted.

Expected Results:  
Name/value of input type image should be submitted when clicked using mouse, as well as keyboard.

See this for more info, if it helps:
http://www.onenaught.com/posts/382/firefox-4-bug-input-type-image-only-submits-x-and-y-not-name
Summary: Html input type image only submits x and y, not name when clicked. Keyboard is okay. Firefox 3.6 submits all 3. → Firefox 4: Html input type image only submits x and y, not name when clicked. Keyboard is okay. Firefox 3.6 submits all 3.
Thanks a lot for this bug report!

However, our behavior is correct according to HTML5, which we're tracking: <http://www.whatwg.org/html/#form-submission-algorithm>, 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 <http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG>, component "HTML5 spec (editor: Ian Hickson)", or send an email to <whatwg@whatwg.org>.
Blocks: 547165
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
I have the same problem and my page is a regular XHTML page (no HTML5).
The problem is that i check if the name of the submit button is present in the posted variables to see if the user sent his form... now this doesn't work anymore (and for no apparent reason).

Why are HTML5 specs interferring with my XHTML pages? I believe this is a bug, at least when no HTML5 is involved in the page.
The HTML specification defines how browsers need to interpret and handle all HTML and XHTML pages, whatever their doctype. There is only one version of HTML, and that is the one defined in the HTML specification I linked to.

Also, as I understand it, the name will not be present if your visitors use Internet Explorer, so you can't avoid handling the case where the name isn't present.
Could anyone elaborate on how 4.10.22.4 1.3.3.6..7;

Append an entry to the form data set with the name namex, the value x, and the type type.

Append an entry to the form data set with the name namey and the value y, and the type type.

Can be read as: remove name and value from an image-button?
They're not "removed".  They're just never added.  In particular, for image inputs the steps followed are section 4.10.22.4 step 3.3 substeps 1-7.  Steps 7 says to skip anything other processing.  The "name and value" bit is added for other controls in step 9, which step 3.3.7 explicitly says to skip.
Boris, I understand the 'logic' now, I mis interpreted the steps 5-6 which only mention adding the x/y coordinates, not the 'value=value'.
The point is not if the rules say so or if they have changed or if they were misunderstood in 3.x and correctly interpreted in 4.x.  Ok, suppose they are now correctly interpreted in 4.x and x,y are transmited and name/value should not be transmitted.  Then why it is transmited on keyboard press submit and not transmitted on mouse click submit?  It just means inconsistency. It is nothing about any rules interpretation, it is plain inconsistency.
> Then why it is transmited on keyboard press submit

It's not.
he he, it is nothing about democracy or opinions.  It is a fact explained in point one and re explained above.  Keyboard input transmits x,y and name/value but mouse doesnt.
> he he, it is nothing about democracy or opinions

Indeed.

> Keyboard input transmits x,y and name/value

No, it doesn't.  I just looked at the code, and that's not what the code does.  I just tried a testcase, and for a keyboard submission the x and y are sent but the name/value is not.

If you think otherwise, please attach an HTML example showing the behavior you claim to happen actually happens.

In other words, the claim about keyboard input in comment 0 is just false.  That's not the behavior I observe.
Hi,

When I first logged this, the beta version I think (IIRC) was sending name as well when pressing enter on the focused image input, but I just tested on latest Firefox 4 (my original blog post has the same test I used then and now) and it definitely doesn't send name/value any more, so it is exactly same as mouse click. Maybe at some point it changed? (Either way, as someone else commented, on the server side you have to handle IE behavious anyway, so this has not become a big deal for me, personally)
Yeah, it's quite possible that b3 was buggy here.
What sad person said this isn't a bug, an Ex-Microsoft employee perhaps.

I don't care what the HTML5 standard says, it is common sense that the result should be the
same if either the keyboard or the mouse is pressed.

IE, Chrome, Safari and all, and I mean all the others agree on this, It is only you sad lot
who appear to of lost your way.

The sad end to what was a once great browser.
Well at least some conscious comment.  This discussion shows how humankind usually gets lost in vanities and fake illusions of power.  Hope you guys wake up from the hangover of being firefox programmers.
And I will let you know another shameful fact.  This post was started by me and misteriously someone else seems to be the initiator.  I really don't give a damn who pretends to be what, but something is rotten here.
> it is common sense that the result should be the same if either the keyboard or
> the mouse is pressed

And the result _is_ the same.  Did you even read the bug before commenting?
(In reply to comment #19)
> This post was started by me
> and misteriously someone else seems to be the initiator.

I am not sure if you are accidentally posting a comment against the wrong bug??? *I* initially reported this as can be seen by the description.

Since then, it has been corrected to me in the comments that FFx behaviour is per design. As per comments 14 and 15, the name not submitting in one case and then submitting in another is no longer an issue: it was probably an inconsistency in an early beta.

@bob:
> IE, Chrome, Safari and all, and I mean all the others agree on this

No, IE (at least older versions, not checked IE9) does not, nor does Opera, as also noted earlier!
The title of the bug is something I created and stated clearly mouse vs keyboard situation, which was again remmarked on post #10.  The text of the description has the steps I posted with EDITED content like the GET, suggestion which I acknowledge I did not write.  

More important. For me to be able to come and issue my post #10, is because I got an e-mail notifying me of the existence of the bug, meaning I had posted something  before post #10, a previous post WHICH YOU CAN'T FIND: Do you follow?
energizamx, you filed bug 610005 which was marked as a duplicate of this bug (see comment 2).  At that point you were added to the cc list of this bug.  This bug is not the bug you filed.

I strongly suggest you refrain from screaming at people and from spamming this bug in general.....
Thanks Boris.  I accept my mistake.  But it has nothing to do with the status of this issue RESOLVED INVALID and a complete nonsense away of the bottom line.  Just the fact that Anup (to whom I publicly appologize) and I found the same behaviour in 2 different locations of the planet, proves the issue was a fact.  The remaining verbosity is unnecesary and whomever responsible of the problem has to simply fix it and appologize as well.  Spam means a complete different thing.  I did not come here to sell potatoes.  I solved the problem on my own and came here to notify about it, which is -I suppose- the aim of this forum.
Energizamx, probably commenting on the upstream bug at W3C might solve this situation. I hate this situation as well, but I guess blaiming Firefox for suddenly implementing this standard is not the right way to go.
Thanks Stefan.  I don't blame Firefox for implementing a standard even though it is weird.  I do complain how complicated explanations come out from Firefox to say something simple: "the standard says to only send coordinates and not value. The keyboard vs mouse is an issue that is solved already -update your FF-, or will be solved in x time". Thanks again, for me the thing is over.
Since upstream claims because 3 browsers have converged now. Opera, IE and Firefox, and the HTML5 editor is working at Opera, a browser that never implemented this functionality. I would suggest Firefox restoring the above functionality. Which make 3 browsers implementing it, and IE and Opera to follow common sense.
Stefan, I don't see us changing away from the spec. If you want us to change, I suggest reopening the W3C bug and focusing on technical arguments, rather than "common sense" and personal attacks.
(Also, get your facts straight. The editor doesn't work for Opera.)
Ms2ger, the technical fact is in my first reply. The person that closed the bug is has an @opera address and claims an 'Editor Response'. Given that he argues based on 3 browsers already changed, actually only Firefox did, the reasoning makes absolutely no sense. And the common sense approach still holds, every input field gets its name/value pair posted, except image in HTML5.
> The person that closed the bug is has an @opera address and claims an 'Editor
> Response'.

See <http://lists.w3.org/Archives/Public/public-html/2011Jun/0218.html> and <http://lists.w3.org/Archives/Public/public-html/2011Jun/0285.html>.  Anne is not the editor, but has been delegated to help the editor with some issues.

We are not going to change behavior here unless the spec changes, and would likely argue against the spec change.  One behavior change was needed somewhere, to get compat, but at this point the path of least change for web developers is for WebKit to change to follow the spec.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.