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. :-)
Woah. This is what I find seriously cool about HN. Was searching around for "push button+state machine" the other day to learn how to program some menus with a microcontroller, and came across this. It's a really neat visualization, thanks for your work years ago!
There appears to be a mistake in the automaton diagram (not operation). The start state is "Idle, Up", and assumes the mouse is presently outside the button. But after doing "Click to Reset", you're already inside the button and so cannot enter it. Thus you should actually, and unfortunately, be in "Idle, Up". The demonstration gets around this by magically jumping to "hover", but this violates the whole educational point of what a start state is.
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".
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. ;-)
Just think of it as throwing the old button away and buying a new one. Buttons come idle from the factory. Once the old button is hauled away and the new one is installed under where your cursor happens to be, it transitions to hover.
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).
No repro here (Chrome 99 on Windows): right-clicking the button works the same as left-clicking it (yes, there's my browser's context-menu, but it doesn't seem to interfere with the webpage's logic at my end).
On Chrome on Mac I get the same, and right clicking outside the button makes it stick in the (idle, down) state, hovering makes it move between (hover, pressed) and (idle, down).
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.
I can make it do this on Firefox on Ubuntu; the key is to hit Escape to dismiss the context menu, instead of clicking away. Closing it by clicking away makes it act correctly.
Not sure why it seems MacOS related, but same thing here on mac (safari and firefox).
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.
