57795 - Mozilla does not submit value for successful image controls in HTML 4.01 documents[form sub]

Status: VERIFIED FIXED

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

Description

[patrik]

When an image control is clicked in an HTML 4.01/XHTML document, it's value
should be submitted. Mozilla does not do this. HTML 3.2 but this changed in HTML
4.01, which never gives an exception for image controls (AFAICT).
For those who are interested, Mozilla shares this bug with (at least) Netscape
4.75, IE 5, lynx, links, w3m, w3 and konqueror.
The URL is a page that lets you click a button and then tells you whether your
browser submits the value or not (using PHP).

Comment 1

[Brian Wilson]

HTML4 does not explicitly *require* the value to be submitted. It *does* say in 
17.4.1 "Control types created with INPUT" 
(http://www.w3.org/TR/html4/interact/forms.html#h-17.4) that: 

"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."


It does not *prohibit* the value attribute from being submitted (it actually 
doesn't make any reference to the value attribute in the spec there), but no 
browsers do that...if it were to, the name attribute would be overloaded even 
more thus:
(where the first value is the form field name, and the second is the value 
passed for it):
   name.x, x-coord
   name.y, y-coord
   name, value

One last side consideration is: what should be passed if a pointing device is 
NOT used? Say, if the keyboard is used to activate the image? I tried that in 
NN4.x, IE5 and Mozilla build 2000102404 and Mozilla/IE5 passes .x/.y values of 
zero. NN4.x did not allow keyboard navigation to the input image element, so 
that scenario is moot.

I think the question to be asked in this boundary case is:
"what should happen when a pointing device is NOT used to activate this INPUT 
element?"

Comment 2

[Hixie (not reading bugmail)]

0,0 is what the spec says should be sent for image maps triggered by keyboard, 
consistency would suggest that would be a good plan for this too.

Comment 3

[patrik]

From the standard
(http://www.w3.org/TR/html4/interact/forms.html#successful-controls):
"17.13.2 Successful controls

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. A successful control must be defined within a FORM element and must have a
control name.

However:
[...]
If a form contains more than one submit button, only the activated submit button
is successful.
[...]"

An image control is defined within a form, and can have a name. If it does, it
is successful, unless we consider it to be a non-activated submit button. Now,
the standard does not specify what it takes for a submit button to be activated,
but to suggest that a graphical submit button doesn't get activated under the
same circumstances that will activate a non-graphical one would be silly.

Of course this can be worked around by using a button element, and noone else
supports correct behaviour, but it's still a bug, AFAICT.

Comment 4

[Keyser Sose]

So is this a problem or not?

Comment 5

[rods (gone)]

reassigning

Comment 6

[Asa Dotzler [:asa]]

setting bug status to New

Comment 7

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 8

[John Keiser (jkeiser)]

I say treat it as a graphical submit button.  Patch forthcoming.

Comment 9

[John Keiser (jkeiser)]

Taking bug

Comment 10

[John Keiser (jkeiser)]

Attachment: Patch

This makes input type=image submit values IF the name exists and is not empty
AND the value is not empty.  Everything else still seems to work too, reference
http://www.johnkeiser.com/cgi-bin/mozform.pl

Comment 11

[Alexandru Savulov]

Comment on attachment 65572 [details] [diff] [review]
Patch

r= alexsavulov

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 65572 [details] [diff] [review]
Patch

sr=jst

Comment 13

[John Keiser (jkeiser)]

checked in

Comment 14

[Vladimir Ermakov]

this is fixed a long time ago, verifying.