Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Description • 12 years ago

** 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.

	Josh Carpenter [:jcarpenter]
	Comment 1 • 12 years ago

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

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Comment 2 • 12 years ago

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.

	Evelyn Hung Assignee
	Comment 3 • 12 years ago

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.

	Josh Carpenter [:jcarpenter]
	Comment 4 • 11 years ago

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).

	[:fabrice] Fabrice Desré
	Comment 5 • 11 years ago

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?

	Kan-Ru Chen [:kanru] (UTC+9)
	Comment 6 • 11 years ago

(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.

	[:fabrice] Fabrice Desré
	Comment 7 • 11 years ago

(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.

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Comment 8 • 11 years ago

Pointer to Github pull-request

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Comment 9 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 10 • 11 years ago

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.

	Preeti Raghunath(:Preeti)
	Comment 11 • 11 years ago

tracker bug

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 12 • 11 years ago

(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?

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Comment 13 • 11 years ago

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

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Reporter
	Comment 14 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 15 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 16 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 17 • 11 years ago

This is the last bug affecting keyboard app OOM recovery.