In a desktop application, if a button stays in the pressed state when you let go of the mouse button, it means that the developer was lazy and is doing work on the UI thread. In a classic Windows UI, the transfer dialog would be closed, or it would disable all controls until the operation completes and then show a confirmation message.
Well, kind of.
Actually, the developer should really do some work in the UI thread beyond just sending out a "button pressed" message: When I press the button, I need immediate feedback that it was pressed and that pressing it had an effect, that things are now happening. Too many UIs, especially in the web where round-trip-times can be long, rely on just firing of a message or a network request. The response to the user, by displaying a spinner, progress bar, modal or new page only happens asynchronously and after a comparatively long delay. This means that users will sometimes repeatedly click because "nothing happens", leading to multiple messages, leading to multiple actions, leading to a big mess.
So the UI thread should synchronously trigger user feedback, take a lock or other measures to prevent unintended repeated actions and start a timeout callback in case the triggered action doesn't happen in a sensible timeframe.