Live data from Hacker News

Double-clicking on the Web

ma.ttias.be

71–80 of 109 posts

Re: Double-clicking on the Web

#71
post #22

I don't see the problem. Contrary to the post, double clicking a link doesn't open it twice, and double clicking a submit button doesn't submit the form twice; at least, not on Chrome or Firefox on Linux.

That's true so I assume that the author is talking about ajax requests. I have a rule to always disable buttons that trigger ajax requests until they finish. Not only does this reduce double-submissions, it makes it clear to the user that their click was successful and to wait for the action to complete.

Re: Double-clicking on the Web

#72
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…

Even before I got into web dev, I assumed something like that one-time-use token could be implemented to solve the problem. But back in the day, every online store had explicit instructions to "only hit submit once". Why didn't they just use the token solution?

Re: Double-clicking on the Web

#73
Please don't disable links permanently! (as in the included jQuery snippet)

If submission gets stuck and doesn't go through (because mobile networks, public wifi, and "cloud" servers have more failure modes than we'd like…) user is stuck with permanently-disabled buttons and can't retry submitting.

Re: Double-clicking on the Web

#74
Browsers do not provide immediate visual feedback on some things for which they should. When you click on a link which exits the page, something visual should happen immediately, long before the new page loads. The browser knows you're leaving. Dimming the page, or some other visual transition, would be a good start. That would make a clear distinction between page-exiting actions and ones which keep the page active.

Re: Double-clicking on the Web

#75
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…

[deleted]

Re: Double-clicking on the Web

#76
This makes no sense. The examples he gives of "double-clicks everywhere" are all instances of the same thing: items that are selected with single-click and opened with double-click.

We're not "trained to double-click anything", unless some particular trainer is extremely misguided.

Double-clicking is used when there is some action available for an item in addition to the single-click action, where the double-click usually leads to both actions taking place: we single-click to select files and double-click to open them, single-click the title bar to activate the window and double-click to maximize, single-click the window menu to view the menu and double-click to close the window (which is one of the options in the menu).

Some examples of things we only single-click: buttons, scrollbars, tabs, menus, dropdowns, text (for selection).

Single-click is everywhere. Everything that can be double-clicked can also be single-clicked. Single-click is the default. If a single-click only leads to an item beings selected, that's a pretty good hint to try double-click if you also wanted it to be opened.

(Incidentally, what do those who double-click everything do when they want to select a file? Do they just open it, close it again (leaving it selected) and accept that as normal?)

Re: Double-clicking on the Web

#77
post #74

Browsers do not provide immediate visual feedback on some things for which they should. When you click on a link which exits the page, something visual should happen immediately, long before the new page loads. The browser knows you're leaving. Dimming the page, or some other visual transition, would be a good start. That would make a clear distinction between page-exiting actions and ones which keep the page active.

There used to be much better feedback with the "throbber", i.e. the big animated Mosaic/Netscape/Mozilla logo. But that seems to have gone away with the decrease in size of the toolbar buttons.

Re: Double-clicking on the Web

#78
post #10

Are double click actions still a thing? Windows has had an option for single-click mode since forever, and most users I know use it – mainly because they're used to single click from the web. The remainder and most Mac/Linux users don't even bother and navigate with the keyboard. I can't remember the last time I had to double-click anything, except for text selection.

We single click links just like we single click buttons. Form buttons on a browser should behave like regular buttons in the operating system: single click. Clicking an item in a list should select the item. Double clicking an item in a list should open it. This is the part that might be broken in the web browser because I see check boxes and all sorts of other UI gymnastics to enable the functionality of how a list…

There's tag `label` made for connecting text and input elements. And any correct form should use labels and it'll work in any browser just as you described: click on text label will trigger input activation (toggle checkbox or focus text input).

Re: Double-clicking on the Web

#79
post #42

Earlier quoted context omitted.

Forms should probably have a one-time token generated when the form is rendered. This will also help prevent CSRF and DDOS via hogging of resources. In fact, the same technique should apply to session tokens in general. They should be signed by the server, which removes the need to do I/O to filter out unauthorized sessions and mitigate DDOS attacks. So yes, this is the correct way to do it. But additionally, I don't…

Signing is slow, if anything signing the CSRF tokens just became your bottleneck, if not you just inflated the request size by kilobytes for no good reason.

Signing doesn't require I/O and can be massively parallelized.

And also the CSRF token doesn't need signing, it comes from the session data stored on the server. The session id is what needs signing.

Re: Double-clicking on the Web

#80
post #29

Earlier quoted context omitted.

Forms should probably have a one-time token generated when the form is rendered. This will also help prevent CSRF and DDOS via hogging of resources. In fact, the same technique should apply to session tokens in general. They should be signed by the server, which removes the need to do I/O to filter out unauthorized sessions and mitigate DDOS attacks. So yes, this is the correct way to do it. But additionally, I don't…

So the DDoS attacker can't retrieve said tokens?

Well, presumably creating an account will be expensive, otherwise an attacker can just execute a http://en.wikipedia.org/wiki/Sybil_attack

Once an account is created, throttling resources is straightforward. If you want, you can allow a person to have one X per Y (time, points, whatever).

Post reply on HN