The old Xt event sequences still linger on, keydown-activate-keyup and then forget whatever happen next, but I would really like a response stage. After you activate some function, that function should call back to whatever activated it, and either confirm or reject the activation. Most of the time this does not matter at all, you always confirm the action. In some cases though, especially when button toggling run in one process, and the action takes place in some other process, then it is not obvious whether some action is happening or it is rejected – or even if the second process is hung.

In some other project, a long time ago, we had an idea that you push a button to fire the action, and then you released the button but it did not fully pop out before it had a response to the action. It was a kind of tri-state button with an indeterminate or pending state. That did not solve the problem where a long-running process failed to comply, but that is a slightly different problem.

To make an example: In Scribuntos debug console it could be a [evaluate] button that is set in a pending state until the server replies with a final outcome, or even a multipart request where the server gives a reply when it has parsed the request but still has not finalized the reply.

Another way to implement this is as an insensitive state that only goes away after some kind of confirmation. The problem with this is that a lost confirmation would make the program hung. It is thus better to show a pending state that can be overridden, thus canceling the previous request.

This kind of tri-state button could be a nice addition to OOUI, but I don't know how obvious it would be. It is not something that is in common use as far as I know.

Perhaps it is more obvious to simply kill a weird-responding page and move on. Still I wonder whether it would be better to change the present fire-and-forget -model.

Feel free to flag as declined or invalid or whatever.