Closed Bug 998213 Opened 11 years ago Closed 11 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
normal

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]
Status: ASSIGNED → RESOLVED
Closed: 11 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.

Attachment

General

Creator:
Created:
Updated:
Size: