Stupid user tricks (double-click = double postback)
-
I've just solved an issue that has baffled me for some time. The app in question is a webforms app hosted at Azure. The issue was/is caused by the user double-click a submit button causing double-postbacks and duplicate records in the database. The rate of occurrence was pretty low (about 10 times a week out of around 12K inserts) and really only results in a minor annoyance as the last record is the only one used moving forward. Additionally, it seemed to affect only specific individuals. I racked my brain over this problem multiple times in the past looking for this 'bug' thinking that it might be a hiccup at the web server or a collision at the db. The customer gave me another example this morning to remind me that it was still happening. After a couple of hours of looking for the problem, I took a break. It was then that I considered that maybe they are hitting the submit button twice. At first, I dismissed the idea thinking that it shouldn't even be possible...there's been javascript there all along that should have prevented it anyway! :omg: Then I tried it and behold, there it is! :) It just took a really fast double-click. I still wonder wtf people want to double-click in a web browser??? :confused: Apparently, the existing javascript was only effective when I put a breakpoint in it so I think it may have been a timing issue...the second client-side click registered before the javascript (fired on-click) that was setting it's click event to false. I had to add a couple of hidden fields to actually make it work right.
"Go forth into the source" - Neal Morse
Just because you can... Means it's gonna happen! :laugh: :cool:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I've just solved an issue that has baffled me for some time. The app in question is a webforms app hosted at Azure. The issue was/is caused by the user double-click a submit button causing double-postbacks and duplicate records in the database. The rate of occurrence was pretty low (about 10 times a week out of around 12K inserts) and really only results in a minor annoyance as the last record is the only one used moving forward. Additionally, it seemed to affect only specific individuals. I racked my brain over this problem multiple times in the past looking for this 'bug' thinking that it might be a hiccup at the web server or a collision at the db. The customer gave me another example this morning to remind me that it was still happening. After a couple of hours of looking for the problem, I took a break. It was then that I considered that maybe they are hitting the submit button twice. At first, I dismissed the idea thinking that it shouldn't even be possible...there's been javascript there all along that should have prevented it anyway! :omg: Then I tried it and behold, there it is! :) It just took a really fast double-click. I still wonder wtf people want to double-click in a web browser??? :confused: Apparently, the existing javascript was only effective when I put a breakpoint in it so I think it may have been a timing issue...the second client-side click registered before the javascript (fired on-click) that was setting it's click event to false. I had to add a couple of hidden fields to actually make it work right.
"Go forth into the source" - Neal Morse
i usually disable the buttons using javascript as soon as they're clicked and keep them that way until the page refreshes. it helps
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I've just solved an issue that has baffled me for some time. The app in question is a webforms app hosted at Azure. The issue was/is caused by the user double-click a submit button causing double-postbacks and duplicate records in the database. The rate of occurrence was pretty low (about 10 times a week out of around 12K inserts) and really only results in a minor annoyance as the last record is the only one used moving forward. Additionally, it seemed to affect only specific individuals. I racked my brain over this problem multiple times in the past looking for this 'bug' thinking that it might be a hiccup at the web server or a collision at the db. The customer gave me another example this morning to remind me that it was still happening. After a couple of hours of looking for the problem, I took a break. It was then that I considered that maybe they are hitting the submit button twice. At first, I dismissed the idea thinking that it shouldn't even be possible...there's been javascript there all along that should have prevented it anyway! :omg: Then I tried it and behold, there it is! :) It just took a really fast double-click. I still wonder wtf people want to double-click in a web browser??? :confused: Apparently, the existing javascript was only effective when I put a breakpoint in it so I think it may have been a timing issue...the second client-side click registered before the javascript (fired on-click) that was setting it's click event to false. I had to add a couple of hidden fields to actually make it work right.
"Go forth into the source" - Neal Morse
Haha I had the same thing happen. Sorry to laugh but mine was a bugger to find as well, even though the environment wasn't as complicated as yours. System had been running for about 7 years. It is for Government so their testers gave it a pounding and ticked it off as OK. Then one day an end user said something to me about an issue so I looked through the logs. There it was. Obscure error too. It was really rare but it only ever happened to about 3 users out of about 250. I thought about it and then thought maybe double click. Then tried but it all worked OK. Tried all sorts of things within this stage of a process. Turns out that my double click technique is shit. I practised to get it down from milliseconds to nanoseconds. Yep got the error. When I looked at the code I had a couple of instructions inserted before I disabled the button. Shifted the disable to when the click event happens and then all good. I felt a little embarrassed about it, should have checked the code first, but gee wiz, these 3 users were Olympians of the double click, albeit in a single click application. End users are often Faster, Higher, Stronger or Stupid.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
Haha I had the same thing happen. Sorry to laugh but mine was a bugger to find as well, even though the environment wasn't as complicated as yours. System had been running for about 7 years. It is for Government so their testers gave it a pounding and ticked it off as OK. Then one day an end user said something to me about an issue so I looked through the logs. There it was. Obscure error too. It was really rare but it only ever happened to about 3 users out of about 250. I thought about it and then thought maybe double click. Then tried but it all worked OK. Tried all sorts of things within this stage of a process. Turns out that my double click technique is shit. I practised to get it down from milliseconds to nanoseconds. Yep got the error. When I looked at the code I had a couple of instructions inserted before I disabled the button. Shifted the disable to when the click event happens and then all good. I felt a little embarrassed about it, should have checked the code first, but gee wiz, these 3 users were Olympians of the double click, albeit in a single click application. End users are often Faster, Higher, Stronger or Stupid.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
grralph1 wrote:
End users are often Faster, Higher, Stronger or Stupid.
Not necessarily - it could just be an old mouse. One of the things uSwitches can do when they get old is "bounce" more, and if the time between successive bounces is larger than the hardware (or driver) "debounce" period, you get two clicks for a single press. (Normally there is a cap or similar to swallow the quick bounces, but as the contact surfaces get dirtier and more worn the bounces can be further apart.) Switch Bounce and How to Deal with It[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
grralph1 wrote:
End users are often Faster, Higher, Stronger or Stupid.
Not necessarily - it could just be an old mouse. One of the things uSwitches can do when they get old is "bounce" more, and if the time between successive bounces is larger than the hardware (or driver) "debounce" period, you get two clicks for a single press. (Normally there is a cap or similar to swallow the quick bounces, but as the contact surfaces get dirtier and more worn the bounces can be further apart.) Switch Bounce and How to Deal with It[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Good point. I am aware of this as I come from an electronics background. Plus switch bounce can be an intermittent problem as well, that can come and go, which makes it worse and harder to detect. However this system was a shared station that is in each outlet. So all users in each outlet used the same machine for the function that it was designed for. So in this case it was the super speed of 3 users, at different outlets, if i remember correctly, that were the cause of the issue. Well I should really rephrase that to; No not switch bounce, the developer just stuffed up.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
Haha I had the same thing happen. Sorry to laugh but mine was a bugger to find as well, even though the environment wasn't as complicated as yours. System had been running for about 7 years. It is for Government so their testers gave it a pounding and ticked it off as OK. Then one day an end user said something to me about an issue so I looked through the logs. There it was. Obscure error too. It was really rare but it only ever happened to about 3 users out of about 250. I thought about it and then thought maybe double click. Then tried but it all worked OK. Tried all sorts of things within this stage of a process. Turns out that my double click technique is shit. I practised to get it down from milliseconds to nanoseconds. Yep got the error. When I looked at the code I had a couple of instructions inserted before I disabled the button. Shifted the disable to when the click event happens and then all good. I felt a little embarrassed about it, should have checked the code first, but gee wiz, these 3 users were Olympians of the double click, albeit in a single click application. End users are often Faster, Higher, Stronger or Stupid.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
grralph1 wrote:
System had been running for about 7 years.
This system is almost 4 y/o now. This problem didn't surface until the last year of so, but as stated, it was rare and only produced a minor annoyance for the customers.
grralph1 wrote:
Turns out that my double click technique is sh*t. I practised to get it down from milliseconds to nanoseconds. Yep got the error.
My experience as well! It should be noted that this web app runs inside of a web browser control in a .NET app installed on their POS touchscreen devices. The users could actually be hitting the button with two fingers almost simultaneously.
grralph1 wrote:
End users are often Faster, Higher, Stronger or Stupid.
:thumbsup: And then there is sabotage...around 2 weeks ago, a relatively new user of one of our legacy applications caused an overflow by putting huge numbers into an order screen. The database handled it OK, but the next stage UI did not. Shame on me for not expecting quantities over a billion! :wtf:
"Go forth into the source" - Neal Morse
-
grralph1 wrote:
End users are often Faster, Higher, Stronger or Stupid.
Not necessarily - it could just be an old mouse. One of the things uSwitches can do when they get old is "bounce" more, and if the time between successive bounces is larger than the hardware (or driver) "debounce" period, you get two clicks for a single press. (Normally there is a cap or similar to swallow the quick bounces, but as the contact surfaces get dirtier and more worn the bounces can be further apart.) Switch Bounce and How to Deal with It[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Agreed And the keyboards/mice of today actually are slower because of USB, nevermind the wireless ones and even more latency. IIRC, a PS2 connection could circumnavigate the planet and still be registered in the computer before a Logitech Unity signal is recognized.
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
grralph1 wrote:
System had been running for about 7 years.
This system is almost 4 y/o now. This problem didn't surface until the last year of so, but as stated, it was rare and only produced a minor annoyance for the customers.
grralph1 wrote:
Turns out that my double click technique is sh*t. I practised to get it down from milliseconds to nanoseconds. Yep got the error.
My experience as well! It should be noted that this web app runs inside of a web browser control in a .NET app installed on their POS touchscreen devices. The users could actually be hitting the button with two fingers almost simultaneously.
grralph1 wrote:
End users are often Faster, Higher, Stronger or Stupid.
:thumbsup: And then there is sabotage...around 2 weeks ago, a relatively new user of one of our legacy applications caused an overflow by putting huge numbers into an order screen. The database handled it OK, but the next stage UI did not. Shame on me for not expecting quantities over a billion! :wtf:
"Go forth into the source" - Neal Morse
That last user was either an idiot or crazy.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
That last user was either an idiot or crazy.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
Brisingr Aerowing wrote:
That last user was either an idiot or crazy.
Either way, it was considered my bug and had to be patched, clearly a case of not protecting the user from themselves not to mention code that didn't properly validate variable/field type limits in all screens. I was lazy and simply used a larger datatype. Ideally, I should've triggered Clippy to ask 'Are you really sure you want to order 123,456,789,123 cases of broccoli?'. :laugh:
"Go forth into the source" - Neal Morse
-
Good point. I am aware of this as I come from an electronics background. Plus switch bounce can be an intermittent problem as well, that can come and go, which makes it worse and harder to detect. However this system was a shared station that is in each outlet. So all users in each outlet used the same machine for the function that it was designed for. So in this case it was the super speed of 3 users, at different outlets, if i remember correctly, that were the cause of the issue. Well I should really rephrase that to; No not switch bounce, the developer just stuffed up.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
grralph1 wrote:
However this system was a shared station that is in each outlet. So all users in each outlet used the same machine for the function that it was designed for.
grralph1 wrote:
Faster, Higher, Stronger or Stupid.
I mean, some of them might be stronger than others. Pro tip: Maybe some testers should get high too.
-
I've just solved an issue that has baffled me for some time. The app in question is a webforms app hosted at Azure. The issue was/is caused by the user double-click a submit button causing double-postbacks and duplicate records in the database. The rate of occurrence was pretty low (about 10 times a week out of around 12K inserts) and really only results in a minor annoyance as the last record is the only one used moving forward. Additionally, it seemed to affect only specific individuals. I racked my brain over this problem multiple times in the past looking for this 'bug' thinking that it might be a hiccup at the web server or a collision at the db. The customer gave me another example this morning to remind me that it was still happening. After a couple of hours of looking for the problem, I took a break. It was then that I considered that maybe they are hitting the submit button twice. At first, I dismissed the idea thinking that it shouldn't even be possible...there's been javascript there all along that should have prevented it anyway! :omg: Then I tried it and behold, there it is! :) It just took a really fast double-click. I still wonder wtf people want to double-click in a web browser??? :confused: Apparently, the existing javascript was only effective when I put a breakpoint in it so I think it may have been a timing issue...the second client-side click registered before the javascript (fired on-click) that was setting it's click event to false. I had to add a couple of hidden fields to actually make it work right.
"Go forth into the source" - Neal Morse
kmoorevs wrote:
I still wonder wtf people want to double-click in a web browser??? :confused:
Blame Windows Explorer for that. I know people (non techie and pretty "I don't understand computers, so don't even try to explain me anything") that basically double click all, no matter what or where it is.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I've just solved an issue that has baffled me for some time. The app in question is a webforms app hosted at Azure. The issue was/is caused by the user double-click a submit button causing double-postbacks and duplicate records in the database. The rate of occurrence was pretty low (about 10 times a week out of around 12K inserts) and really only results in a minor annoyance as the last record is the only one used moving forward. Additionally, it seemed to affect only specific individuals. I racked my brain over this problem multiple times in the past looking for this 'bug' thinking that it might be a hiccup at the web server or a collision at the db. The customer gave me another example this morning to remind me that it was still happening. After a couple of hours of looking for the problem, I took a break. It was then that I considered that maybe they are hitting the submit button twice. At first, I dismissed the idea thinking that it shouldn't even be possible...there's been javascript there all along that should have prevented it anyway! :omg: Then I tried it and behold, there it is! :) It just took a really fast double-click. I still wonder wtf people want to double-click in a web browser??? :confused: Apparently, the existing javascript was only effective when I put a breakpoint in it so I think it may have been a timing issue...the second client-side click registered before the javascript (fired on-click) that was setting it's click event to false. I had to add a couple of hidden fields to actually make it work right.
"Go forth into the source" - Neal Morse
I've noticed from time to time that JS events can have significant, sometimes measurable, lag times. Since the JavaScript interpreter is single threaded, there is no such thing as pre-emptive multitasking. I vaguely recall encountering a similar issue several years ago, which I resolved by putting the double-postback preventer script in charge of submitting the form.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Brisingr Aerowing wrote:
That last user was either an idiot or crazy.
Either way, it was considered my bug and had to be patched, clearly a case of not protecting the user from themselves not to mention code that didn't properly validate variable/field type limits in all screens. I was lazy and simply used a larger datatype. Ideally, I should've triggered Clippy to ask 'Are you really sure you want to order 123,456,789,123 cases of broccoli?'. :laugh:
"Go forth into the source" - Neal Morse
Bear in mind that "numbers" like
35e7are often validated as numeric, but of course represent very large numbers (even though they're relatively short in terms of number of characters, so putting a MaxLength on a text field won't stop it!). They can occur in numeric input when a user mis-types. When testing validation of numeric input, it's always worth testing this case. Sorry for a late post on this thread, but it might be of interest/use to someone someday! :) (And as for asking "are you really sure..." you can guarantee that at some point the user will click "yes" and then you're still left with the original bug anyway. ) -
Bear in mind that "numbers" like
35e7are often validated as numeric, but of course represent very large numbers (even though they're relatively short in terms of number of characters, so putting a MaxLength on a text field won't stop it!). They can occur in numeric input when a user mis-types. When testing validation of numeric input, it's always worth testing this case. Sorry for a late post on this thread, but it might be of interest/use to someone someday! :) (And as for asking "are you really sure..." you can guarantee that at some point the user will click "yes" and then you're still left with the original bug anyway. )Yes, I've been bitten by the numeric e but usually always with very small numbers meaning I must have forgotten a round somewhere. :laugh: Actually, the input fields (in my case) only allow numeric chars plus b/s, and period validated at the keypress event. It's a little extra effort, but it's a good first line of defense against invalid data...of course, the clever ones can still copy/paste so you still have to check again. To be honest, I've never even afaik tried a value with an e in it. I'll have to check it out when I have more time! :)
DerekTP123 wrote:
you can guarantee that at some point the user will click "yes"
Yep, whether they mean to or not...so many users don't even bother to read, they just click 'Yes' to dialogue they see. :sigh:
"Go forth into the source" - Neal Morse
