1063579 - Keyboard crashes upon first focus of any input

Status: RESOLVED DUPLICATE of bug 1059832

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

Description

[:Eli Perelman]

Attachment: 2014-09-05-10-23-58.png

When trying to use the Rocketbar search, the keyboard crashes upon trying to focus the input for the first time. Sometimes the keyboard will relaunch correctly, sometimes you need to re-focus the input, but after each reboot the crash message is displayed.

Nominating for 2.1 blocking as displaying keyboard crashing after every reboot and not having the keyboard working after focus is a usability problem.

Gaia 2ad4a6b1aa929d89f3f2fea1c6efb511b2227c0c
Gecko 3809a1cc806e1c3190e3550a1efc209ef98bf159

Comment 1

[Gregor Wagner [:gwagner]]

I would say this is a keyboard problem?

Comment 2

[:Eli Perelman]

That would be my guess, but I wasn't completely sure as I only saw this manifest on the Rocketbar search.

Comment 3

[:Eli Perelman]

I take that back, I was just able to crash the keyboard by trying to create a new contact in the Contacts app.

Comment 4

[Marcia Knous [:marcia]]

Eli: I have running the whole day on Flame using a slightly different build than you, but I haven't seen this bug:

Gaia   95e9b099aa89ded133e44014dd40b19dc0193c01
SourceStamp 92a6bbdfd945
BuildID 20140905000202
Version 34.0a2
base: v123

Are you running on User/Engineering or is this a build you built yourself?

Comment 5

[:Eli Perelman]

Built myself from the B2G repo:

./repo sync
./build.sh
./flash.sh

I believe Mason is also experiencing the same issue. Mason, can you confirm if you are still experiencing?

Comment 6

[Mason Chang [Inactive] [:mchang]]

Just did a repo sync.

Gecko: 203783:d934dc4a99ac
Gaia:  2991746d61bae865f6e0c0dfacda07ae3c2f2fbd

Interestingly, if I do a flash, I can reproduce this 100%. Only crashes reliably after a reboot. However, if I do a make reset-gaia, this doesn't happen at all.

Comment 7

[:Eli Perelman]

Interesting, I notice the same thing as Mason. The issue is manifested if I do a flash, but doing a make reset-gaia after the flash removes the crashing.

Comment 8

[Nicolas B. Pierron [:nbp] {away}]

This bug is blocking the harness used for checking JavaScript benchmarks on the phones.
Is anybody working on this bug?

Comment 9

[Nicolas B. Pierron [:nbp] {away}]

(In reply to Nicolas B. Pierron [:nbp] from comment #8)
> This bug is blocking the harness used for checking JavaScript benchmarks on
> the phones.

(In reply to Mason Chang [:mchang] from comment #6)
> Interestingly, if I do a flash, I can reproduce this 100%. Only crashes
> reliably after a reboot. However, if I do a make reset-gaia, this doesn't
> happen at all.

For the moment I disabled the fact that I rebooted the phone between 2 benchmarks, otherwise I constantly hit this issue with Marionette.  The harness is doing similar to:

$ adb wait-for-device
$ adb reboot
$ adb wait-for-device
$ adb root
$ sleep 10
$ adb forward tcp:2929 tcp:2828
$ gaiatest --address=127.0.0.1:2929 --device=… --testvars=… $B2G/gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/browser/test_browser_navigation.py

Comment 10

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 11

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

Is it possible to find the regression window? Is there anything that can be helpful in the log?

It's unlikely keyboard app can crash itself so I would list the likely InputMethod API / input mgmt bugs below. However most of them are not in v2.1:

m-c: https://github.com/mozilla/gecko-dev/commits/master/dom/inputmethod
gaia master: $ g log --oneline -- apps/system/js/keyboard_manager.js

55401db Bug 1059663 - Input Management script code cleanup
19a3c58 Bug 1048228 - Set the last used keyboard as default after restart of the phone
c02a731 Bug 1058382 - Reorganize |KeyboardManager. inputFocusChange()|
36e13d6 Bug 1054942 - Dissect |KeyboardManager.updateLayouts()|
3205968 Bug 1053624 - Extract and organize Input Management showAll()
7e46978 Merge pull request #23569 from alivedise/bugzilla/1061118/dismiss-keyboard-before-attention-window-opened
e6e25c7 Bug 942309 - [keyboard] keyboard layout language changes for input type=url and type=email
77cc40a Bug 1061118 - Dismiss keyboard on attention window requestopen or recovering
2a52b1d Merge pull request #23413 from mnjul/bug_1005752_keyboard_not_setLayoutFrameActive
a732457 Bug 1005752 - [Keyboard] Should not setLayoutFrameActive(false) if we don't need to
552e51a Bug 1059668 - Move some keyboard removal logics from keyboard_manager.js to input_frame_manager.js

Comment 12

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

Another recent change would be changing the way we work with audio tag in bug 1060879.

https://github.com/timdream/gaia/commits/master/apps/keyboard

Comment 13

[Jason Smith [:jsmith]]

As a reminder - A single QA keyword should be used to describe the immediate need. We do branch checks first before doing a window, so clearing the window request.

See https://groups.google.com/forum/#!topic/mozilla.dev.gaia/KbZYREhnprY which explained this.

Comment 14

[Chris Kreinbring [:CKreinbring]]

Unable to repro on the latest Flame 2.2 on both JB and KK.
Actual result: Tapping a textbox for the first time brings up the keyboard with no errors.

JellyBean
BuildID: 20140909070054
Gaia: 4abb193ddae0f9780ad12ffe5e31772feee3926a
Gecko: 4d1793da0b96
Platform Version: 35.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

KitKat
BuildID: 20140909065754
Gaia: 4abb193ddae0f9780ad12ffe5e31772feee3926a
Gecko: 2eaf94a4f837
Platform Version: 35.0a1
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Comment 15

[Nicolas B. Pierron [:nbp] {away}]

(In reply to Chris Kreinbring [:CKreinbring] from comment #14)
> Unable to repro on the latest Flame 2.2 on both JB and KK.
> Actual result: Tapping a textbox for the first time brings up the keyboard
> with no errors.

Did you follow what is described in comment 5?
AWFY FxOS slaves are still able to reproduce this issue on every build, with the snippet described in comment 9.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

The patch on bug 1059832 should fix this. (Thanks Mason for linking the two!)