Closed
Bug 983012
Opened 10 years ago
Closed 10 years ago
[Sora][Message][Input method]The virtual keyboard is not working after switching the keyboard layouts several times.
Categories
(Firefox OS Graveyard :: Gaia::Keyboard, defect, P1)
Firefox OS Graveyard
Gaia::Keyboard
Tracking
(blocking-b2g:1.3+, b2g-v1.2 unaffected, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 verified, b2g-v2.0 fixed)
Tracking | Status | |
---|---|---|
b2g-v1.2 | --- | unaffected |
b2g-v1.3 | --- | fixed |
b2g-v1.3T | --- | fixed |
b2g-v1.4 | --- | verified |
b2g-v2.0 | --- | fixed |
People
(Reporter: sync-1, Assigned: rudyl)
References
Details
(Keywords: regression)
Attachments
(2 files)
Firefox OS v1.3 Mozilla build ID: 20140226004002 Regression: can not reproduce on buri 1.1. DEFECT DESCRIPTION: ->tap the virtual keyboard, it's disable. REPRODUCING PROCEDURES: ->Enter"Message"to create a message; ->Long tap global key to switch the input method as pinyin; ->Then tap the virtual keyboard, it's disable.(ko) It is easy to reproduce this behavior. Download the MS and power on, enter text edit interface, switch to "pinyin" input method. The keyboard is disable, it can not input any charactors. note:Buri 1.1 is ok. EXPECTED BEHAVIOUR: ->Should input normally ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:
Other input method also cause have PR, just continuous switch input method via long tap global key.
blocking-b2g: --- → 1.3?
Flags: needinfo?(vchen)
Comment 2•10 years ago
|
||
Can we confirm reproduction on Buri 1.3 not using Pinyin?
Keywords: qawanted
It can reproduce on 1.3 not using Pinyin: http://www.youtube.com/watch?v=TmBsy3yYHI4&feature=youtu.be As you can see, what I did was just kept changing the input method, and after changing about 6 or 7 times, the keypad cannot work anymore. Get no response when tap the virtual keypad Thanks Vance
Flags: needinfo?(vchen)
Keywords: qawanted
Updated•10 years ago
|
Keywords: regression
Updated•10 years ago
|
blocking-b2g: 1.3? → 1.3+
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Updated•10 years ago
|
QA Contact: mvaughan
Comment 4•10 years ago
|
||
This issue looks to have started on the 09/25/13 1.3 build. - Last Working - Device: Buri v1.3 MOZ RIL BuildID: 20130924040201 Gaia: a22ba4a3a9efd99f94adf9ece8a2b391d4df295b Gecko: 1fda74e33e06 Version: 27.0a1 Firmware Version: V1.2-device.cfg - First Broken - Device: Buri v1.3 MOZ RIL BuildID: 20130925174530 Gaia: 7e42b4d690049709c62e8783910f16ab20869f42 Gecko: fa0e6916f88c Version: 27.0a1 Firmware Version: V1.2-device.cfg *This looks to be a gaia issue* last working gaia/first broken gecko = NO REPRO Gaia: a22ba4a3a9efd99f94adf9ece8a2b391d4df295b Gecko: fa0e6916f88c first broken gaia/last working gecko = REPRO Gaia: 7e42b4d690049709c62e8783910f16ab20869f42 Gecko: 1fda74e33e06 Push log: https://github.com/mozilla-b2g/gaia/compare/a22ba4a3a9efd99f94adf9ece8a2b391d4df295b...7e42b4d690049709c62e8783910f16ab20869f42 NOTE: This possibly could be reproduced all the way back to the first 1.3 from 09/19/13. However it looks like in order to reproduce this issue, the cursor has to remain in, and maintain focus of, the text box that is being used to bring up the keyboard. This was broken until 9/25/13 when bug 911129 was fixed.
Comment 5•10 years ago
|
||
After I revert this patch for bug 911129, this issue can still be reproduced.
Hi Jason, per Comment#5, looks like we still need someone to further check this issue, mind pointing me to the owner of the general keyboard issues? Thanks Vance
Flags: needinfo?(jsmith)
Comment 7•10 years ago
|
||
Rudy would be a good person to ask.
Flags: needinfo?(jsmith) → needinfo?(rlu)
Assignee | ||
Comment 8•10 years ago
|
||
I could not reproduce this issue with v1.3 on buri. I did not enable pinyin layout for my test, could someone confirm if pinyin is necessary or not? -- Gaia 2ea2aab306bd1c941719160cdcb49ee9d755dc17 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/cf2042938526 BuildID 20140317164002 Version 28.0 ro.build.version.incremental=324 ro.build.date=Thu Dec 19 14:04:55 CST 2013
Flags: needinfo?(rlu)
Keywords: steps-wanted
(In reply to Rudy Lu [:rudyl] from comment #8) > I could not reproduce this issue with v1.3 on buri. > I did not enable pinyin layout for my test, could someone confirm if pinyin > is necessary or not? > > -- > Gaia 2ea2aab306bd1c941719160cdcb49ee9d755dc17 > Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/cf2042938526 > BuildID 20140317164002 > Version 28.0 > ro.build.version.incremental=324 > ro.build.date=Thu Dec 19 14:04:55 CST 2013 No Pinyin is not necessary to reproduce this issue, I get a video here, could you check the video first? I think that will give you a better idea regarding how to reproduce this one, if you still cannot reproduce it, please let me know and I can show you how to http://www.youtube.com/watch?v=TmBsy3yYHI4&feature=youtu.be Thanks Vance
Assignee | ||
Comment 11•10 years ago
|
||
Vance, I could not access that video via this link, http://www.youtube.com/watch?v=TmBsy3yYHI4&feature=youtu.be - It would say "The video is private." Could you please help check the permission of that video? Thanks.
Flags: needinfo?(vchen)
Sorry, my bad, please try again, it should be public available now
Flags: needinfo?(vchen)
Assignee | ||
Comment 13•10 years ago
|
||
Still could not reproduce after following similar steps shown in that video. My setup: 1. Only enable 3 layouts - English, Spanish, Portuguese. 2. Using message app's message field as well. If someone on this bug could reproduce this, please help comment on if the whole system is still working, like if pressing Home button can bring you to homescreen, etc. Vance, I'll try to sync up with you on this bug tomorrow.
Comment 14•10 years ago
|
||
(In reply to Rudy Lu [:rudyl] from comment #13) > If someone on this bug could reproduce this, please help comment on if the > whole system is still working, like if pressing Home button can bring you to > homescreen, etc. > Dear Rudy, When this issue happened, the system is still working. But the keyboard can not input any charactors in all apps.
(In reply to Rudy Lu [:rudyl] from comment #13) > Still could not reproduce after following similar steps shown in that video. > My setup: > 1. Only enable 3 layouts - English, Spanish, Portuguese. > 2. Using message app's message field as well. > > If someone on this bug could reproduce this, please help comment on if the > whole system is still working, like if pressing Home button can bring you to > homescreen, etc. > > Vance, > > I'll try to sync up with you on this bug tomorrow. Sure, I am in office now, just ping me if you want to sync up
Updated•10 years ago
|
Assignee: nobody → rlu
Assignee | ||
Comment 16•10 years ago
|
||
Still could not find an easy way to reproduce this on buri, so would like to call for help from QA. William, Do you recently test v1.3 keyboard? Did you see any issues when switching keyboard layouts with long press? Thanks.
Flags: needinfo?(whsu)
Keywords: steps-wanted
Comment 17•10 years ago
|
||
Good Job, Vance! :) ======================================================= Hi, Rudy, I also can reproduce this bug on V1.3 build (Buri Device) There had something wrong on Gecko while I reproduced it. ------------------------------------------------------- E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] E/GeckoConsole( 136): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 484}] -------------------------------------------------------- Does it relate to canvas because I saw a related discussion on stackoverflow. - http://stackoverflow.com/questions/8660867/firefox-throws-error-0x80004005-when-working-with-canvas * Build Information: - Gaia da50b2b62ed96993cf4df22e3d69c435b28506bd - Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/3c39d1e487d9 - BuildID 20140226004002 - Version 28.0 * Result: - Can be reproduce Thanks.
Flags: needinfo?(whsu)
Comment 18•10 years ago
|
||
So far there's three people that can reproduce this, which makes me think the STR is correct. I don't know why Rudy can't reproduce. At this point, I think you need to go talk to William or Vance directly this to find out why you can't reproduce.
Keywords: steps-wanted
Assignee | ||
Comment 19•10 years ago
|
||
When this issue occurs, we got isShowingAlternativesMenu set as true. https://github.com/mozilla-b2g/gaia/blob/808394920b64ee7f1bfc7bf84a1f2339e1eb1701/apps/keyboard/js/keyboard.js#L1081 So, keyboard app would ignore any new touch events. From the log, isShowingAlternativesMenu is set as true before movePress() was invoked after you switch to any keyboard layout. Will try to see how to avoid this.
Assignee | ||
Comment 20•10 years ago
|
||
The caused has been stated in the previous comment. This patch tries to remove event listeners for the touched keys after you switch the layouts. Tim, please help review this one. Thanks.
Attachment #8394042 -
Flags: review?(timdream)
Assignee | ||
Comment 21•10 years ago
|
||
Modify the summary since this has nothing to do with pinyin.
Summary: [Sora][Message][Input method]The virtual keyboard is disable after switching the keyboard as pinyin. → [Sora][Message][Input method]The virtual keyboard is not working after switching the keyboard layouts several times.
Comment 22•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 Can we test the patch?
Attachment #8394042 -
Flags: review?(timdream) → feedback+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #22) > Comment on attachment 8394042 [details] [review] > pull request 17374 > > Can we test the patch? I will test later and ask partner to verify as well
Patch verified OK by partner Thanks Vance
Assignee | ||
Comment 25•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 Tim, Could you help review again so that we can land this? Thank you.
Attachment #8394042 -
Flags: review?(timdream)
Updated•10 years ago
|
Attachment #8394042 -
Flags: review?(timdream)
Assignee | ||
Comment 26•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 Patch updated to add unit test and address review comments. Will send review after travis is green.
Assignee | ||
Comment 27•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 Patch upated for: - Add unit test, note that the test for jspinyin has been removed, since it may conflict with the newly added tests, and since it has been disabled anyway. Tim, please help review it again. Thanks.
Attachment #8394042 -
Flags: review?(timdream)
Comment 28•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 You should not remove JSPinyin tests since it's enabled by default for engineering build so we should be able to run them. Thank you for adding a test. I do not know we have no any test at first place. I think we should now concentrate the test script effort to the new keyboard instead.
Attachment #8394042 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 29•10 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #28) > Comment on attachment 8394042 [details] [review] > pull request 17374 > > You should not remove JSPinyin tests since it's enabled by default for > engineering build so we should be able to run them. > What I meant by "disabled" os for jspinyin tests themselves, please see https://github.com/mozilla-b2g/gaia/blob/f5132420bef0d4dc27dfcb32bb9c5df2ab80530a/apps/keyboard/test/unit/jspinyin_test.js#L9 Without removing them, the tests would conflict with the newly added tests. Could you confirm we can remove jspinyin tests for now? Thanks.
Flags: needinfo?(timdream)
Comment 30•10 years ago
|
||
Yes, the test is disabled on 1.3. But I don't understand why keeping the files in the tree can result conflict in any way ....?
Flags: needinfo?(timdream)
Assignee | ||
Comment 31•10 years ago
|
||
This is because jspinyin would still require some files which would define some global objects, like 'window.InputMethods' with this line, requireApp('keyboard/test/unit/setup_engine.js'); However, we defined this in keyboard.js, which would cause conflict because const could be defined more than once. const InputMethods = {}.
Assignee | ||
Comment 32•10 years ago
|
||
Landed to v1.3, https://github.com/mozilla-b2g/gaia/commit/b38047ff76a532cfd8300928b4d75e037aa03c00 Will have separate patches for v1.4 and master.
Comment 33•10 years ago
|
||
I don't see any v1.3 approval here? https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_3 Please get approval or revert ASAP. This policy change took effect over a month ago.
Assignee | ||
Comment 34•10 years ago
|
||
Sorry that I forgot to ask for approval first, patch reverted, https://github.com/mozilla-b2g/gaia/commit/b789780c53adaac199787f51615375f721edfef4
Assignee | ||
Comment 35•10 years ago
|
||
Comment on attachment 8394042 [details] [review] pull request 17374 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): N/A, might be a hidden bug for a long while. [User impact] if declined: The keyboard would be totally unusable if this occurs. [Testing completed]: Yes, manual tests and unit tests included. [Risk to taking this patch] (and alternatives if risky): Should be low, just remove the event listener when the keyboard is hidden or switched. [String changes made]: N/A.
Attachment #8394042 -
Flags: approval-gaia-v1.3?(fabrice)
Updated•10 years ago
|
Attachment #8394042 -
Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
Assignee | ||
Comment 36•10 years ago
|
||
Landed. Gaia master, https://github.com/mozilla-b2g/gaia/commit/77dab58bc492c26441132ee7641cfcda26f3ca90 v1.4, https://github.com/mozilla-b2g/gaia/commit/e849783b647035552e9bb289e8cb8b8ddfa22aaf v1.3, https://github.com/mozilla-b2g/gaia/commit/812838ad0fabf51fa14435af562ddac6d26fa936
Updated•10 years ago
|
Comment 37•10 years ago
|
||
Verified it. Thanks. * Build Information: - Gaia 4c3b2f57f4229c5f36f0d8fd399e65f4db88f104 - Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/3aaca223b673 - BuildID 20140330160202 - Version 30.0a2
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Flags: in-moztrap?
Comment 38•10 years ago
|
||
Thanks Robert! :) Added. - https://moztrap.mozilla.org/manage/case/12019/
Flags: in-moztrap? → in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•