Current LockScreenWindowManager and the old LockScreen manage the passpad directly. This increase the complication between sub-component and its parent. But things may not go well if we encapsulate it as a non-frame component and later we need to change it to use the real keyboard. So I prefer to make a LockScreenInputWindow that implement the interface of the near future InputWindow, so we can invoke real keyboard instead of the keypad and thus complete the encapsulation, while in the future we don't need to rewrite the whole keypad logic again, but replace the implementation of LockScreenInputWindow to inherit the real InputWindow.

After we implement the LockScreenInputWindow, we can evolute this with 3 steps: 1. LockScreenInputWindow + current keypad, not the real keyboard yet 2. LockScreenInputWindow + custom keyboard iframe, but not follow the real InputWindow flow 3. LockScreenInputWindow inherit the real InputWindow

The major risks: integration and Gaia UI tests.

Comment on attachment 8503874 [details] Patch Set feedback since the patch now works. Left: tests and possible architecture issues.

Update the patch with what you commented. So I set the review.

Comment on attachment 8503874 [details] Patch >https://github.com/mozilla-b2g/gaia/pull/24957

Comment on attachment 8503874 [details] Patch r=me

Gaia-Try is green: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=9f209ebe8e7a So I would land this patch. Hope In-Bound would keep good, too.

master: https://github.com/mozilla-b2g/gaia/commit/b62cf59505bfb7eb2076be856827dcaff527c549