** For V2 - Keyboard ** In V1, the built-in keyboard app. is mozBrowser/mozapp but not OOP. For 3rd-party keyboard app. support we will need to make it OOP for safety.

Rudy, will there be any performance impacts (negative or positive) as a result?

I suppose we may get performance improvement after we move Keyboard app OOP, though I am not sure about that. Besides, we may need someone to take a look at Bug 826152, which might also affect keyboard performance.

Josh, it depends on how we launch those keyboard apps. Per my implementation now, it takes 1-2 seconds to switch on a keyboard app that is first time launched. We may have some keyboard apps (and different layouts) in the phone, to prevent they run out all memory, we don't want to launch them when system is booting up, instead, we only do this if necessary (the user wants to switch on it). Once the keyboard app is launched, we won't destroy it except the process is killed by platform (OOM). So if the user wants it next time, it shows much quickly (as we have now). We could do some performance improvement of our built-in keyboard on many aspects, such as bug 826152 (rendering issue), or speeding up keyboard initialization ...etc. I think most of them are not related to keyboard app OOP. The only thing we need to improve here is switching keyboards smoothly.

Thanks Evelyn, that makes perfect sense, and I agree fully with your points. A bit of a delay when switching keyboards is fine in order to preserve memory, so long as we use an interstitial loading indicator while the loading is happening (if it's going to take longer than 1 second).

Do we know what the impact is in terms of memory usage and stability? How do we prevent the memory usage by the keyboard app to go through the roof and kill the app that triggered the keyboard itself to open?

(In reply to Fabrice Desré [:fabrice] from comment #5) > Do we know what the impact is in terms of memory usage and stability? We may use more memory as the keyboard is in its own process but we get better stability because **** keyboard won't crash the system app process. > How do we prevent the memory usage by the keyboard app to go through the > roof and kill the app that triggered the keyboard itself to open? I think the role=keyboard app should have lower priority than the foreground app that triggers it but higher priority than the rest of other apps. So we try to keep the keyboard open as hard as possible but don't let it kill the foreground app. This has not been implemented yet.

(In reply to Kan-Ru Chen [:kanru] from comment #6) > I think the role=keyboard app should have lower priority than the foreground > app that triggers it but higher priority than the rest of other apps. So we > try to keep the keyboard open as hard as possible but don't let it kill the > foreground app. This has not been implemented yet. I agree, and I don't think we should land OOP (and hence enable 3rd party support) without that.

Pointer to Github pull-request

Comment on attachment 803608 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12156 We can land this after Gecko patches have landed. Tim, Please help to review this one. Thanks.

Comment on attachment 803608 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12156 We shouldn't land any patches on a tracking bug so I will give you an f+ here. Please clone a bug and set your r+ there. Thanks.

tracker bug

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #10) > Comment on attachment 803608 [details] > Pointer to Github pull request: > https://github.com/mozilla-b2g/gaia/pull/12156 > > We shouldn't land any patches on a tracking bug so I will give you an f+ > here. Please clone a bug and set your r+ there. Thanks. Is there a specific bug to active it in Gaia?

Bug 928281 filed to track the Gaia change for activating keyboard app to run OOP. Thanks.

Comment on attachment 803608 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12156 Will send another patch with Bug 928281.

With bug 941885, keyboard apps are now oop'd in master branch, and remain disabled in v1.2 (along with 3rd-party keyboard support itself). Closing this tracking bug since this part of the work has completed.

We had to reopen this tracking bug because bug 941885 will not enable keyboard oop due to bug 941885 comment 15. Let's identify the cause and fix it.

This is the last bug affecting keyboard app OOM recovery.