Bug 9756 – A form without a submit button unexpectedly performs its action when Return is pressed

• Component: Forms
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Steps to reproduce:
1. Open the bug URL.
2. Click in any input field.
3. Press Return key.

Results: the page reloads
Expeced results: nothing happens (as in Firefox 1.5)

[Alexey Proskuryakov]

*** Bug 21716 has been marked as a duplicate of this bug. ***

[Edward Rudd]

Further docs on the "expected' behavior and reasons.

http://www.alanflavell.org.uk/www/formquestion.html 

It is rather unexpected and actually causes much problems when webkit submits a form on enter even though there are multiple text input elements in the form.

Here is a stackoverflow question about how to prevent webkit from doing this..

http://stackoverflow.com/questions/751702/how-can-i-prevent-webkit-browser-to-submit-a-form-when-enter-is-pressed-in-an-inp


IMO, it's a bad design to submit the form the way webkit does as (quote from the first link)

(From HTML 2.0 spec) 
When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.

(from article)
This was evidently meant as a convenient way to submit simple queries, but reducing the risk, on a complex form, of prematurely submitting it while trying to fill it in. 

the current webkit design causes a high volume of prematurely submitted forms. (of which I am currently in the middle of deciding if I want to redesign EVERY FORM on my web application so webkit can be used OR blacklisting webkit due to numerous issues due to this bug)

[Dimitri Glazkov (Google)]

The HTML5 spec is pretty clear here. We're doing the right thing:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission

[Alexey Proskuryakov]

HTML5 diverges from both IE and Firefox here. We should probably ask for clarification on whether this is even intentional.

[Dimitri Glazkov (Google)]

Yup. I paraded on #whatwg for a bit with this question and the lukewarm response was that the spec is logical, whereas the IE/FF/Opera behavior is not.

[Edward Rudd]

Opera as well does not exhibit this behaviour..  It follows what IE and Firefox (and the 2.0 spec stated).  I know that there are many many people frustrated with webkit's behavior and this saddens me that you are refusing to change this behavior despite the BAD user experience it provide..  I should not HAVE to add javascript to make a form work correctly as users press enter to goto the next field ALL the time unfortunately due to the way other user interface dialogs in the OS are designed.   And this leads me with no choice but to ban webkit from my web applications until this is actually changed. as I have users frustrated because of webkit's behavior.

[Ian 'Hixie' Hickson]

The other browsers agree that it should submit if you hit enter if there's a submit button, right?

Why would it be different without a button?

All the spec is saying is that browsers have to be consistent. It doesn't require that enter submit a form, only that IF enter submits a form, it does so whether there's a button or not.

(An easy way to work around this if it's really a problem is to disable the first button in the form.)

[Alexey Proskuryakov]

> I paraded on #whatwg for a bit with this question

Sorry, I didn't see that before posting my comment.

Anyway, I think that IE/Firefox/Opera are logical and consistent here. Pressing Enter activates the default button, so if there is no default button, then nothing is activated.

This is how it works in native applications, too - pressing Enter dismisses a dialog that has an "OK" button with appropriate special rendering (e.g. a thicker border, or a different color, or pulsating). But pressing Enter in a text field does not close windows that lack an "OK" button.

[Edward Rudd]

(In reply to comment #8)
> Anyway, I think that IE/Firefox/Opera are logical and consistent here. Pressing
> Enter activates the default button, so if there is no default button, then
> nothing is activated.

And the issue I have is I have forms with no submit button and they get submitted.  But even with a button there's no easy way to state "I want NO default" without using javascript.

> 
> This is how it works in native applications, too - pressing Enter dismisses a
> dialog that has an "OK" button with appropriate special rendering (e.g. a
> thicker border, or a different color, or pulsating). But pressing Enter in a
> text field does not close windows that lack an "OK" button.

But how many of those dialogs with multiple fields go "default" on enter? When you are presented with a form with multiple inputs most of the time enter servers the same as TAB.  the user experience of having a half submitted form submit when they press enter is HORRID.  And I believe that is why no other browser (aside from webkit) does it that way.  with a auto submission  in the middle of a MULTI field form just BEGS for accidental submissions. And NO javascript is not a clean and acceptable workaround..    The only case where I expect and enter to implicitly submit (and this is from web AND desktops) is where there is ONE single input field.  As that makes sense there as I'm searching.. but a multi-input field form?? That doesn't makes sense, it creates a bad user experience.

[Dimitri Glazkov (Google)]

(In reply to comment #8)
> > I paraded on #whatwg for a bit with this question
> 
> Sorry, I didn't see that before posting my comment.
> 
> Anyway, I think that IE/Firefox/Opera are logical and consistent here. Pressing
> Enter activates the default button, so if there is no default button, then
> nothing is activated.

I would argue that their behavior is the least consistent one. It works like this:

When user presses enter in a text field with no submit button:
* If this is the only text field in a form, submit the form
* Otherwise, do not submit.

Whereas WebKit just always submits, like the spec prescribes.

[Alexey Proskuryakov]

I don't think that the current HTML5 draft should influence our decision much. Every other major browser engine behaves differently from WebKit, and we have well founded complaints about WebKit behavior.

> * If this is the only text field in a form, submit the form
> * Otherwise, do not submit.

I agree that the single-input case is inconsistent, both internally and with platform conventions. But WebKit is instead inconsistent with platform conventions in the more common case of having more than one input. And as explained by Edward above, the action of accidentally submitting an incomplete form is a dangerous one, so we shouldn't make it too easy.

[Dimitri Glazkov (Google)]

(In reply to comment #11)
> I don't think that the current HTML5 draft should influence our decision much.
> Every other major browser engine behaves differently from WebKit, and we have
> well founded complaints about WebKit behavior.
> 
> > * If this is the only text field in a form, submit the form
> > * Otherwise, do not submit.
> 
> I agree that the single-input case is inconsistent, both internally and with
> platform conventions. But WebKit is instead inconsistent with platform
> conventions in the more common case of having more than one input. And as
> explained by Edward above, the action of accidentally submitting an incomplete
> form is a dangerous one, so we shouldn't make it too easy.

Then we should change the spec :)

[Edward Rudd]

(In reply to comment #12)
> 
> Then we should change the spec :)

How does one go about getting input into the HTML5 spec then? As I'll be glad to push input into there.

[Dimitri Glazkov (Google)]

Created attachment 53883 [details]
Fairly comprehensive layout test

Also works in manual mode (for testing in Firefox/Opera -- sorry no IE).

[Dimitri Glazkov (Google)]

Here's the description of what FF does when in text input: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLInputElement.cpp#2022

It does basically the same when in radio/checkbox:

http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLInputElement.cpp#1956

[Dimitri Glazkov (Google)]

Investigating this change, I arrived at a few tests that will fail once we match our behavior with IE/FF:

Neither IE nor FF pass these:
http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/select-enter-key.html
http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/check-box-enter-key.html

IE doesn't pass this:
http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/enter-clicks-buttons.html

With the fast/forms/select-enter-key.html, no other browsers will submit on Enter when focused on a select under any circumstances. However, there's bug 12417 where we need to submit on Enter. 

With fast/forms/check-box-enter-key.html and fast/forms/enter-clicks-buttons.html,Firefox will submit on Enter when focused on a checkbox or radio if there's only a text field in the form or a submit button. IE won't. Ideally, we should just match IE, but there's a bug in rdar (http://trac.webkit.org/changeset/9232), where we need to submit on Enter.

To compromise, I'll make the behavior for selects and checkboxes consistent with how Firefox treats checkboxes: if there's a single text field, we submit. Otherwise, we don't. This takes care of all of our cases and their variants while still helps us match most of the other browsers. 

 is something we can easily address, because I don't think this was a proper regression test for the original issue anyway, and  will work once the form is less nonsensical (i.e. has at least one text field).

So the solution to match IE/FF on everything except:
* match FF but not IE on forms with single text field and a focused checkbox (will submit on Enter)
* match IE, but not FF on forms with single text field and a focused radio (won't submit on Enter)
* match neither IE nor FF on forms with single text field and a focused select (will submit on Enter).

[Dimitri Glazkov (Google)]

(In reply to comment #16)
>  is something we can easily address, because I don't think this was a proper
> regression test for the original issue anyway, and  will work once the form is
> less nonsensical (i.e. has at least one text field).

Argh :) Edit fail. Ignore this paragraph.

[Dimitri Glazkov (Google)]

Created attachment 54001 [details]
Patch

[Ojan Vafai]

(In reply to comment #16)
> With the fast/forms/select-enter-key.html, no other browsers will submit on
> Enter when focused on a select under any circumstances. However, there's bug
> 12417 where we need to submit on Enter. 

I don't see how this is related to submit on enter with select elements.

> With fast/forms/check-box-enter-key.html and
> fast/forms/enter-clicks-buttons.html,Firefox will submit on Enter when focused
> on a checkbox or radio if there's only a text field in the form or a submit
> button. IE won't. Ideally, we should just match IE, but there's a bug in rdar
> (http://trac.webkit.org/changeset/9232), where we need to submit on Enter.

This is 5 years old and could well be obsolete at this point.

> To compromise, I'll make the behavior for selects and checkboxes consistent
> with how Firefox treats checkboxes: if there's a single text field, we submit.
> Otherwise, we don't. This takes care of all of our cases and their variants
> while still helps us match most of the other browsers. 
>
> So the solution to match IE/FF on everything except:
> * match FF but not IE on forms with single text field and a focused checkbox
> (will submit on Enter)
> * match IE, but not FF on forms with single text field and a focused radio
> (won't submit on Enter)
> * match neither IE nor FF on forms with single text field and a focused select
> (will submit on Enter).

I'm OK with submitting the form iff there is a submit button and/or focus is in the only text input in the form. Submitting the form when you have a checkbox or a radio selected only if there is a single text field seems like it will only confuse users. Doing the hybrid approach you suggest above seems doubly insane. Do we really have any evidence there are still websites that on this?

[Dimitri Glazkov (Google)]

(In reply to comment #19)
> (In reply to comment #16)
> > With the fast/forms/select-enter-key.html, no other browsers will submit on
> > Enter when focused on a select under any circumstances. However, there's bug
> > 12417 where we need to submit on Enter. 
> 
> I don't see how this is related to submit on enter with select elements.

Well... there's a test that captures the behavior. Perhaps it had more to do with multiple form submission protection?
 
> > With fast/forms/check-box-enter-key.html and
> > fast/forms/enter-clicks-buttons.html,Firefox will submit on Enter when focused
> > on a checkbox or radio if there's only a text field in the form or a submit
> > button. IE won't. Ideally, we should just match IE, but there's a bug in rdar
> > (http://trac.webkit.org/changeset/9232), where we need to submit on Enter.
> 
> This is 5 years old and could well be obsolete at this point.

Yep.

> > To compromise, I'll make the behavior for selects and checkboxes consistent
> > with how Firefox treats checkboxes: if there's a single text field, we submit.
> > Otherwise, we don't. This takes care of all of our cases and their variants
> > while still helps us match most of the other browsers. 
> >
> > So the solution to match IE/FF on everything except:
> > * match FF but not IE on forms with single text field and a focused checkbox
> > (will submit on Enter)
> > * match IE, but not FF on forms with single text field and a focused radio
> > (won't submit on Enter)
> > * match neither IE nor FF on forms with single text field and a focused select
> > (will submit on Enter).
> 
> I'm OK with submitting the form iff there is a submit button and/or focus is in
> the only text input in the form. Submitting the form when you have a checkbox
> or a radio selected only if there is a single text field seems like it will
> only confuse users. Doing the hybrid approach you suggest above seems doubly
> insane. Do we really have any evidence there are still websites that on this?

On matching behavior of other browsers (with single text field), yes, there are sites that rely on that (see URL of this bug). I would say that doesn't even matter -- no matter how obscure the behavior is, we should strive to match it to spec or "state of the world" (as defined by IE/FF).

On the hybrid approach, I am not sure if we're better off just matching IE or doing the hybrid. I could be persuaded either way.

[Dimitri Glazkov (Google)]

> > I'm OK with submitting the form iff there is a submit button and/or focus is in
> > the only text input in the form. Submitting the form when you have a checkbox
> > or a radio selected only if there is a single text field seems like it will
> > only confuse users. Doing the hybrid approach you suggest above seems doubly
> > insane. Do we really have any evidence there are still websites that on this?

Blergh. I misread what you wrote. I think you're leaning toward matching IE here, which I am ok with. Alexey, what do you think?

[Alexey Proskuryakov]

If changes that affect existing tests are questionable, then you can consider spinning those into separate bugs. But they look fine to me.

> With the fast/forms/select-enter-key.html, no other browsers will submit on
> Enter when focused on a select under any circumstances. However, there's
> bug 12417 where we need to submit on Enter. 

That's bad copy/paste, the ChangeLog should have mentioned bug 12697 instead. The original test case in the bug had a submit button, so I think that we can just fix the test here.

> Ideally, we should just match IE, but there's a bug in rdar
> (http://trac.webkit.org/changeset/9232), where we need to submit on Enter.

<rdar://problem/4105097> doesn't mention any specific site, it just says that hitting Enter on a checkbox should submit a form. I think that we can change these tests to have a Submit button, too.

[Ojan Vafai]

(In reply to comment #21)
> > > I'm OK with submitting the form iff there is a submit button and/or focus is in
> > > the only text input in the form. Submitting the form when you have a checkbox
> > > or a radio selected only if there is a single text field seems like it will
> > > only confuse users. Doing the hybrid approach you suggest above seems doubly
> > > insane. Do we really have any evidence there are still websites that on this?
> 
> Blergh. I misread what you wrote. I think you're leaning toward matching IE
> here, which I am ok with. Alexey, what do you think?

Yes. We should just match IE.

[Ojan Vafai]

> > Blergh. I misread what you wrote. I think you're leaning toward matching IE
> > here, which I am ok with. Alexey, what do you think?
> 
> Yes. We should just match IE.

Also, maybe we should file mozilla bugs to see if they'll do the same?

[Adam Barth]

Comment on attachment 54001 [details]
Patch

This change is probable file.  I'm giving it an r- mostly for the abysmal change log.

LayoutTests/fast/forms/implicit-submission.html:59
 +      var html = "<form action=\"data:text/html,<scri" + "pt>javascript:parent.postMessage('y', '*')</scri" + "pt>\">";
Clever

LayoutTests/fast/forms/implicit-submission.html:73
 +              html += "<input type=\"" + type + "\" id=\"" + id + "\">";
This might be easier to do with the DOM.

LayoutTests/fast/forms/implicit-submission.html:93
 +      iframe.src = "data:text/html,<scri" + "pt>var manifest = \"" + manifest[1] + "\";\n" + String(runTestInIframe) + 
You actually only need to split the close script tag.  You can leave the open tag in tact.

WebCore/ChangeLog:7
 +  
Can you add more information to the change log?  There was a lot of good discussion on the bug.  We should summarize the conclusions here for posterity in case we need to revisit this issue.

WebCore/html/HTMLFormElement.cpp:609
 +          if (formElements[i]->hasLocalName(inputTag) && (static_cast<HTMLInputElement*>(formElements[i]))->isTextField() && ++textControlCount > 1)
I hate this static cast pattern, but I realize it's endemic.

[Dimitri Glazkov (Google)]

Thanks for review, Adam -- we haven't concluded the discussion yet though :)

[Adam Barth]

(In reply to comment #26)
> Thanks for review, Adam -- we haven't concluded the discussion yet though :)

Ah, then it's impossible to r+ that patch then.  :)

[Dimitri Glazkov (Google)]

Created attachment 54617 [details]
Patch

[Dimitri Glazkov (Google)]

Landed as http://trac.webkit.org/changeset/58520.

[Eric Seidel (no email)]

Looks like this lit the tree. :(

[WebKit Review Bot]

http://trac.webkit.org/changeset/58520 might have broken GTK Linux 32-bit Release

[Dimitri Glazkov (Google)]

(In reply to comment #30)
> Looks like this lit the tree. :(

My bad. I added a few extra cases to the test and forgot to update the expectations. Updated in http://trac.webkit.org/changeset/58521.

[Alexey Proskuryakov]

This change has caused bug 38913.

[Edward Rudd]

WOOHOO..  I've confirmed it fixed things with my web application using Webkit/534 (what is included in Google Chrome 6.0.408.1).

Thanks to all those who got this issue patched.

[Adele Peterson]

So far we've had two complaints from developers about the new behavior in Safari 5.  One report has the test case below - shouldn't this work?

<form action="http://www.apple.com" method="post" name="FormName">
	<select name="test" size="1">
		<option value="a">a</option>
		<option value="b">b</option>
		<option value="c">c</option>
	</select>
	<input type="submit" value="Save Changes">
</form>

[Dimitri Glazkov (Google)]

(In reply to comment #35)
> So far we've had two complaints from developers about the new behavior in Safari 5.  One report has the test case below - shouldn't this work?
> 
> <form action="http://www.apple.com" method="post" name="FormName">
>     <select name="test" size="1">
>         <option value="a">a</option>
>         <option value="b">b</option>
>         <option value="c">c</option>
>     </select>
>     <input type="submit" value="Save Changes">
> </form>

Hitting Enter from select doesn't trigger anything in IE, ever. But while it seems prudent to match IE in all cases, this one is just not very logical. Maybe we could deviate from our commitment in this case? In other words:

* hitting enter on select doesn't trigger implicit submission
* if a default button is present, act like a checkbox (submit that is).

WDYT?

[Adele Peterson]

I'm not sure.  Its hard for me to tell if the complaints are due to people having to change their behavior, or if there's more behind it.

As a Safari user and developer I do not like this change. I work with forms daily where the old behavior was useful and expected. Those forms have a submit button far from the selects. I often have to scroll the page to find the select button to click it. That's a lot more work than just pressing the enter key on a selected select element.

[Alexey Proskuryakov]

There is a bug 39532 tracking select behavior. It's better to comment there.