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)
Tracking
(blocking-b2g:1.3T+, b2g-v1.3T fixed)
People
(Reporter: bli, Assigned: rudyl)
References
Details
(Whiteboard: [sprd299702][tarako_only] [partner-blocker])
Attachments
(3 files)
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.
Reporter | ||
Updated•11 years ago
|
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → Other
Reporter | ||
Comment 1•11 years ago
|
||
Updated•11 years ago
|
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)
Comment 4•11 years ago
|
||
v1.3t+
Flags: needinfo?(ttsai)
Flags: needinfo?(styang)
Flags: needinfo?(kkuo)
Comment 5•11 years ago
|
||
Comment 6•11 years ago
|
||
Rudy, could you help on this issue? thanks!
Flags: needinfo?(styang) → needinfo?(rlu)
Assignee | ||
Comment 8•11 years ago
|
||
Sure, I'll take a look.
Assignee: nobody → rlu
Flags: needinfo?(rlu)
Flags: needinfo?(iliu)
Assignee | ||
Updated•11 years ago
|
Status: NEW → ASSIGNED
Updated•11 years ago
|
Whiteboard: [sprd299702]
Assignee | ||
Comment 9•11 years ago
|
||
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)
Comment 10•11 years ago
|
||
Since Rudy is working on this case.
Clear the needinfo request.
--
Keven
Flags: needinfo?(kkuo)
Comment 11•11 years ago
|
||
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)
Comment 12•11 years ago
|
||
Can we fix this issue before 4.25 -- spreadtrum PTR2 test cycle.
Assignee | ||
Comment 13•11 years ago
|
||
(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 14•11 years ago
|
||
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)
Updated•11 years ago
|
Whiteboard: [sprd299702] → [sprd299702][tarako_only]
Assignee | ||
Comment 15•11 years ago
|
||
Landed to v1.3t branch only,
https://github.com/mozilla-b2g/gaia/commit/3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0
Tim, thanks.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Whiteboard: [sprd299702][tarako_only] → [sprd299702][tarako_only] [partner-blocker]
Updated•11 years ago
|
Flags: needinfo?(ttsai)
Comment 16•11 years ago
|
||
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.
Description
•