There is never a valid reason for any UI component to respond to touch or click events until it has been visible for at least 500ms.

Reminds me of the cases when I was typing some text on the physical keyboard (I believe it was Windows) and suddenly a dialog appeared and was immediately closed by one of my key presses.
I saw that it was some kind of a confirmation dialog and it left me wondering what the hell I did confirm or did cancel then.

So iOS definitely does it right and every dialog is disabled for the first fraction of a second after becoming visible.
I think mac does it as well bit not entirely sure.

It can be annoying sometimes when you are anticipating something appearing and just waiting for to click it immediately and it doesn’t work, but it’s definitely better than accidentally confirming something that just popped up randomly beneath your cursor or finger.

> 'Reminds me of the cases when I was typing some text on the physical keyboard (I believe it was Windows) and suddenly a dialog appeared and was immediately closed by one of my key presses.

I saw that it was some kind of a confirmation dialog and it left me wondering what the hell I did confirm or did cancel then.'

So very true. It's happened to me more times than I care to count.

I'd also say that, apart from being annoying, it's a security risk.

Just have better reaction times wtf

space tab space tab enter space tab space tab enter enter would like to argue

you never know... I had to do that shit a few times... there was some bug in a framework's reactivity that caused a custom, specialized component not to update its state so I had to do another check in a created() hook that took about 200ms to run.. Took them some 4 years to release a major version that fixed that bug, but the code is still there some 7 years later