Non-activated default buttons prevent implicit form submission.

Non-activated default buttons prevent implicit form submission.

Follow the spec and two other implementations (Gecko + Presto), and do
not allow implicit form submission if the default (submit) button is
not in an activated state (read: disabled.)

Notice that this switches to behavior different from what Trident / IE
provides.

R=eseidel,tkent
BUG=37402
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162095

[sof, 2013-11-14 14:57:34]

At your leisure, please take a look.

[sof, 2013-11-14 14:58:51]

http://code.google.com/p/chromium/issues/detail?id=37402#c11 claims that IE10
Standards mode supports suppression of implicit submits via disabled submit
buttons.

I've been unable to reproduce this locally, hence no claim of IE alignment in
the bug description. Worth mentioning as a potential compat risk.

[eseidel, 2013-11-14 16:25:16]

I wonder if the IETC covers this case.  It seems like the kind of random IE
quirk they might have covered.
http://samples.msdn.microsoft.com/ietestcenter/#html5Forms

[eseidel, 2013-11-14 16:40:32]

Linking to the IETC sent me on a yak-shave.  But the answer is "no" that
marketing site disguised as a "test suite" remains largely useless and does not
cover things like this.

I'm OK with this.  Not entirely sure why the spec chose FF over IE here.

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
File Source/core/html/HTMLButtonElement.cpp (left):

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
Source/core/html/HTMLButtonElement.cpp:164: // HTML spec says that buttons must
have names to be considered successful.
Interesting that we're choosing to follow one bit of HTML5 here, but not
another.

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLFormElem...
File Source/core/html/HTMLFormElement.cpp (right):

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLFormElem...
Source/core/html/HTMLFormElement.cpp:182: if (!seenDefaultButton &&
control->canBeSuccessfulSubmitButton()) {
I think you mean couldBeSuccessful?
http://en.wikipedia.org/wiki/Subjunctive_mood since it's talking about something
uncertain in the future?

[sof, 2013-11-14 17:22:07]

On 2013/11/14 16:40:32, eseidel wrote:
> Linking to the IETC sent me on a yak-shave.  But the answer is "no" that
> marketing site disguised as a "test suite" remains largely useless and does
not
> cover things like this.
> 

I hadn't checked with it, good suggestion. But yes, this is one of its sub areas
where its tests are superficial. I couldn't find anything too interesting
either.

[tkent, 2013-11-15 00:04:30]

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
File Source/core/html/HTMLButtonElement.cpp (left):

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
Source/core/html/HTMLButtonElement.cpp:164: // HTML spec says that buttons must
have names to be considered successful.
On 2013/11/14 16:40:32, eseidel wrote:
> Interesting that we're choosing to follow one bit of HTML5 here, but not
> another.

It seems the WHATWG specification doesn't ask it.  We should remove the comment.

[tkent, 2013-11-15 00:06:28]

On 2013/11/14 14:58:51, sof wrote:
> http://code.google.com/p/chromium/issues/detail?id=37402#c11 claims that IE10
> Standards mode supports suppression of implicit submits via disabled submit
> buttons.
> 
> I've been unable to reproduce this locally, hence no claim of IE alignment in
> the bug description. Worth mentioning as a potential compat risk.

I rechecked IE behavior and I couldn't confirm IE followed the specification :-(
Anyway, we should fix this issue IMO.

[eseidel, 2013-11-15 00:09:02]

lgtm

I trust your judgement.  Please update the comments to reflect IE and the spec.

[sof, 2013-11-15 08:52:14]

Thanks tkent and eseidel. There are always risks with changing forms related
behavior, but this one seems worth switching to overall. Let's try. :)

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
File Source/core/html/HTMLButtonElement.cpp (left):

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLButtonEl...
Source/core/html/HTMLButtonElement.cpp:164: // HTML spec says that buttons must
have names to be considered successful.
On 2013/11/15 00:04:31, tkent wrote:
> On 2013/11/14 16:40:32, eseidel wrote:
> > Interesting that we're choosing to follow one bit of HTML5 here, but not
> > another.
> 
> It seems the WHATWG specification doesn't ask it.  We should remove the
comment.

Done. I couldn't find any mention of this either (nor could others here remember
this being a constraint at some point.)

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLFormElem...
File Source/core/html/HTMLFormElement.cpp (right):

https://codereview.chromium.org/60573007/diff/1/Source/core/html/HTMLFormElem...
Source/core/html/HTMLFormElement.cpp:182: if (!seenDefaultButton &&
control->canBeSuccessfulSubmitButton()) {
On 2013/11/14 16:40:32, eseidel wrote:
> I think you mean couldBeSuccessful?
> http://en.wikipedia.org/wiki/Subjunctive_mood since it's talking about
something
> uncertain in the future?

Maybe the naming could be made clearer, it currently reflects the naming of the
InputType method. I could certainly follow up and rename this, if that's what we
want.

(Actually, I wanted to use isSubmitButton() here for closer correspondence to
spec, but its use is close to deprecated..and would have to be tweaked slightly
to admit image buttons.)

[commit-bot: I haz the power, 2013-11-15 08:52:48]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sigbjornf@opera.com/60573007/120001

[commit-bot: I haz the power, 2013-11-15 09:50:49]

Change committed as 162095