> Why? How, even, have they implemented this?
This is really common because of two design features that most UI frameworks share:
- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)
- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.
> Sometimes this is used to intentionally give you a chance to cancel the action
EDIT: sometimes UI elements with mouse-held interaction allow you to use the escape key to cancel an in-progress interaction (ESC: abort, mouse-up: commit) however the reply button on this page doesn't work that way so I have to edit this message to add this. That escape-key behavior should be universal I think.
> there's no way for it to tell the button to cancel the color change
No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.