Apparently some of our form users are trying to add new lines in a text
field and are hitting the <enter> key thus causing the form to be submitted
prematurely. There is no algorithm we can write that can determine that the
user isn't actually finished filling out the form so the form just gets sent
as is.

The only solution I can think of is to catch the <enter> key and simply
ignore it. I've done that in a test form (it feels very strange hitting the
<enter> key and having nothing happen.) and I can certainly release that
version. Just wondering if anyone else has had to solve this issue.

Wes wrote:[color=blue]
> Apparently some of our form users are trying to add new lines in a
> text field and are hitting the <enter> key thus causing the form to
> be submitted prematurely.[/color]

None of my web forms will submit when the enter key is pressed - while
the focus is within the text field(s).
[color=blue]
> There is no algorithm we can write that can determine that the user
> isn't actually finished filling out the form so the form just gets
> sent as is.[/color]

Something else is amiss. The cursor is not actually in the text field,
if the enter key is submitting it.
[color=blue]
> The only solution I can think of is to catch the <enter> key and
> simply ignore it. I've done that in a test form (it feels very
> strange hitting the <enter> key and having nothing happen.) and I
> can certainly release that version. Just wondering if anyone else
> has had to solve this issue.[/color]

Never been an issue for me, for a very long time.

--
-bts
-This space intentionally left blank.

Previously in comp.infosystems.www.authoring.html, "Beauregard T.
Shagnasty" <a.nony.mous@example.invalid> said:
[color=blue]
> None of my web forms will submit when the enter key is pressed - while
> the focus is within the text field(s).[/color]

IIRC it is the default behaviour in some (most?) browsers when there is
only one text field - try Google for example.
[color=blue]
> Something else is amiss. The cursor is not actually in the text field,
> if the enter key is submitting it.[/color]

As above it could be, if there is only one text field in the form.

--
Mark Parnell
http://www.clarkecomputers.com.au

Mark Parnell wrote:[color=blue]
> Previously in comp.infosystems.www.authoring.html, "Beauregard T.
> Shagnasty" <a.nony.mous@example.invalid> said:
>[color=green]
>> None of my web forms will submit when the enter key is pressed -
>> while the focus is within the text field(s).[/color]
>
> IIRC it is the default behaviour in some (most?) browsers when
> there is only one text field - try Google for example.[/color]

Ah, you're right. My apologies; I was thinking of a <textarea> field.

Need some sleep ...
--
-bts
-This space intentionally left blank.

On Wed, 24 Aug 2005, Wes wrote:
[color=blue]
> Apparently some of our form users are trying to add new lines in a text
> field and are hitting the <enter> key thus causing the form to be submitted
> prematurely. There is no algorithm we can write that can determine that the
> user isn't actually finished filling out the form so the form just gets sent
> as is.[/color]

You might change it to a textarea.
[color=blue]
> The only solution I can think of is to catch the <enter> key[/color]

AFAIK, from the server side the only way to do that would involve sending
them some javascript, which in a www context some users will have disabled
for security reasons.
[color=blue]
> Just wondering if anyone else has had to solve this issue.[/color]

Detailed behaviour depends on the browser, but in the final analysis you
(as provider) can't always prevent an arbitrary user from submitting an
incomplete form, whether by accident or mischievously. If the situation
is critical, you could have two "submit" buttons with different name/value
pairs, noting that if Enter is used to submit a form when the focus is not
on either of them, typically the server will get sent the name/value pair
of the first one (or the name/value pair of neither of them), which you
can test for. So the first Submit button would be marked "Preview" and
the second one would be "Modify". You would only action the modification
if the server had seen the name/value pair of the Modify button in the
submission, otherwise you would re-display the proposed modification and
await further user action.

In less critical situations, perhaps no particular defence is needed,
other than asking users to verify their changes and re-modify them if they
weren't what was intended.

There are actually quite a few forms that prevent being submitted
through pressing the enter key. Most of these are secure forms for
logging into your bank accounts, etc. I reckon that when you actually
press submit there is a process going on that checks whether the form
was submitted form the right place to prevent abuse. It may also
prevent bots from continously hitting the form (are they able to do
that???)