CSRF and double posting

Here's something pedantic: JS and DOM aren't single-threaded, and the latter is not even a relevant term. Browser implementations may be single-threaded - that's a different thing.

Every major browser we have today paints the DOM in a single blocking thread. Sending a synchronous AJAX call blocks this thread. You literally cannot click another link on the page while a request is in progress. From a UX perspective this is a very poor design and that's the reason it's being removed from the spec. If a request takes 1-2s you've locked the entire page for that duration. That's not my idea of "how it works best" and they're removing it to stop people from using it this way.

Web workers are the only way to multi-thread JS and they don't have DOM access which is how they achieve this. Node is also single threaded but it's event loop is non blocking unless you use synchronous methods.

Obviously we don't see eye to eye on this subject. CSRF protection is only one security measure and you should implement multiple to protect yourself. I didn't mean to say CSRF is the only protection you need and you should disable settings willy nilly. It works best in tandem with others which is why I mentioned the iframe block. Apparently I've done a poor job of explaining myself so I'll duck out of this thread now.

Here's something pedantic: JS and DOM aren't single-threaded, and the latter is not even a relevant term. Browser implementations may be single-threaded - that's a different thing.

Every major browser we have today paints the DOM in a single blocking thread.

Yes, today's browser implementations do that.

But JavaScript itself is not single-threaded (otherwise you wouldn't have those workers) and the DOM is an interface. Interfaces don't have behavior; saying that an interface is single-threaded is a meaningless statement.

I'm being pedantic, that's obvious.

Sending a synchronous AJAX call blocks this thread. You literally cannot click another link on the page while a request is in progress.

And that's a good thing if you'd be changing DOM elements depending on the response.

From a UX perspective this is a very poor design and that's the reason it's being removed from the spec.

Yep, and from a technical perspective changing DOM elements when you don't need to is even poorer design.

You don't need to alter a form field if you're going to submit it via AJAX; you don't need that field to exist at all - store the token in a JS variable and update it when receiving responses.

If a request takes 1-2s you've locked the entire page for that duration. That's not my idea of "how it works best" and they're removing it to stop people from using it this way.

"How it works best" is subjective and depends on the use case.
They're trying to discourage bad practices, but this doesn't mean that the problem we're discussing isn't the result of asynchronicity.

Obviously we don't see eye to eye on this subject.

Indeed we don't, and that's fine in principle as long as we disagree on opinion-based matters, but that's not the case.
We're having this discussion because you give security advice with UX and "how hard is it to do" arguments, which is wrong.

CSRF protection is only one security measure and you should implement multiple to protect yourself. I didn't mean to say CSRF is the only protection you need and you should disable settings willy nilly. It works best in tandem with others which is why I mentioned the iframe block. Apparently I've done a poor job of explaining myself so I'll duck out of this thread now.

Unless you're doing another poor job of explaining yourself, it seems that your think CodeIgniter's CSRF protection is "CSRF protection" and X-Frame-Options is not.
They both are CSRF protection mechanisms, working on different principles. You don't need both for the same thing, you pick whichever suits you.

Looking at this I think it is a bug in Chrome. The other browsers simply don't "re-post" as long as no response has been sent from the server.

Maybe you could flag a CSRF token as sent in a session variable. When the second POST comes, check if the token has been flagged. If it has been flagged, don't process and continue to the intended destination.

As for hiding the button, CSS alone should work

Code:

input[type=submit]:active {
   display: none;
}