This is something I created many, many years back for Stanford’s CS103 course as a lecture demo. Apologies for the lack of mobile support - I’ve always presented this from my laptop. :-)
I know this is nitpicky, and yes, I see that "fire!" is an accepting state, but maybe you could have a special transition from "fire!" to "hover" labelled "reset".
You've made a couple mistakes here.
1. You've made the unfounded leap that the diagram intends to represent state after the button has fired. That's manifestly incorrect.
2. You've made the incorrect assumption that a full reset of the diagram is accomplished by clicking the button. But that's not what it says. Obviously, you also need to move the mouse out of the button to return to the start state. So you could criticized this for incomplete instruction, however, since the context is a demo for a college course, omitting over-instruction of obvious and irrelevant details is most likely the best decision to reach the overall instructional goal.
If you want to be pedantic on the internet, you need to go a bit deeper than that. ;-)
Small suggestion for improvement: There are really two boolean variables (inside the button area, or not; mouse button down, or not). They give rise to more than 4 states because the order of actions is important.
But the diagram might be made more intuitive by placing the states within a 2x2 chess board corresponding to in/out, up/down. Not much change is necessary (for example: shift "held outside" left, "pressed" down, and "fire" up).
I added a `#button:active` style to see if it was actually leaving it activated after dismissing the context menu, but apparently no. Not sure what the cause is.
Still a crazy cool demo though. Having worked on ui for my hobby games, I always knew it was more complex than just onClick, but this makes me understand it perfectly. I'm probably going to implement a model based on this in my current project.