Closed Bug 816874 Opened 8 years ago Closed 7 years ago

Tracking: Run keyboard app OOP

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:-)

RESOLVED FIXED
blocking-b2g -

People

(Reporter: rudyl, Assigned: jj.evelyn)

References

Details

(Whiteboard: [ucid:SystemPlatform1], [FT:System-Platform], [Sprint: 2])

Attachments

(1 obsolete file)

** 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.
Summary: Keyboard app. OOP support → Tracking: Run keyboard app OOP
Rudy, will there be any performance impacts (negative or positive) as a result?
Flags: needinfo?(rlu)
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.
Flags: needinfo?(rlu)
OS: Mac OS X → Gonk (Firefox OS)
QA Contact: wachen → whsu
Hardware: x86 → ARM
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.
Assignee: nobody → ehung
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).
Depends on: 847763
Blocks: 891669
Depends on: 891763
blocking-b2g: --- → koi+
Whiteboard: [ucid:SystemPlatform1], [FT: System Platform], [Sprint: 2]
Priority: -- → P1
Whiteboard: [ucid:SystemPlatform1], [FT: System Platform], [Sprint: 2] → [ucid:SystemPlatform1], [FT:System-Platform], [Sprint: 2]
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.
Depends on: 914541
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.
Attachment #803608 - Flags: review?(timdream)
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.
Attachment #803608 - Flags: review?(timdream) → feedback+
No longer blocks: 891669
tracker bug
blocking-b2g: koi+ → -
(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?
Flags: needinfo?(timdream)
Depends on: 928270
Depends on: 928281
Bug 928281 filed to track the Gaia change for activating keyboard app to run OOP.
Thanks.
Flags: needinfo?(timdream)
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.
Attachment #803608 - Attachment is obsolete: true
Depends on: 941627
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Depends on: 944009
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is the last bug affecting keyboard app OOM recovery.
Depends on: 953044
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.