[LockScreen] Let the three-dots trick works again after Bug 1079706 landed

NEW
Unassigned

Status

Firefox OS
Gaia::System::Lockscreen
3 years ago
a year ago

People

(Reporter: snowmantw, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Since the old trick used in Bug 1069879 failed to work on the new LockScreenInputWindow, we need to let it re-work again.
(Reporter)

Updated

3 years ago
Assignee: nobody → gweng
(Reporter)

Updated

3 years ago
Blocks: 1069879
(Reporter)

Comment 1

3 years ago
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.
(Reporter)

Comment 2

3 years ago
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.
Flags: needinfo?(timdream)
(Reporter)

Comment 3

3 years ago
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
Attachment #8515743 - Flags: feedback?(timdream)
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.
Flags: needinfo?(timdream)
Attachment #8515743 - Flags: feedback?(timdream)
Duplicate of this bug: 1102002
(Reporter)

Updated

3 years ago
Depends on: 1101418
(Reporter)

Comment 6

3 years ago
Bug 1101418 would provide what we want.
(Reporter)

Updated

2 years ago
Assignee: gweng → nobody
You need to log in before you can comment on or make changes to this bug.