Doubleclicking on the Web (2015)

41 points by Mojah 4 years ago | 26 comments
  • jchw 4 years ago
    If you want a better server-side solution, you could try employing mandatory idempotency tokens in the request payload. The concept is simple: either have the server give the client an idempotency token as part of the page load, or have the client request one at some point, or have it be something that can be generated on the client side (nonce style) and send it with the request. The server can then validate, using some strongly consistent system, that it has not received any requests in a certain window of time with that token. (Or, possibly, react with the existing response.)

    This has an additional benefit that even methods like PUT do not: it works no matter how many layers of your stack might have retry behavior (properly or improperly) and enables safe retry even when you can’t be sure if the request went through or not. The primary downside is that it introduces a single point of failure, though you could theoretically shard it by some property of the request such as the session key/user id/IP address. Still desirable if you have something you really don’t want to repeat, like a transaction. (Probably would be wise to also make those multiple stage, but nonetheless.)

    Goes without saying you should definitely still mitigate this on the client side by updating the UI state if JavaScript is available.

    • sippeangelo 4 years ago
      CSRF tokens solve this problem for free
      • jchw 4 years ago
        AFAIK typical CSRF token implementations allow for reuse, and unlike an idempotency token necessarily need to be generated by a trusted server. They solve a different problem.
    • ktpsns 4 years ago
      Interestingly, the only persons I've ever seen doubleclicking in the web are from my parent generation (>60, >70 years old).

      Also since 2015 the mobile adaption increased more and more. On mobile devices, the "double tap" concept never was very important, I think (at least not in the web context).

      Therefore my feeling is that this issue is mostly a thing from the past.

      Nevertheless I sometimes see forms which implement this "disable after submission" principle. Especially when it's about money, such as when booking a hotel or flight, etc.

      • Thorrez 4 years ago
        I've actually heard people verbally use the word "doubleclick" to mean explore. For example, someone in a meeting might mention some idea. Then my colleague would say "let's doubleclick on that for a minute".
        • toomanybeersies 4 years ago
          I'm going to start using that in my meetings, alongside "drill down", "circle back", and "take it offline".

          Office Space became a lot less funny when I started living it.

          • mauvehaus 4 years ago
            My person pet peeve jargon is people who use surface in sentences like "what ideas does this surface?"

            Unless you're a submarine, surface isn't a verb!

          • prox 4 years ago
            Looks like someone has a case of the mondays ;)
          • tuxxy 4 years ago
            Wow, that's truly awful.
            • jdbernard 4 years ago
              It gets worse.

              Where I am people use "doubleclick" and "tripleclick" as nouns to represent specific levels of detail. As in, "I think we've got a good story for the doubleclick but I want to hear more about the tripleclick on Topic X."

          • wingerlang 4 years ago
            I don’t feel like I double click much at all in Windows and macOS nowadays at all.

            Literally only to open a file from finder, which I use in column mode so navigating is single clicking.

            • anuila 4 years ago
              This is something I usually take care of by throttling the relevant event listeners (in an AJAXed site) but the way this article puts it makes me wonder if this is as easy as globally disabling double clicks on links and buttons:

                  document.addEventListener('dblclick', event => {
                    if (event.target.closest('a, input, button'))
                      event.preventDefault()
                  })
              • Koffiepoeder 4 years ago
                Would be careful with this (if it works), double clicking can be used to select text, which might turn out to be annoying when disabled in non-button inputs - certainly on mobile I use it a lot.
              • spiznnx 4 years ago
                If the client-side solution is so simple, what's the problem? There are many things on the web where, if given a clean slate, it would be nice to change the default behavior. This doesn't seem to rise to the top of that list.
                • TonyTrapp 4 years ago
                  For the sake of everyone who loves using the back button, please don't disable links when clicking on them.
                  • akersten 4 years ago
                    The proposed solution (an HTML attribute to 'allow' double-click submissions of <form>s) is backwards from how the standard would be updated.

                    The proposal should instead be for an attribute that prevents double-clicks, because that way browsers that have not implemented it still behave correctly. Additionally, you don't "break userspace" for millions of forms online that no longer work as the developer intended.

                    However, I'm skeptical that we need to encode this at all into the standard, since setting the `disabled` attribute on the submission button after submission is pretty much test case #0 of any serious online form development.

                    Amusingly, things have gotten a lot better since 2015 when this was written. That blob of JQuery is now replaced with binding the `disabled` attribute to `isSubmitted` state on your React-based webform. An interesting glimpse into the web-that-used-to-be.

                    • recursive 4 years ago
                      And it used to be even better than that before React and JQuery.

                      `<button onclick="this.disabled=true">button</button>` worked in the 90s.

                      • a1369209993 4 years ago
                        Except that for the overwhelming majority (admittedly not literally all) of those forms, no-double-click is how the developer intended them to work. If anything, I call [citation needed] on the implication that there is any <form> anywhere that actually expects or relies on double-clicks producing two different HTTP requests.
                      • emmelaich 4 years ago
                        Similar problem occurs with the Windows task bar and Mac dock.

                        I've seen new users in particular double click to open.

                        Then, since the machine is so busy, nothing happens for a bit.

                        Concerned, the user then double clicks again. At this point they start to despair or curse.

                        • saagarjha 4 years ago
                          Double clicking on the Mac dock should be idempotent.
                          • bobbylarrybobby 4 years ago
                            It is
                            • saagarjha 4 years ago
                              Well, you can make a bad Mac app that makes this not true. But that’s really on you.
                        • treve 4 years ago
                          Another way this _could_ be solved is to allow HTML authors to use idempotent HTTP methods like PUT.

                          Sadly, it doesn't seem browser vendors are very interested to support this.

                          • vim-guru 4 years ago
                            I'm certain that there's a lot of these issues that could be solved browser-side. Something for a breaking html6 maybe
                            • squam 4 years ago
                              > What if a double-click is blocked by default

                              I agree this would be a more sensible behavior for form submission, but given that ship has long since sailed: https://xkcd.com/1172/