HTMLForms: Implicit Submission with {display:none} button

[Ryosuke Niwa-3]

On Sep 25, 2011 11:48 AM, "Boris Zbarsky" <bzbarsky@...> wrote:
> On 9/24/11 4:45 PM, Ryosuke Niwa wrote:
>> It does not do implicit submissio in the following conditions:
>>
>>    - Two text fields
>
> Not doing that last is actually a requirement for web compat, last I
looked at this.
>
> Furthermore, a requirement for web compat is that in the two-textfield
case the submission happen via triggering a click event on the default
submit element for the form and then allowing that to trigger submission as
it would normally (or not trigger it, if the page prevents its default
action, etc).  I expect this event-firing business is why IE has any sort of
dependency on styles for the submit button, and I would not be surprised if
that's why WebKit has it too.

This is a good point. So Gecko fires a click event on a button even if it
had display: none or visibiliy: hidden?

> For the one-text-input case, as I recall IE does NOT click the default
submit, at least as of 2002; Gecko used to have that behavior but we opted
for more consistency.  So the current Gecko behavior is to submit via
clicking the default submit input if there is one, else to submit only if
there is only one text control (where the definition of "text control" is
especially interesting, since it of course includes controls of unknown
types, so as new form control types are added things get _really_ exciting
before browsers implement them).

Right, determining whether there is excatly one text field is tricky.

> For those who want to mess with the spec for this behavior,
https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and
https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and
https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but
probably not sufficient) reading.

Thanks for the pointer!  This is very helpful.

- Ryosuke

[Boris Zbarsky]

On 9/25/11 5:35 PM, Ryosuke Niwa wrote:
> So Gecko fires a click event on a button even if
> it had display: none or visibiliy: hidden?

In this situation, yes.  Just like as if you called dispatchEvent on it.

Of course you can't trigger click events on such a button using an
actual mouse, since it can't be hit-targeted.

-Boris

[Kaustubh Atrawalkar-4]

On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard <glenn@...> wrote:

> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa <rniwa@...> wrote:
>
>>  The current Trident/WebKit behavior has a nice side-effect to (without
>> scripts) require a visible submit button to enable implicit form submission.
>>
>
> I don't find that nice.  As a user, it's very annoying when implicit form
> submission doesn't work for some obscure reason (like not having a submit
> control), forcing me to use the mouse instead of it behaving like any other
> form.  It makes the UI inconsistent and unpredictable.
>
> Also, the single-text-input-with-no-submit-button case doesn't follow the
> above.
>
> The "without scripts" is also a fatal caveat.  Users can't be expected to
> understand things like "you can press enter to submit the form if you see a
> browser-native submit button, but not if the button is actually scripted
> markup".
>
> In principle, *all* forms should allow implicit submit, unless the site
> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't
> support it.  That ship sailed years ago, but the visibility of the submit
> button shouldn't enter into it.
>
>

Reopening discussion -
In case of single Input box and disabled (but visible button) forms still
gets submitted on implicit submission. This is again something weird
and happens in IE & Webkit but not in FF & opera. IMHO, the implicit
submission should have straight away algorithm -

1) If submit button is there but not disabled implicit submission should
happen on enter key press
2) If submit button is there and disabled implicit submission should not
happen on enter key press

Both logic should be irrespective of number of input button OR visibility of
submit button.

- Kaustubh

[Kaustubh Atrawalkar-4]

On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard <glenn@...> wrote:

> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa <rniwa@...> wrote:
>
>>  The current Trident/WebKit behavior has a nice side-effect to (without
>> scripts) require a visible submit button to enable implicit form submission.
>>
>
> I don't find that nice.  As a user, it's very annoying when implicit form
> submission doesn't work for some obscure reason (like not having a submit
> control), forcing me to use the mouse instead of it behaving like any other
> form.  It makes the UI inconsistent and unpredictable.
>
> Also, the single-text-input-with-no-submit-button case doesn't follow the
> above.
>
> The "without scripts" is also a fatal caveat.  Users can't be expected to
> understand things like "you can press enter to submit the form if you see a
> browser-native submit button, but not if the button is actually scripted
> markup".
>
> In principle, *all* forms should allow implicit submit, unless the site
> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't
> support it.  That ship sailed years ago, but the visibility of the submit
> button shouldn't enter into it.
>
>

Should this be made to for all browser compliance and browser to allow
implicit submission irrespective of visibility of submit button? A web-dev
can always stop this by either disabling the submit button or through
script. Browser can give control back to onsubmit handler on enter key press
if there is enabled submit button.

[Ryosuke Niwa-2]

Given that both IE and WebKit have been disabling implicit form submission
for years when the button has display: none, I don't think we can change
our behavior here.

Best,
Ryosuke Niwa
Software Engineer
Google Inc.

On Wed, Oct 12, 2011 at 11:33 PM, Kaustubh Atrawalkar <kaustubh@...
> wrote:

>
> On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard <glenn@...> wrote:
>
>> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa <rniwa@...> wrote:
>>
>>>  The current Trident/WebKit behavior has a nice side-effect to (without
>>> scripts) require a visible submit button to enable implicit form submission.
>>>
>>
>> I don't find that nice.  As a user, it's very annoying when implicit form
>> submission doesn't work for some obscure reason (like not having a submit
>> control), forcing me to use the mouse instead of it behaving like any other
>> form.  It makes the UI inconsistent and unpredictable.
>>
>> Also, the single-text-input-with-no-submit-button case doesn't follow the
>> above.
>>
>> The "without scripts" is also a fatal caveat.  Users can't be expected to
>> understand things like "you can press enter to submit the form if you see a
>> browser-native submit button, but not if the button is actually scripted
>> markup".
>>
>> In principle, *all* forms should allow implicit submit, unless the site
>> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't
>> support it.  That ship sailed years ago, but the visibility of the submit
>> button shouldn't enter into it.
>>
>>
> Should this be made to for all browser compliance and browser to allow
> implicit submission irrespective of visibility of submit button? A web-dev
> can always stop this by either disabling the submit button or through
> script. Browser can give control back to onsubmit handler on enter key
> press if there is enabled submit button.
>

[Boris Zbarsky]

On 12/9/11 6:06 PM, Ryosuke Niwa wrote:
> Given that both IE and WebKit have been disabling implicit form submission
> for years when the button has display: none, I don't think we can change
> our behavior here.

Why, given that neither Gecko nor Opera have, and as far as I know have
gotten precisely 0 bug reports about that?

-Boris

[Ian Hickson]

On Sat, 24 Sep 2011, Kaustubh Atrawalkar wrote:

> On 24-Sep-2011, at 12:24 AM, Ian Hickson <ian@...> wrote:
>> On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote:
>>>
>>> If the form has submit button with display property as none, will that
>>> form should be implicitly submitted on pressing enter key? This works
>>> in Opera & Firefox but does not work in IE & Safari as of now. What is
>>> the expected behavior for this?
>
>> The strict answer is that it's up to the browsers; the spec allows
>> browsers to do whatever they think is appropriate per their platform's
>> conventions. So both behaviours are compliant.
>
> But then this might result in website compliance issue. A website having
> username, password field with hidden submit button expecting to login on
> enter key using forms implicit submission will work on FF & Opera but
> may not work on IE & Safari.

Yes. Similarly, some browsers might provide spelling checking, and others
might not. Some might support tabbing from field to field, others might
not. The thing is, if a platform does not have the concept of implicit
submission, presumably the user wouldn't try to implicitly submit anything
in the first place, so it doesn't matter if the browser does it or not.

>> The guidelines in the spec do not say anything about the behaviour
>> being different for elements that are display:none or otherwise hidden,
>> though, so I don't see any reason to consider the visibility of a
>> button in making the decision as to which button is the default.
>
> Second to your opinion, on the last line of the specs paragraph it says
> - "If the form has no submit button, then the implicit submission
> mechanism must just submit the form element from the form element
> itself."
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission

This does not contradict what I wrote. It just says what to do if there IS
an implicit submission mechanism, but there's no button at all.


On Sat, 24 Sep 2011, Ryosuke Niwa wrote:

>
> WebKit's behavior is very confusing here. It does implicit submission in the
> following conditions:
>
>    - One text fields
>    - One text field with one visible submit button
>    - Two text fields with one visible submit button
>    - Two text fields with one visibility:hidden submit button
>    - One text field with one display:none submit button
>
> However, it doesn't submit when we have:
>
>    - Two text fields

That's non-conforming currently.


>    - Two text fields with one display:none submit button

That's not really sensible, but it was technically within the spec's
language. (You were allowed to not pick a default button if there was one
to pick from but you didn't like it for some reason.) I've changed the
spec to make this no longer allowed. The first button will now always be
the default.


> Given that WebKit implicitly submits form even in the presence of a
> visible submit button or an invisible submit button (visibility: hidden,
> or display: none with exactly one text field), I don't see why we should
> avoid implicit submission only when there are multiple form controls and
> a display:none submit button.

Agreed.


On Sat, 24 Sep 2011, Ryosuke Niwa wrote:

>
> IE9 does implicit submission in the following conditions:
>
>    - One text field
>    - One text field with one visible submit button
>    - One text field with one display:none submit button
>    - Two text fields with one visible submit button
>
> It does not do implicit submissio in the following conditions:
>
>    - Two text fields
>    - Two text fields with one visibility:hidden submit button
>    - Two text fields with one display:none submit button
>
> Basically, IE9 only does implicit submission when there is exactly one
> text field (you can have checkbox, hidden, etc...) or there is a visible
> button (i.e. not diplay: none nor visibility: hidden).

If you submit with one text field and no button, then you are required to
also submit with two text fields and no button. So this is non-conforming.

> Firefox 5 does implicit submission in the following conditions:
>
>    - One text field
>    - One text field with one visible submit button
>    - One text field with one display:none submit button
>    - Two text fields with one visible submit button
>    - Two text fields with one visibility:hidden submit button
>    - Two text fields with one display:none submit button
>
> It does not do implicit submissio in the following conditions:
>
>    - Two text fields
>
> In summary, Firefox special cases one text field (can have checkbox,
> hidden, etc...) like MSIE and requires a submit button with more than
> two text fields regardless of presence of visibility: hidden or display:
> none.

On Sun, 25 Sep 2011, Kaustubh Atrawalkar wrote:

>
> Opera - Does Implicit submission in following cases -
> * One text field
> * One text field with one visible submit button
> * One text field with one display:none submit button
> * Two text fields with one visible submit button
> * Two text fields with one visibility:hidden submit button
> * Two text fields with one display:none submit button
>
> Only in following case it does not -
> * Two text fields

Those seem non-conforming for the same reason.


On Sun, 25 Sep 2011, Boris Zbarsky wrote:
>
> Not doing that last is actually a requirement for web compat, last I
> looked at this.

Do you have any links to pages that break if a form with more than one
text field supports implicit submission?


> Furthermore, a requirement for web compat is that in the two-textfield
> case the submission happen via triggering a click event on the default
> submit element for the form and then allowing that to trigger submission
> as it would normally (or not trigger it, if the page prevents its
> default action, etc).  I expect this event-firing business is why IE has
> any sort of dependency on styles for the submit button, and I would not
> be surprised if that's why WebKit has it too.

The spec tried to say this, though it did so poorly. It now definitely
says this.

> For the one-text-input case, as I recall IE does NOT click the default
> submit, at least as of 2002; Gecko used to have that behavior but we
> opted for more consistency.  So the current Gecko behavior is to submit
> via clicking the default submit input if there is one, else to submit
> only if there is only one text control (where the definition of "text
> control" is especially interesting, since it of course includes controls
> of unknown types, so as new form control types are added things get
> _really_ exciting before browsers implement them).
>
> Submitting forms with no submit on enter in a single text control is
> also required for web compat, of course.
>
> There is also the separate issue of _which_ controls enter triggers
> submission in (e.g. it works in checkbox or radio in Gecko, iirc, but of
> course not in textarea).
>
> For those who want to mess with the spec for this behavior,
> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but
> probably not sufficient) reading.

I read those bugs, but can't see the reason why submitting a form with two
text fields and no buttons would break the Web. Can you elaborate?


On Sat, 24 Sep 2011, Glenn Maynard wrote:
>
> Nothing in "4.10.22.2 Implicit submission" seems to allow implicit
> submission to vary based on whether a submit button is displayed or
> not...

Technically, if you have a button, you could arbitrarily pick the default
from the buttons you have, including picking no button, and the spec put
no limit on what you based the decision on.

I've now changed this since it allowed different behaviours unnecessarily.


> (It also explicitly says that if implicit submit is supported but
> there's no submit button in the form, the implicit submit must still
> happen.  That doesn't sound like it could be followed, since lots of
> pages are probably depending on the absence of a submit button
> suppressing implicit submit. That's just backwards-compatibility, not
> platform conventions, though.)

Do you have any such pages to point to?


On Sat, 24 Sep 2011, Ryosuke Niwa wrote:
>
> Why? From user's perspective, not having submit button, having a submit
> button with display: none, having a submit button with visibility:
> hidden all look the same.

The semantics of the page don't change though.

(Opacity:0.01 and margin-left:-100em would both also look the same, but
presumably you don't think those shouldn't submit.)


On Sun, 25 Sep 2011, Ryosuke Niwa wrote:
>
> Why is this authoring question? As an user, I'd like to know whether
> pressing enter in my text field triggers implicit submission or not.

Whether it does or not should be based on the conventions of the platform.


On Sun, 25 Sep 2011, Ryosuke Niwa wrote:
>
> I personally find implicit form submission to be annoying, and always wished
> I could disable it (also backspace triggering backward navigation).

Really? I've always found it annoying that I have to hunt for the submit
button. I don't have to in Windows dialogs, why do I have to on Web pags
in Windows browsers? Doesn't make any sense.


On Thu, 29 Sep 2011, Kaustubh Atrawalkar wrote:

>
> In case of single Input box and disabled (but visible button) forms
> still gets submitted on implicit submission. This is again something
> weird and happens in IE & Webkit but not in FF & opera. IMHO, the
> implicit submission should have straight away algorithm -
>
> 1) If submit button is there but not disabled implicit submission should
> happen on enter key press
> 2) If submit button is there and disabled implicit submission should not
> happen on enter key press
>
> Both logic should be irrespective of number of input button OR
> visibility of submit button.

The spec agrees with you. If there's a button, and it's the default, then
if it is disabled the form won't submit. If there's a button and it's not
the default, the form wouldn't submit either. So if there's a button and
it's disabled, you should not be able to implicitly submit, per the spec.


On Fri, 9 Dec 2011, Ryosuke Niwa wrote:
>
> Given that both IE and WebKit have been disabling implicit form
> submission for years when the button has display: none, I don't think we
> can change our behavior here.

On Fri, 9 Dec 2011, Boris Zbarsky wrote:
>
> Why, given that neither Gecko nor Opera have, and as far as I know have
> gotten precisely 0 bug reports about that?

I agree with Boris here.

I've changed the spec to be clearer that CSS cannot be taken into account
when determining the default. The default button is just always the first
submit button in the form.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Boris Zbarsky]

On 2/21/12 7:35 PM, Ian Hickson wrote:
> On Sun, 25 Sep 2011, Boris Zbarsky wrote:
>>
>> Not doing that last is actually a requirement for web compat, last I
>> looked at this.
>
> Do you have any links to pages that break if a form with more than one
> text field supports implicit submission?

Not offhand.  Again, it's been a while since I looked into this, but at
the time this was being implemented in Gecko we carefully made the
two-input-no-submit case not submit.  I thought that was for good
reason, but reskimming the bugs now I can't find the reason.  It's been
over 10 years, so the details are a bit hazy in my mind.  :(

>> For those who want to mess with the spec for this behavior,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but
>> probably not sufficient) reading.
>
> I read those bugs, but can't see the reason why submitting a form with two
> text fields and no buttons would break the Web. Can you elaborate?

https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that
needs reading, but it doesn't help either.  I didn't look at the various
(and somewhat numerous) duplicates of the various bugs involved...

I suppose we could try submitting the "more than one text input, no
submit button" case and see what happens...

-Boris

[Glenn Maynard]

On Tue, Feb 21, 2012 at 6:35 PM, Ian Hickson <ian@...> wrote:

> > (It also explicitly says that if implicit submit is supported but

> there's no submit button in the form, the implicit submit must still
> > happen.  That doesn't sound like it could be followed, since lots of
> > pages are probably depending on the absence of a submit button
> > suppressing implicit submit. That's just backwards-compatibility, not
> > platform conventions, though.)
>
> Do you have any such pages to point to?
>

Nope, only the assumption that the weird browser behavior related to this
could only be for that reason.  I'll be happy if this proves unnecessary;
this ugliness has caused me headaches in the past.

On Sun, 25 Sep 2011, Ryosuke Niwa wrote:
> > Why is this authoring question? As an user, I'd like to know whether
> > pressing enter in my text field triggers implicit submission or not.
>
> Whether it does or not should be based on the conventions of the platform.
>

I don't think the existence of implicit submit should depend on platform
conventions, though, for interop on forms without visible submit buttons.
 The form implicit submit takes is a platform convention, but it should be
required to exist in some form or another.

--
Glenn Maynard

[Dimitri Glazkov-2]

On Tue, Feb 21, 2012 at 5:36 PM, Boris Zbarsky <bzbarsky@...> wrote:

> On 2/21/12 7:35 PM, Ian Hickson wrote:
>>
>> On Sun, 25 Sep 2011, Boris Zbarsky wrote:
>>>
>>>
>>> Not doing that last is actually a requirement for web compat, last I
>>> looked at this.
>>
>>
>> Do you have any links to pages that break if a form with more than one
>> text field supports implicit submission?
>
>
> Not offhand.  Again, it's been a while since I looked into this, but at the
> time this was being implemented in Gecko we carefully made the
> two-input-no-submit case not submit.  I thought that was for good reason,
> but reskimming the bugs now I can't find the reason.  It's been over 10
> years, so the details are a bit hazy in my mind.  :(

I made WebKit match this behavior a couple of years ago:
https://bugs.webkit.org/show_bug.cgi?id=9756

:DG<

>
>
>>> For those who want to mess with the spec for this behavior,
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but
>>> probably not sufficient) reading.
>>
>>
>> I read those bugs, but can't see the reason why submitting a form with two
>> text fields and no buttons would break the Web. Can you elaborate?
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that
> needs reading, but it doesn't help either.  I didn't look at the various
> (and somewhat numerous) duplicates of the various bugs involved...
>
> I suppose we could try submitting the "more than one text input, no submit
> button" case and see what happens...
>
> -Boris

[Boris Zbarsky]

On 2/21/12 10:47 PM, Dimitri Glazkov wrote:
> I made WebKit match this behavior a couple of years ago:
> https://bugs.webkit.org/show_bug.cgi?id=9756

Ah, interesting.  Some of the links in that bug indicate that people are
in fact depending on this behavior....

-Boris

[Glenn Maynard]

On Tue, Feb 21, 2012 at 7:36 PM, Boris Zbarsky <bzbarsky@...> wrote:

> Not offhand.  Again, it's been a while since I looked into this, but at
> the time this was being implemented in Gecko we carefully made the
> two-input-no-submit case not submit.  I thought that was for good reason,
> but reskimming the bugs now I can't find the reason.  It's been over 10
> years, so the details are a bit hazy in my mind.  :(
>

Ten years later it's still giving me headaches, when I try to do a trivial
two-input login form without a browser submit button, and find that every
obvious way of hiding the submit button breaks implicit submit in one
browser or another.  Do I really need to stick the submit button in an
overflow: hidden, 0x0 div?  I know I found a less ugly workaround for this
the last time I hit this...

--
Glenn Maynard

[Boris Zbarsky]

On 4/3/12 5:14 PM, Glenn Maynard wrote:
> Ten years later it's still giving me headaches, when I try to do a
> trivial two-input login form without a browser submit button, and find
> that every obvious way of hiding the submit button breaks implicit
> submit in one browser or another.  Do I really need to stick the submit
> button in an overflow: hidden, 0x0 div?  I know I found a less ugly
> workaround for this the last time I hit this...

Well, the fact that display:none makes it not submit is clearly a
browser bug in the browsers it happens in.

The only question is whether just not having a button at all should also
submit.

-Boris

[Rob Crowther-3]

On 22/02/12 00:35, Ian Hickson wrote:
> I've changed the spec to be clearer that CSS cannot be taken into account
> when determining the default. The default button is just always the first
> submit button in the form.
>
What about the situation where there isn't a button?  Implicit
submission still seems to happen on forms which have just a single
element, for example:

http://www.boogdesign.com/examples/forms2/test-validate-1.html
http://www.boogdesign.com/examples/forms2/test-validate-2.html

These both trigger the form validation algorithm in Firefox, Opera &
Chrome if you just hit return.  This form with two inputs doesn't
trigger implicit submission:

http://www.boogdesign.com/examples/forms2/test-validate-3.html

But add a submit button and it does:

http://www.boogdesign.com/examples/forms2/test-validate-4.html

Because in 4.10.22.2 everything hinges on the 'default button' this
behaviour doesn't seem to be covered.  Is this intentional?

Rob

[Ian Hickson]

On Tue, 21 Feb 2012, Boris Zbarsky wrote:
> On 2/21/12 10:47 PM, Dimitri Glazkov wrote:
> > I made WebKit match this behavior a couple of years ago:
> > https://bugs.webkit.org/show_bug.cgi?id=9756
>
> Ah, interesting.  Some of the links in that bug indicate that people are
> in fact depending on this behavior....

I've tried to define this in the spec. It's a bit esoteric, but...

Let me know if it's not quite right. I wasn't sure exactly what weird
things to test. I mostly relied on WebKit's (specifically Chrome's)
behaviour here since they were apparently the ones most recently affected
by real compat reasons to implement something here so maybe they are the
closest to what the Web today actually needs (?).


On Tue, 3 Apr 2012, Boris Zbarsky wrote:

> On 4/3/12 5:14 PM, Glenn Maynard wrote:
> > Ten years later it's still giving me headaches, when I try to do a
> > trivial two-input login form without a browser submit button, and find
> > that every obvious way of hiding the submit button breaks implicit
> > submit in one browser or another.  Do I really need to stick the
> > submit button in an overflow: hidden, 0x0 div?  I know I found a less
> > ugly workaround for this the last time I hit this...
>
> Well, the fact that display:none makes it not submit is clearly a
> browser bug in the browsers it happens in.

Indeed.


On Tue, 21 Feb 2012, Glenn Maynard wrote:
>
> I don't think the existence of implicit submit should depend on platform
> conventions, though, for interop on forms without visible submit
> buttons. The form implicit submit takes is a platform convention, but it
> should be required to exist in some form or another.

User agents aren't actually required to let users input anything, so it
doesn't make much sense to require submission be possible...


On Thu, 24 May 2012, Rob Crowther wrote:

> On 22/02/12 00:35, Ian Hickson wrote:
> > I've changed the spec to be clearer that CSS cannot be taken into
> > account when determining the default. The default button is just
> > always the first submit button in the form.
>
> What about the situation where there isn't a button?  Implicit
> submission still seems to happen on forms which have just a single
> element, for example:
>
> http://www.boogdesign.com/examples/forms2/test-validate-1.html 
> http://www.boogdesign.com/examples/forms2/test-validate-2.html
>
> These both trigger the form validation algorithm in Firefox, Opera &
> Chrome if you just hit return.  This form with two inputs doesn't
> trigger implicit submission:
>
> http://www.boogdesign.com/examples/forms2/test-validate-3.html
>
> But add a submit button and it does:
>
> http://www.boogdesign.com/examples/forms2/test-validate-4.html
>
> Because in 4.10.22.2 everything hinges on the 'default button' this
> behaviour doesn't seem to be covered.  Is this intentional?

I've updated the spec to hopefully better match this, as noted above.

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Boris Zbarsky]

On 6/29/12 5:24 PM, Ian Hickson wrote:
> Let me know if it's not quite right. I wasn't sure exactly what weird
> things to test. I mostly relied on WebKit's (specifically Chrome's)
> behaviour here since they were apparently the ones most recently affected
> by real compat reasons to implement something here so maybe they are the
> closest to what the Web today actually needs (?).

What were the differences between Chrome and Gecko here, if you recall?
  I'm somewhat interested.

In any case, I believe the spec is wrong in one aspect: in the case that
there is a default button, what needs to happen is a click event on that
button, not just a triggering of its activation behavior.  In
particular, onclick handlers need to fire and the activation behavior
should only happen if preventDefault is not called on the event.  For
example, this testcase:

   <!DOCTYPE html>
   <form action="http://w3.org">
     <input type="text" value="Focus me and hit enter">
     <input type="submit" onclick="alert('haha'); return false;">
   </form>

should alert and not submit.  Yes, I know this is totally screwy.  :(

-Boris

[Boris Zbarsky]

On 6/29/12 6:19 PM, Boris Zbarsky wrote:
> In any case, I believe the spec is wrong in one aspect: in the case that
> there is a default button, what needs to happen is a click event on that
> button, not just a triggering of its activation behavior. In particular,
> onclick handlers need to fire and the activation behavior should only
> happen if preventDefault is not called on the event.

Note that depending on how <input disabled> defines handling of click
events, we may get the right thing happening with it for free.
Unfortunately, I'm failing to find where the spec talks about the actual
behavior of @disabled on submit controls.  :(

-Boris

[Ian Hickson]

On Fri, 29 Jun 2012, Boris Zbarsky wrote:
> On 6/29/12 5:24 PM, Ian Hickson wrote:
> > Let me know if it's not quite right. I wasn't sure exactly what weird
> > things to test. I mostly relied on WebKit's (specifically Chrome's)
> > behaviour here since they were apparently the ones most recently
> > affected by real compat reasons to implement something here so maybe
> > they are the closest to what the Web today actually needs (?).
>
> What were the differences between Chrome and Gecko here, if you recall?  
> I'm somewhat interested.

The main difference was that Chrome and Firefox differ in what input types
they support, which affects which they allow to affect the implicit
submission thing.

> In any case, I believe the spec is wrong in one aspect: in the case that
> there is a default button, what needs to happen is a click event on that
> button, not just a triggering of its activation behavior.  In
> particular, onclick handlers need to fire and the activation behavior
> should only happen if preventDefault is not called on the event.  For
> example, this testcase:
>
>   <!DOCTYPE html>
>   <form action="http://w3.org">
>     <input type="text" value="Focus me and hit enter">
>     <input type="submit" onclick="alert('haha'); return false;">
>   </form>
>
> should alert and not submit.  Yes, I know this is totally screwy.  :(

Oh, wow, yeah, the spec was just bogus there, sorry about that. I never
got around to updating it to handle the activation behaviour stuff
properly after fixing that a few years back.

Fixed.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ian Hickson]

On Fri, 29 Jun 2012, Boris Zbarsky wrote:

> On 6/29/12 6:19 PM, Boris Zbarsky wrote:
> > In any case, I believe the spec is wrong in one aspect: in the case
> > that there is a default button, what needs to happen is a click event
> > on that button, not just a triggering of its activation behavior. In
> > particular, onclick handlers need to fire and the activation behavior
> > should only happen if preventDefault is not called on the event.
>
> Note that depending on how <input disabled> defines handling of click
> events, we may get the right thing happening with it for free.
> Unfortunately, I'm failing to find where the spec talks about the actual
> behavior of @disabled on submit controls.  :(

It's a bit of a tortuous route.

The definition of <input> says:

# The disabled attribute is used to make the control non-interactive and
# to prevent its value from being submitted.
 - http://www.whatwg.org/specs/web-apps/current-work/#the-input-element

...which links to:

# A form control is disabled if its disabled attribute is set [...]
 - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-disabled

This is used in the <input> element section:

# When an input element is disabled, it is immutable.
 - http://www.whatwg.org/specs/web-apps/current-work/#concept-input-immutable

This is then used in the type=submit definition:

# If the element is immutable, it has no activation behavior.
 - http://www.whatwg.org/specs/web-apps/current-work/#submit-button-state-(type=submit)

And now the implicit submission section says:

# If the platform supports letting the user submit a form implicitly (for
# example, on some platforms hitting the "enter" key while a text field is
# focused implicitly submits the form), then doing so for a form whose
# default button has a defined activation behavior must cause the user
# agent to run synthetic click activation steps on that default button.
#
# Consequently, if the default button is disabled, the form is not
# submitted when such an implicit submission mechanism is used. (A button
# has no activation behavior when disabled.)
 - http://www.whatwg.org/specs/web-apps/current-work/#implicit-submission

HTH,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Boris Zbarsky]

On 6/29/12 7:20 PM, Ian Hickson wrote:
> The main difference was that Chrome and Firefox differ in what input types
> they support, which affects which they allow to affect the implicit
> submission thing.

Oh, ok.  Yeah, that's a bit of a mess... ;)

> Oh, wow, yeah, the spec was just bogus there, sorry about that. I never
> got around to updating it to handle the activation behaviour stuff
> properly after fixing that a few years back.
>
> Fixed.

Looks good, thanks.

-Boris