Is so important have people with that spark to see and fix those little UX issues, a good analogy used on UX design is papercuts for the user, not critical but it degrades user satisfaction.
To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.
One I've experienced on GitHub and Jira is dragging to select text on a dialog, if you release outside the dialog the mouse up event dismisses the pop up which is probably a side effect of being able to click outside the dialog to dismiss it.
That’s classic “web ui”, the consequence of lowering the absraction level without providing and forcing developers to use useful mechanisms. So everyone just goes mindlessly with events which are badly targeted by design.
I’d say that desktop is an order of magnitude better, but a kde installation I have to work with also doesn’t register clicks on buttons sometimes. Because for the sake of ui-ness they used flat elements instead of buttons and forgot making them down-upable anywhere within to click. So when you move-quick-and-click it registers (I guess) drag instead due to the movement, and drag is a no-op.
Allowing clueless developers to use lower level and normalizing lower level graphics is a huge mistake these platforms make. The web is basically built with this in mind, that’s why it sucks.
20 years ago you couldn’t even imagine clicking around in a desktop app to see if radio works. People would literally laugh at you.
This could probably be fixed by tracking whether the mousedown event was started inside or outside the dialog, and only close the dialog if the mousedown started outside it.
To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.