Since the old trick used in Bug 1069879 failed to work on the new LockScreenInputWindow, we need to let it re-work again.
And since this bug is only for master, I think we can land the real solution rather than workaround, to resolve the animation managements issues at least for this symptom.
Tim: The root cause of this bug is we created LockScreenInputWindow to encapsulate the keypad and in the future, it would migrate to InputWindow and using real keyboard as the input pad, so the animation control now is managed by app-transition-controller, thus we can't control it in our states anymore. To solve this bug, I think the major issue is: while we try to manage panel switching with states, the animation 'delaying' in this case is actually a state that shows the fulfilled passcode. This means, in the 'passcode-fulfilled state' to apply the transition-delay on the target window, would make us no way to restore it, since another state may not know there is the delay on the target window, which is set by the previous or even previous previous state. Of course we can do some nasty things to make this restoring happen (every potential states after the 'passcode-fulfilled state' should try restore it, although they never know why this is necessary), but I think to delay a specific time during the 'show fulfilled passcode' state is more reasonable, although this leads to another issue is you hate to setTimeout in our codebase. Another possible solution is to modify the app-transtion-controller, to let the animation the keypad (now is LockScreenInputWindow) use a special animation with the delay while it's unlocking. But I think this is an overkill, since it creates a new animation just for the delaying time. However, maybe this is the only reasonable way to solve this bug, if we insist the delaying is just a delaying, not another state for showing the fulfilled passcode. And for patching this bug, I would show the setTimeout + 'keypadShowFulfilledPasscode' state version, and maybe we can discuss the proper approach later.
Created attachment 8515743 [details] [review] WIP Patch Tim: Please take a look of this WIP patch, to see if the approach is OK to you. The patch: 1. Create a new state to show the passcode, rather than to treat it as a 'delay time' only 2. Remove the code caused too early to clean the passcode dots in LockScreenInputPad, and delegate the cleaning timing to the states
Comment on attachment 8515743 [details] [review] WIP Patch Per offline discussion, let's do some planning making the state machine more leaner and decided where to put this bug on that roadmap.
Bug 1101418 would provide what we want.