It has nothing to do with OOP. The design we're talking about is blind firing events at the in-focus window, and the in-focus window is being changed unexpectedly. The problem is loose coupling between the parent<->child. If the child window (PUK entry/pin reset window) knew the parent's ID and fired the dismiss event at that ID this wouldn't be possible.
Even the fix they implemented is poor: The child is STILL blind-firing a dismiss event, but they just told the lock screen to ignore dismiss events from the PUK entry window. Instead, the fix should have been to stop blind-firing events at whatever happens to be in-focus. They've added more complexity rather than fixing the poor design.
Maybe I'm misunderstanding what you refer to as blind-firing, but the change is to require a target ID from dismiss calls. That's regardless of focus then right?
Sure, but it’s a race condition that could happen in a functional language, too. FP has an analogue to a class called ADTs, and you could have the same bug using those
Again not really, somewhere, something send a signals, and outcome of that signal depends on UI state.
The problem is a lack of qualified signals and validated state changes, whatever the programming model used, if the logic is «remove topmost screen without any context check», you'll end up with this issue.
