4 ms·

> When the SIM PUK was reset successfully, a .dismiss() function was called by the PUK resetting component on the “security screen stack”, causing the device to

> When the SIM PUK was reset successfully, a .dismiss() function was called by the PUK resetting component on the “security screen stack”, causing the device to dismiss the current one and show the security screen that was “under” it in the stack Oh, the exceptional safety of object oriented programming!

lupire 4y ago
There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.
- 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 ago
    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
  - tuyiown 4y ago
    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.
  - Someone1234 4y ago
    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.
    - gausswho 4y ago
      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?

lupire 4y ago

There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.

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 ago
  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
- tuyiown 4y ago
  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.
- Someone1234 4y ago
  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.
  - gausswho 4y ago
    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?