3 ms·
It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.
by vitiral 4y ago
It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.
- roflc0ptic 4y agoSure, 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
- tuyiown 4y agoAgain 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.
- Someone1234 4y agoIt 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.
- gausswho 4y agoMaybe 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?