This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11347 - Submitting a partially downloaded form
Summary: Submitting a partially downloaded form
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-19 11:29 UTC by Ed Avis
Modified: 2011-08-04 05:34 UTC (History)
6 users (show)

See Also:


Attachments

Description Ed Avis 2010-11-19 11:29:13 UTC
Suppose a browser is downloading a page and has got halfway through a form with some text elements.  Before the rest of the form finishes downloading, the user puts focus in one of the elements and presses Enter.  Normally that keystroke would submit the form.  Should the browser submit the form anyway even though it has not finished downloading?  Doing so would omit some form elements which might be marked mandatory.

The HTML 4 standard doesn't say anything on this one way or the other, though it is implied that everything inside the <form> element should be considered, not just the part that happens to have been downloaded so far.  HTML 5 may make things
a little more complex in that form elements can appear anywhere in the document,
so you don't know that a form is complete until the document has been fully
downloaded.

Related Firefox bug report: <https://bugzilla.mozilla.org/show_bug.cgi?id=607328>
Comment 1 Ian 'Hixie' Hickson 2010-12-31 07:12:01 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The spec is clear that yes, the incomplete form should be submitted. There's not much we could do about this short of preventing form submissions entirely before the page is completely loaded. Note that even after the page is loaded, it's possible that scripts are going to further populate the form so even then it might not be ready. If this is a problem in practice, authors are encouraged to add something to the form after everything else has been added, marking the form as complete, and having server-side scripts check that the client only sent complete forms.
Comment 2 Ed Avis 2010-12-31 10:37:03 UTC
The spec is clear that yes, the incomplete form should be submitted.

Could you point that bit out?  I don't see anything in
<http://www.w3.org/TR/html401/interact/forms.html>
mentioning it one way or the other.

(I intended to submit a bug report against the HTML 4 spec and was eventually
pointed to this bug tracker - let me know if this is not the right place for
such bugs, or if HTML 4 is no longer being maintained by the W3C.)
Comment 3 Aryeh Gregor 2010-12-31 18:52:57 UTC
To the best of my knowledge, HTML 4 is no longer being maintained.  It is superseded by HTML5, which is the component this bug was filed against.  HTML5 leaves the question of implicit submission up to the browser, since it's really a UI thing:

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

Generally speaking, what interface is available to the user is up to browsers, not specs.  Browsers are allowed to have whatever UI they want to prevent users from making mistakes or whatever.  But from HTML5's perspective, forms can certainly be submitted even if they aren't fully downloaded -- e.g., if a script calls submit() on the form when it's not fully downloaded, it would certainly have to be submitted.

Authors can work around this in practice by including a hidden input after all the other form elements, and rejecting form submissions that don't include the hidden input.  It's not ideal, but I don't see a much better way given the need for progressive rendering.
Comment 4 Ed Avis 2010-12-31 19:40:12 UTC
Ah.  I thought that since HTML 5 wasn't finalized yet, the latest W3C Recommendation was still HTML 4.01.  But if everyone has moved to HTML 5 already, I'm happy to move with them.  So let's look at what the standard says:

>If the form has no submit button, then the implicit submission mechanism must
>just submit the form element from the form element itself.

But it's not clear from this text how to determine whether 'the form has no submit
button'.  Does it mean if the download made by the browser so far does
not include any <input type="submit">, even if the download so far is obviously
a partial download?  If so, that needs to be stated IMHO.

An equally plausible reading of the text is that to determine whether 'the form
has no submit button' then the browser needs to download the <form> element at
least.

I apologize if there is some general principle elsewhere in the spec that says
'for a partially downloaded page, the semantics are as if you close
all the open elements and take that as the full HTML document', but I didn't see
anything like that.

So I think there is a decision to be made here about at what point a form can be
submitted.  If the decision has already been made, it needs to be stated
explicitly.
Comment 5 Aryeh Gregor 2011-01-02 00:34:11 UTC
(In reply to comment #4)
> But it's not clear from this text how to determine whether 'the form has no
> submit
> button'.  Does it mean if the download made by the browser so far does
> not include any <input type="submit">, even if the download so far is obviously
> a partial download?  If so, that needs to be stated IMHO.

The HTML5 standard is defined in terms of the DOM.  The section on parsing defines how to incrementally proceed from a stream of input bytes to a DOM, adding each node one by one.  If a UA chooses to make the document visible and interactive to the user before the entire document is loaded, the spec applies as-is to the DOM as it currently exists.  If the the form has no submit button in the DOM that has so far been constructed, the form has no submit button (even if it might get one later).

This is all sort of fundamental to the idea of progressive rendering.  I don't know if it's stated clearly anywhere, but I'm pretty sure it's clear if you read the right parts of the spec.  When the document is only partially loaded, it's treated mostly the same as if the rest of the document just didn't exist.  Since, after all, it hasn't been parsed yet, or maybe not even received.

> An equally plausible reading of the text is that to determine whether 'the form
> has no submit button' then the browser needs to download the <form> element at
> least.

This is not the correct reading.

> I apologize if there is some general principle elsewhere in the spec that says
> 'for a partially downloaded page, the semantics are as if you close
> all the open elements and take that as the full HTML document', but I didn't
> see
> anything like that.

This is basically the case, although I don't know offhand where specifically this is stated or implied.
Comment 6 Ed Avis 2011-01-04 12:09:43 UTC
>When the document is only partially loaded,
>it's treated mostly the same as if the rest of the document just didn't exist. 

Thanks for clarifying that.  So, then, the semantics of a partially downloaded form are clear: make it the same as a completed form with the same content.  I think this resolves the original bug report - what follows is discussion for those who are interested.

Is the current semantics a sensible behaviour?  In my view, it is not: it is not helpful for user agents to submit incomplete data when the Enter key is pressed.  There is a workaround by adding a hidden element and checking for it, but this seems a lot of complication for what is surely the common case.  I would have chosen safety by default (don't submit the form until it is complete, at least by the measure used in HTML 4 and earlier of a closing </form>) with a possible way to choose the unsafe behaviour of 'just submit whatever is there' if the web site author really wants it.

So, if I were granted a wish for this, I would have something like

<form ready-to-submit=
   "end-of-document | end-of-element | submit-button-seen | no | yes" >

with the default value being the most conservative, 'end-of-document', meaning do not allow the form to be submitted until the whole page has been downloaded.  The value 'no' is for use with Javascript: when the script has done its stuff it can mark the form as submittable.

However I guess it is too late to submit such a suggestion for HTML 5?
Comment 7 Aryeh Gregor 2011-01-05 23:13:25 UTC
HTML5 doesn't really handle exactly what hitting Enter in a particular form field does.  It's up to browsers to decide if they want to submit the form in response to specific user input.  You should be trying to persuade browsers to change here, not HTML5.

If you don't want the bug to remain open, by the way, you can reclose it to save Ian the trouble.
Comment 8 Ed Avis 2011-01-05 23:55:11 UTC
See the Firefox bug linked to above.  I started out asking if the browser behaviour could be changed to something more sensible, but they pointed me to the W3C instead to clarify what the standard says.
Comment 9 Mounir Lamouri 2011-01-06 14:25:21 UTC
The specs do mention one case: if you hit enter on a text control and there is a submit control in the form. In that case, it's not a requirement, the form can be submittable as if the user clicked on the submit control.
AFAIK, the specs don't mention the case where there is no submit control in the form. However, all major browsers have the same behavior: the form is submitted if you press enter in a text field even if there is no submit control.

You can try this:
data:text/html,<form onsubmit="alert('submit!');"><input>

Opera, Chrome, Safari, Firefox and IE (only tested with IE6) have the exact same behavior: the form is submitted.

I would bet that some forms would be broken if we change that. I'm thinking of search fields for example.
Comment 10 Ed Avis 2011-01-06 14:34:30 UTC
>AFAIK, the specs don't mention the case where there is no submit control in the
>form. However, all major browsers have the same behavior: the form is submitted
>if you press enter in a text field even if there is no submit control.

That is true, but it's not the issue here.  The question is the behaviour when
you press Enter in a text field but there is no submit control *because the form
has not yet been fully downloaded*.  To recap the example from the Firefox bug:

<form method="get" action="/cgi-bin/test_page" enctype="multipart/form-data">
  <input type="text" name="y" value="y" />
  <!-- download got here -->
  <input type="text" name="z" value="z" />
  <input type="submit" name=".submit" />
</form>

Suppose the browser has downloaded as far as 'download got here' and displayed
the partial form retrieved so far.  The user clicks in the first text field and
presses Enter.  Should the form now be submitted immediately?

According to earlier replies in this comment, according to the standards the
answer is yes.  A partially downloaded form is not treated any differently from
a fully downloaded one, because of a general principle in the HTML standard that
says 'the spec applies as-is to the DOM as it currently exists'.

Browser behaviour differs: Firefox will submit the partial form when you press
Enter, but Safari will not - it waits for the form to download fully.

In my personal view, submitting the partial form is not a helpful behaviour for
the user, and if this behaviour is the standard, it means web sites have to
resort to clunky workarounds like a 'form complete' hidden field in every form.
Comment 11 Ian 'Hixie' Hickson 2011-02-07 23:05:45 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Comment 1 still applies (and it answers many of the points made after it). The exact user interface here is up to the browser vendors. They're allowed to wait for the page to be loaded (though that's no guarantee that the form is ready any more than not waiting at all, or waiting for </form>, or waiting 10 minutes). My recommendation is to use the hidden="" attribute to hide user interface elements that are not yet fully functional.
Comment 12 Ed Avis 2011-02-08 11:33:20 UTC
>Rationale: Comment 1 still applies

Thanks for considering this.  One thing I wanted to clarify though,

>If this is a problem in practice, authors are
>encouraged to add something to the form after everything else has been added,
>marking the form as complete, and having server-side scripts check that the
>client only sent complete forms.

That's exactly the situation - typically the server side sees that the form is
incomplete and so throws up an error page.  The user (if they understand what
happened) must go back to the page with the form, wait for the whole form to
download this time, and then resubmit.  It would be a smoother user experience
if the form were not submitted until it's complete (by some measure).

It's unfortunate that HTML doesn't have any way to mark the end of a form or the
point when it is complete and submittable (without resorting to Javascript).  The
closing </form> tag no longer indicates that, although it did in earlier versions.
Perhaps some future revision to HTML will include an explicit end-of-form marker.
Until then, I guess a workaround is to always put the textfield as the final
element of the form, so that it can't accidentally be submitted too soon.
Comment 13 Michael[tm] Smith 2011-08-04 05:34:07 UTC
mass-move component to LC1