At 4:02 PM -0400 5/23/06, Robert Cummings wrote:
On Tue, 2006-05-23 at 15:01, Paul Novitski wrote:
At 11:08 AM 5/23/2006, Lester Caine wrote:
>I could not believe that double clicking a link would run the link
>twice. It just does not make any sense. So I've been round the
>browsers. IE does NOT process the link twice how ever I try and
>since all the user sites are IE they should be OK.
>Moz, Firefox and Sea Monkey *DO* run the link twice, and any code
>attached to that link.
>I can't believe that this has not surfaced before. I should not need
>to prevent duplicate actions, but it looks as that is required by
>the Mozilla browsers :(
Just to clarify, there's a difference between "double-clicking" and
clicking more than once before the form completely submits.
Double-clicking is a GUI event, the two mouse clicks bound together
as a single event as defined by your mouse properties in your
computer's operating system.
It is certainly possible to single-click once to submit a form, then
single-click again to submit the same form a second time before the
first request has completed. This sends two submissions to the
server and is a common problem on pages that have left this door wide open.
Before I wandered off into the dense jungle of possible browser bugs,
I'd make absolutely sure my users can't submit the form more than once.
There is no way you can prevent your users from clicking more than
once unless you visit them and physically restrain them, a strategy
which would quickly exhaust your resources and soon curtail your
personal freedom. Instead, you have to assume that some of your
users WILL multiply click (whether deliberately or accidentally) and
plan for that contingency. Multiple submissions can happen for a
variety of reasons:
- maliciousness;
- accidentally clicking twice (happens to me when I've been working
too long: my mouse button finger sometimes just clicks of its own accord);
- getting impatient with a form submission that takes more than a few
seconds and either clicking again or reloading the form to try again.
A client-side solution is for Javascript to disable the submit button
onsubmit(), however this wouldn't prevent the user from reloading the
page and submitting a second time and wouldn't work at all if
scripting were disabled.
A server-side (and therefore more robust) solution is to accept only
one form submission from each user/session.
An additional strategy to make your system more robust is to use
three pages for your form submission:
1) the form itself, which submits to:
2) the script that processes input, which redirects to:
3) the page that displays the results (or is the next form in a sequence).
Even if the user reloads the results page (3) they won't be
resubmitting the form (1) or repeating the input processing (2).
I think a 2 page scenario is simpler and more elegant:
1) the form itself, which submits to itself for validation
and re-presenation in case of validation errors
(including multiple submission of same form - such as
going back in browser). This also means if errors occur
then the form can be presented with previously
submitted data.
2) the final destination page(s) after the form has been
submitted with successful validation to which the user
is redirected (preventing reload submissions).
Cheers,
Rob.
-
Considering that everyone is putting in their $0.02, here's my suggestion.
1. Keep the form and processing on one page. The number of pages is
not the problem -- double clicking is.
2. Start a session.
3. Initialize a variable that is incremented each time the page is
refreshed per session.
4. If the variable's value is larger than one, then do something
other than create and insert a duplicate record. Allow the user one
insert per session or whatever.
If you want a very simple example that deals with clicks, see this:
http://xn--ovg.com/session
No matter how many times you double click that link, it will not
increment more than once (at least that's been my experience). In
other words, you can't get it to jump more than one.
If you want code, then see this:
http://www.weberdev.com/get_example-4349.html
tedd
PS: For several reasons, don't rely on javascript to control what the
user is doing.
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
