Closed Bug 998213 Opened 5 years ago Closed 5 years ago

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

Categories

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

Other
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T fixed)

VERIFIED FIXED
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed

People

(Reporter: bli, Assigned: rudyl)

References

Details

(Whiteboard: [sprd299702][tarako_only] [partner-blocker])

Attachments

(3 files)

Attached video 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.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → Other
Attached file logcat
blocking-b2g: --- → 1.3T?
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}]
hi,Ian
   Could you find someone to have a look why the "mozvisibilitychange" event missed?Thank you!
Flags: needinfo?(iliu)
v1.3t+
Flags: needinfo?(ttsai)
Flags: needinfo?(styang)
Flags: needinfo?(kkuo)
Rudy, could you help on this issue? thanks!
Flags: needinfo?(styang) → needinfo?(rlu)
Partner's blocker. 1.3T+
blocking-b2g: 1.3T? → 1.3T+
Sure, I'll take a look.
Assignee: nobody → rlu
Flags: needinfo?(rlu)
Flags: needinfo?(iliu)
Status: NEW → ASSIGNED
Whiteboard: [sprd299702]
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.)
Attachment #8409344 - Flags: review?(timdream)
Since Rudy is working on this case.
Clear the needinfo request.

--
Keven
Flags: needinfo?(kkuo)
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?
Attachment #8409344 - Flags: review?(timdream)
Can we fix this issue before 4.25 -- spreadtrum PTR2 test cycle.
(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.
Flags: needinfo?(timdream)
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.
Attachment #8409344 - Flags: review+
Flags: needinfo?(timdream)
Whiteboard: [sprd299702] → [sprd299702][tarako_only]
Landed to v1.3t branch only,
https://github.com/mozilla-b2g/gaia/commit/3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0

Tim, thanks.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
See Also: → 998900
Whiteboard: [sprd299702][tarako_only] → [sprd299702][tarako_only] [partner-blocker]
Flags: needinfo?(ttsai)
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.