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

31–40 of 109 posts

Re: Double-clicking on the Web

#31

Post by babuskov »

jxf wrote: post #18

HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…

I wish I could upvote this more than once. In the company I worked for for 10+ years (2002-2013) we had a huge web application used heavily by 500+ users daily. I have seen a lot, and the one-time-token approach is the only bulletproof way to solve this once and forever.

It's not only the double-click that causes problems. For example, user might click and if the server does not respond right away it might seem that click did not get accepted, so the user will try to click again 3-4 seconds later. The one-time token solves this problem as well.

Then you might have AJAX stuff that gives no feedback until the server does its job (which might take a while if it's under load at the time) and if you disable the button it prevents the user to retry. Sure, you can add indeterminate progress bars and animations, but users quickly learn to ignore those if they don't get any response from the server in expected time.

What really should be done is educating developers to implement this pattern. Any beginner book that talks about HTML and HTTP should include this. Unfortunately, it's so easy to enter web development today that many people have to learn from their own mistakes, and reinvent the wheel over and over again.

Maybe I'm too pessimistic, but I just don't see it happening.

Re: Double-clicking on the Web

#32

Post by sjwright »

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.

Re: Double-clicking on the Web

#33

Post by quotemstr »

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.

> There's no excuse, but they don't fix it.

Browsers exist for my convenience, not yours.

Re: Double-clicking on the Web

#34

Post by snowwolf »

Because never trust user input and race conditions.

The author says "Server-side, this is a much harder problem to solve." and he is correct. But that doesn't mean that if the browsers did solve this problem that you wouldn't still need to solve it server side. For the same reason you still need to implement server side validation even though you have client side validation (never trust user input).

Say you had an order form only allowing one order per customer (some special offer) and on the server you have a check to ensure order.count==1 you might assume that because the browser prevents double clicks on the form you are now safe. Except you aren't. It's pretty trivial to still send that form submission multiple times simultaneously (curl, ab) and trigger a race condition where each order.count check returns 0.

Re: Double-clicking on the Web

#35

Post by rwallace »

reinhardt wrote: post #24
denma wrote: post #3

That reminds me of the way my mother is using a computer. She clicks EVERYTHING twice. No matter if online or offline. That often causes problems. For example if you double-click an icon in the windows taskbar to open an application it opens twice.

Mine is the opposite, she never double clicks despite numerous attempts to teach her. Not sure about online but offline she "right-click + open"s everything, which is painful to watch.

Just set her desktop to single click mode?

Re: Double-clicking on the Web

#36

Post by smorrow »

I was using that Google 3D plot viewer thing the other day and assumed right-click-dragging would do something for me. It didn't, and it occurred to me that the reason we have this is that Microsoft, Apple, or some other microcomputer vendor once decided people were too dumb to know they have more than one finger.

And now on the subject of double-clicking, it occurs to me that if the one-finger thing hadn't been the way, everything that was ever a double-click action could've just been a single click on the next button over. Which would be simpler.

Re: Double-clicking on the Web

#37

Post by xrstf »

nailer wrote: post #30
nodesocket wrote: post #9

Is it me, or why is a setTimeout needed in this example? $(document).ready(function(){ $("form").submit(function(){ setTimeout(function() { $('input').attr('disabled', 'disabled'); $('a').attr('disabled', 'disabled'); }, 50); }) });

50 should be a constant called NEXT_TICK with a value of 0. This makes it run on the next event loop, ie, default event submit form, next tick afterwards the form is disabled

You are looking for setImmediate[1].

EDIT: Oh, never knew that this method was a Node-ism only.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/setI...

Re: Double-clicking on the Web

#38

Post by atomwaffel »

jxf wrote: post #18

HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…

While I agree that you should include a one-time token with all sensitive forms, I don't think that disabling links/submit buttons on the first click is a bad idea in general. It's an easy fix that will immediately prevent most accidental redundant server requests, but as it's a client-side fix it's inherently unreliable.

What's wrong though is the author's solution of disabling _all_ links and submit buttons on the page indefinitely. Here's an alternative solution that only disables whatever has been clicked on for half a second:

    (function() {
      function stopClickEvent (ev) {
        ev.preventDefault();
        ev.stopPropagation();
      }
      document.body.addEventListener('click', function (ev) {
        if (ev.target.tagName === 'A' || ev.target.getAttribute('type').toLowerCase() === 'submit') {
          setTimeout(function () {
            // Needs to happen _after_ the request goes through, hence the timeout
            ev.target.addEventListener('click', stopClickEvent);
          }, 0);
          setTimeout(function () {
            ev.target.removeEventListener('click', stopClickEvent);
          }, 500);
        }
      });
    })();
Unlike the author's solution, this really works for links (they don't support the `disabled` attribute), it doesn't change the appearance of the button, it only disables one element, and it will work for elements that have been added to the document after the DOM was loaded. You can try it here: http://codepen.io/anon/pen/xGKdLX

Re: Double-clicking on the Web

#39

Post by 13 »

atomwaffel wrote: post #38
jxf wrote: post #18

HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…

While I agree that you should include a one-time token with all sensitive forms, I don't think that disabling links/submit buttons on the first click is a bad idea in general. It's an easy fix that will immediately prevent most accidental redundant server requests, but as it's a client-side fix it's inherently unreliable. What's wrong though is the author's solution of disabling _all_ links and submit buttons on the…

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.

Re: Double-clicking on the Web

#40

Post by riquito »

captainmuon wrote: post #7

Firefox seems to remove the second click sometimes. If I click a link, and then, while the page is loading but the old page is still visible change my mind and click another link, it sometimes ignores the second click. However it doesn't seem to happen all the time. As an aside, the distinction between double click and single click used to be much clearer (in Windows 3.1/95 times!): - If its on a white background, ma…

> Firefox seems to remove the second click sometimes. If I click a link, and then, while the page is loading but the old page is still visible change my mind and click another link, it sometimes ignores the second click. However it doesn't seem to happen all the time.

To have better response time (and be a good citizen and save bandwidth), if you try to load in quick succession two different pages the first request is aborted. If you're too late the content of the first request has already been downloaded and being processed, resulting in that page being loaded.

Post reply on HN