Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Double-clicking on the Web

ma.ttias.be

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Double-clicking on the Web

#81

Post by eXpl0it3r »

All I can think of is that someone is using the mouse (and keyboard) quite a bit different than I do.

I can understand that single vs double clicking can be an issue with non-technical users, but disabling double click won't really change that issue, because they usually don't understand that these are two different actions. Of course one can and should try to make things easier for them, but once it starts to affect the usability for others, it's not really worth it anymore. These people should learn to adjust their behavior.

Now that this is out of the way, I really wonder what he meant with:

> For techies like us, a double-click happens by accident.

What kind of techies is he talking about, because I'm using the PC many hours each day and I don't just accidentally double click stuff. Maybe it's the environment they're working with, but for me I'd say, I do a larger portion of single-clicks than double-clicks per day and if a signification percentage were accidental double-clicks I would have more issues that just a site that opens twice.

And last but not least I'd say a big percentage of my clicks on the web are middle clicks anyways, i.e. open link in a new tab. Something that wasn't even looked at, which again makes me wonder how the author is using the web.

What we can learn from this however is, that websites should add checks to prevent double submissions of forms. And provide proper feedback if e.g. an AJAX submission failed or if it's still sending data.

Re: Double-clicking on the Web

#82

Post by ptx »

Here's an example of what happens when you try to treat single- and double-click as the same thing (which may or may not have been the intent in this particular case).

In Android 5.0, swiping from the top brings up the notification menu and a two-finger swipe brings up the settings shortcuts. From the shortcuts screen, the back button brings you back to the notification menu. Another press of the back button brings you all the way back to where you were.

So to quickly go back after bringing up the shortcuts screen, you would naturally press the back button twice in quick succession. But that's a lot like a double-click, and if we want to treat those as single-clicks ... it has to ignore one press and just bring you back to the notifications screen instead. Which is exactly what happens.

So to actually go back twice, which is a very common and natural thing in this case, you have to go back ... then wait ... wait ... and then finally go back again.

> If the same form submit has been registered by the browser in less than 2 seconds, surely that must have been a mistake and would count as an accidental double-click?

Or maybe they're using POST requests to control some process which they get feedback from through another channel. They could be rotating pieces in a Tetris game – should I have to wait for 2 seconds between my two identical commands for rotating a piece 180 degrees to the right?

Re: Double-clicking on the Web

#83

Post by snowwolf »

oldmanjay wrote: post #65
snowwolf wrote: post #50

Earlier quoted context omitted.

The problem isn't idempotency as that just solves the problem of multiple synchronous submits (If order submitted what happens if order is submitted again). The real problem is the asynchronous nature of the web where both submissions could arrive at exactly the same time. And this is solved generally by using some kind of global lock (often at the database level).

coarse locking is only a possibility at fairly small scales, unless your users like waiting. CSRF protection is the solution here as well. this entire article could have one comment that says nothing more and it would perfect.

Who said anything about course locking? Most databases support row level locking (think lock user row so each user cannot submit multiple orders at the same time).

And I think you are misunderstanding CSRF. As the name implies it is protection against Cross Site attacks and will do nothing to help you prevent race conditions.

Re: Double-clicking on the Web

#84

Post by mbell »

scrollaway wrote: post #69
mbell wrote: post #68

Earlier quoted context omitted.

This just moves the concurrency issue to the client, particularly for xhr requests. Say you double click on some action with a one time token, the first request gets to the server and succeeds while the second request fails due to the token being used. But, the response to the first request is delayed and the second response (failure) gets to the client first. The client can either 'obey' this failure response or wai…

Subsequent requests to the same token don't have to fail - they just have to silently pass.

That doesn't make the situation any better.

Request 1 takes the 'token'

Request 2 sees the token gone, returns 'silent success'

Request 2 response reaches client, client assumes success.

Request 1 fails somewhere internally

Request 1 returns failure to client, which has already acted on the success of request 2

User thinks the action was successful, when it wasn't.

Now, you can build yourself a lovely two phase commit system around the token and the operations performed by the action to deal with a UI issue, or you can just throttle the requests.

Re: Double-clicking on the Web

#85

Post by Retra »

DonHopkins wrote: post #64
nailer wrote: post #56

Earlier quoted context omitted.

OK I'm wrong. I use a Mac every day and thought they didn't do double click. Apparently it's a somewhat subconscious action.

Wasn't that the whole point of the article? How many times did he point that out? More than two: >Everywhere in the Operating System, whether it's Windows or Mac OSX, the default behaviour to navigate between directories is by double-clicking them. We're trained to double-click anything. >Want to open an application? Double-click the icon. Want to open an e-mail in your mail client? Double-click the subject. Double-c…

Following a link and opening a directory are distinct enough in most people's minds to not confuse the two. That's why hyperlinks are normally underlined, colored, and give you a different mouse cursor.

Re: Double-clicking on the Web

#86

Post by 13 »

atomwaffel wrote: post #47
13 wrote: post #39

Earlier quoted context omitted.

This gets seriously annoying if you have an intermittent connection. I know the first click didn't succeed, so I have the choice of refreshing and losing all my typed content or manually using the web inspector to re-enable the button. It's shitty user experience.

Sorry, you might want to re-read my comment. My solution will only disable the button or link that has been clicked on for half a second, which ought to be enough to both prevent accidental and allow intentional resubmissions.

Ah! Yes I jumped to an assumption there. That's a much better solution.

Re: Double-clicking on the Web

#87

Post by Retra »

sjwright wrote: post #32

Browser makers like Mozilla think it's appropriate that holding down F5 should repeatedly pummel the server in accord with keyboard repeat rates. It's like the browser makers are being intentionally hostile towards web servers. E.g. https://bugzilla.mozilla.org/show_bug.cgi?id=224026 https://bugzilla.mozilla.org/show_bug.cgi?id=873045 There's no excuse, but they don't fix it.

So rather than fix your one server to be more robust, every one of the thousands of browsers that exist should change?

Re: Double-clicking on the Web

#88

Post by scrollaway »

mbell wrote: post #84
scrollaway wrote: post #69

Earlier quoted context omitted.

Subsequent requests to the same token don't have to fail - they just have to silently pass.

That doesn't make the situation any better. Request 1 takes the 'token' Request 2 sees the token gone, returns 'silent success' Request 2 response reaches client, client assumes success. Request 1 fails somewhere internally Request 1 returns failure to client, which has already acted on the success of request 2 User thinks the action was successful, when it wasn't. Now, you can build yourself a lovely two phase commi…

If the first request errored, you can error on the second one as well. I don't see the problem.

Re: Double-clicking on the Web

#89

Post by mbell »

scrollaway wrote: post #88
mbell wrote: post #84

Earlier quoted context omitted.

That doesn't make the situation any better. Request 1 takes the 'token' Request 2 sees the token gone, returns 'silent success' Request 2 response reaches client, client assumes success. Request 1 fails somewhere internally Request 1 returns failure to client, which has already acted on the success of request 2 User thinks the action was successful, when it wasn't. Now, you can build yourself a lovely two phase commi…

If the first request errored, you can error on the second one as well. I don't see the problem.

If there is no throttling, there could be a dozen requests, with different responses arriving in arbitrary order. Which one do you believe to determine the outcome of the operation? How long do you wait for responses? etc. etc. If your going to build all the machinery in the client to deal with this situation, it's much easier to just throttle.

Re: Double-clicking on the Web

#90

Post by scrollaway »

mbell wrote: post #89
scrollaway wrote: post #88

Earlier quoted context omitted.

If the first request errored, you can error on the second one as well. I don't see the problem.

If there is no throttling, there could be a dozen requests, with different responses arriving in arbitrary order. Which one do you believe to determine the outcome of the operation? How long do you wait for responses? etc. etc. If your going to build all the machinery in the client to deal with this situation, it's much easier to just throttle.

I'm not saying "don't throttle". I'm just saying tokens can work pretty well too...
Post reply on HN