198405 - Pressing Enter key Mozilla 1.3 does submit form using an image included bypassing onsubmit form event.

Status: RESOLVED INVALID

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

Description

[David Vozza]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Having a form with an input text type and an image calling for a javascript
function that submits the form, Mozilla 1.3 submits it using the image (and
linked function) bypassing the form onsubmit event when I press Enter key.
IE5.5 and even on NS 7.02 pressing Enter key firstly check the form onsubmit
event and, above all, don't automatically click on image to subimt the form!

Reproducible: Always

Steps to Reproduce:
1. Put an image inside an HTML form calling for a javascript function that
submits it.
2. Put an alert in onsubmit event included into html form.
3. Load page and, being inside input field, press Enter key.

Actual Results:  
Mozilla 1.3 bypasses form onsubmit event.

Expected Results:  
Mozilla shouldn't ignore onsubmit form event.

Comment 1

[David Vozza]

Attachment: Test case

Comment 2

[David Vozza]

Attachment: Test case img

Comment 3

[Boris Zbarsky [:bzbarsky]]

You hit enter.  We find the nearest submit element and call its onclick()
function (pages expect this to happen).  This function does a manual submit,
which does _not_ trigger an onsubmit handler.

In fact, the fact that the handler triggers when clicking on the image is due to
the double-submit (the onclick submits but does not cancel the click, so the
image input submits too).

Comment 4

[David Vozza]

If this is the right behaviour I should suppose that NS7.02 was (is!) wrong.

Comment 5

[John Keiser (jkeiser)]

Attachment: Testcase

Current trunk does not have this problem (it fires onsubmit).  I remember
something like it being fixed a while back, it was a problem with our
double-submit code, sure enough.

Comment 6

[Sam Schinke]

Why would you find the nearest submit element and fire it's onclick()?

This would make that submit element "successful", which is contrary to HTML 4.0:
http://www.w3.org/TR/REC-html40/interact/forms.html#successful-controls

(in particular: If a form contains more than one submit button, only the
activated submit button is successful. -- this implies that if there is more
than one submit button, none of them is successful unless activated)

If there is more than one submit button, and "enter" is pressed in a text input
field, NO submit button should be activated, otherwise the results are ambiguous
as to which submit button should be activated.

This ALSO occurs with "<input type=image" form buttons, where ONE of the image
inputs will be submitted with input.x and input.y set to 0,0. Which is also
"wrong" (I'll look a bit more for a bug specific to this).

Regards,
Sam

Comment 7

[John Keiser (jkeiser)]

Pressing enter *activates* the first submit button.  There's nothing in the spec
to say a user agent can't choose one of the buttons and activate it, and this is
the expected behavior and is non-ambiguous (the first button, only the first
button, and always the first button).

It is also not the subject of this bug.

Comment 8

[Sam Schinke]

Yes, thanks. I've filed another bug after searching, which has been marked as a dup. Looking at the dup now :)

Is it the "first" or the "nearest" submit button, by the way? Replies in this thread have been confilcting on that issue.

Regards,
Sam

Comment 9

[Boris Zbarsky [:bzbarsky]]

This is invalid.  What NS 7.02 was doing was deliberately changed to the current
behavior.

Sam, it's the first submit button.  My initial comment was incorrect.