998213 - [Tarako][Keyboard] Unable to input keys after doing some steps

Status: VERIFIED FIXED

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

Description

[Bingqing Li]

Attachment: STR-Video

Environment:
--------------------------------------------------
Gaia      f0872318d46781bb59d0a13a2e1fffb115b8ca2b
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/9ff031daa73c
BuildID   20140417164004
Version   28.1
ro.build.version.incremental=eng.cltbld.20140417.201933
ro.build.date=Thu Apr 17 20:19:40 EDT 2014


Steps to reproduce:
--------------------------------------------------
1. Launch Settings -> Display

2. Change wallpaper -> Select a picture from gallery
   --> It goes back to 'Display' page

3. Change wallpaper -> Select a picture from wallpaper
   --> It goes back to 'Display' page

4. Repeat step 2 and 3 for 3~5 times (maybe even more)

5. Press Home button (or sometimes setting is killed when changing wallpaper)
   --> Home screen is reloaded because it got killed.

6. Launch SMS -> Create a new message -> Focus on an input box

7. Tap on the keys after the keyboard shows up


Actual result:
-------------------------------------------
The pressed keys are not sent to the input box.
Pls refer to the STR-video attached.


Additional info:
------------------------------------------
The reproduce rate is about 1/6.
There are just four screenshots in gallery, no specific pictures there.

Comment 1

[Bingqing Li]

Attachment: logcat

Comment 2

[yang.zhao]

I found that when the issue occurs,the 'mozvisibilitychange' event hasn't been triggered,so 'setKeyboardName()' is not called ,and then in "oninputcontextchange' ,the keyboard pops up by calling "showKeyboard() " ,but the "inputMethod.activate" is null,so you'll see the log print as follows:

E/GeckoConsole( 5019): [JavaScript Error: "TypeError: inputText is undefined" {file: "app://keyboard.gaiamobile.org/js/imes/latin/latin.js" line: 429}]

Comment 3

[yang.zhao]

hi,Ian
   Could you find someone to have a look why the "mozvisibilitychange" event missed?Thank you!

Comment 4

[James Zhang (Spreadtrum)]

v1.3t+

Comment 5

[James Zhang (Spreadtrum)]

see http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=299702

Comment 6

[Steven Yang [:styang]]

Rudy, could you help on this issue? thanks!

Comment 7

[Steven Yang [:styang]]

Partner's blocker. 1.3T+

Comment 8

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Sure, I'll take a look.

Comment 9

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Patch V1 - pull request 18468

I think the root cause is as follows,
 1. The keyboard was re-launched after it is killed due to memorypressure.
 2. During keyboard init process, we would invoke setKeyboardName() but not showKeyboard. (because document.mozHidden or inputcontext not ready)
    - At this stage, setKeyboardName would trigger loading the layout and IM engine.
 3. And then inputcontextchange event came and we show the keyboard, but the IM engine was not ready yet => caused this issue.

This patch just removed #2, and only do setKeyboardName after visibilitychange and inputcontextchange event.

--
Tim, could you please help review this?
Thanks.

(Sorry that I did not add unit tests for this change as we don't have it for keyboard.js and I promise will get that addressed when we got time to refactor the old keyboard code base.)

Comment 10

[Keven Kuo [:kkuo]]

Since Rudy is working on this case.
Clear the needinfo request.

--
Keven

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8409344 [details] [review]
Patch V1 - pull request 18468

I don't agree with the fix. We should instead queue the user inputs until the engine is ready (is it possible?). 

By the way, I thought we are not going to use auto suggestion in 1.3t? Why do we need to load the engine?

Comment 12

[James Zhang (Spreadtrum)]

Can we fix this issue before 4.25 -- spreadtrum PTR2 test cycle.

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #11)
> Comment on attachment 8409344 [details] [review]
> Patch V1 - pull request 18468
> 
> I don't agree with the fix. We should instead queue the user inputs until
> the engine is ready (is it possible?). 
> 
> By the way, I thought we are not going to use auto suggestion in 1.3t? Why
> do we need to load the engine?

The engine is still needed for auto-punctuation and for capitalizing.
We still need to wait for the engine to be ready to determine the capitalization so that the UI will be shown with correct [Shift] key status.

I would suggest we keep this implementation because of the limited schedule, as pointed out by Comment 12.
Please let me know if you have any questions.
Thanks.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8409344 [details] [review]
Patch V1 - pull request 18468

This patch should be 1.3T only; please file another bug for impl on master.

Comment 15

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Landed to v1.3t branch only,
https://github.com/mozilla-b2g/gaia/commit/3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0

Tim, thanks.

Comment 16

[Mike Lien[:mlien]]

verified and fixed with today's daily build
Gaia      3771067de006633df690a590a97b4d28c44ef8b2
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/51a4e4d35e30
BuildID   20140423164005
Version   28.1