All users were logged out of Bugzilla on October 13th, 2018

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




16 years ago
15 years ago


(Reporter: david_vozza, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)

522 bytes, text/html


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

16 years ago
Created attachment 117854 [details]
Test case

Comment 2

16 years ago
Created attachment 117855 [details]
Test case img
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

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

Comment 5

16 years ago
Created attachment 117868 [details]

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.
Attachment #117854 - Attachment is obsolete: true
Attachment #117855 - Attachment is obsolete: true

Comment 6

16 years ago
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:

(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).


Comment 7

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

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

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

Sam, it's the first submit button.  My initial comment was incorrect.
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.