1093121 - Keyboard never shows

Status: RESOLVED DUPLICATE of bug 1092941

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

Description

[Ben Francis [:benfrancis]]

STR:
* Shallow flash today's nightly build of Gecko + Gaia on top of v184 base image https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk-eng/
* Launch an app with a text field
* Focus the text field

Expected:
* Keyboard appears

Actual:
* Keyboard doesn't appear

Comment 1

[Gabriela [:gaby2300]]

I cannot reproduce this using base image v188, FFOS 2.2 and the latest OTA update.

Comment 2

[Ben Francis [:benfrancis]]

Correction, I am reproducing using v188 base image (not v184). I can also reproduce with current master of Gaia flashed with "make reset-gaia".

The keyboard shows when trying to enter a WiFi password during FTU after "make reset-gaia", but then fails to show for the Rocketbar once the FTU is complete.

After rebooting the device, the keyboard starts to work again.

When the keyboard is not working it looks as though it tries to show but gets stuck with transition-state=closed

Comment 3

[Michael Henretty [:mikehenrty][:mhenretty]]

I noticed this when flashing master gecko-gaia on 188 base image. The keyboard didn't show up in the FTU on the sim pin step, but started showing up after FTU (for instance, in the search app).

Comment 4

[Gregor Wagner [:gwagner]]

This basically means the phone is not usable. Tony, can we get some help here?

Comment 5

[Tony Chung [:tchung]]

marking qawanted to get some attention.   We did have automation failures on 2.2 today as well, due to no keyboard

Qawanted, please try 2.2 with both full and shallow flash to see if there's a difference.

Comment 6

[Tony Chung [:tchung]]

By the way, the 2.2 report for today that was sent out did not indicate this was reproduced when doing a full flash of 2.2 over v188.   Given the STR above is around shallow flashing and make-reseting of gaia, more investigation is needed to narrow this down.

Comment 7

[Martin Shuman [:Marty]]

I was able to reproduce this issue once with a Full Flash on today's Flame 2.2 build.

After full flashing, I progressed through the FTU, was able to successfully input my SIM PIN with a number keypad, and successfully input a WiFi password with a full keyboard.  Once I was at the Homescreen, I tapped the Rocketbar and was able to type 'google.com' with the full keyboard; however, once I hit enter, the keyboard disappeared, and I was stuck at the Rocketbar view with no search results.  I do not believe I was given a geolocation permission prompt at Rocketbar.  I was unable to access the keyboard at all after this point, trying in Rocketbar, Settings, and Browser.  Restarting the phone resolved this issue, allowing me to access the keyboard again.

Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141103040202 (Full Flash)
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 5999e92e89ff
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 8

[Peter Bylenga [:PBylenga]]

Smoke team saw this approximately 2/30 times on user master nightly. Automation reported earlier that this would be fixed by:
https://github.com/mozilla-b2g/gaia/commit/82c3899a7fd73cb3d7c406696c67f12ed461547c

Comment 9

[Tony Chung [:tchung]]

Hey guys, is this a regression from https://bugzilla.mozilla.org/show_bug.cgi?id=998106?

Comment 10

[Oliver Nelson [:oliverthor]]

While attempting to repro the issue, it seems that shallow flashing seems to be a major culprit:

Full flashing Nightly:                2/30
Shallow flashing Nightly:             3/3 
Full flashing Engineering Nightly:    3/3
Shallow flashing Engineering Nightly: 3/3 

It is worth noting that upon restarting an affected phone, the issue resolves itself.

Comment 11

[John Lu [:mnjul][Please NI or I'll miss]]

Hi there,

We did a huge input management refactoring on the commit said in comment 8 which may (or may not) have inadvertently fixed the bug.

I tend to say it has not fixed the bug according to what Ben said in comment 2. [1]

While we wait for further QA input, I'd like to confirm with Ben about
1) what flags you have used during reset-gaia (anything, including "the usual ones" such as DEVICE_DEBUG)
2) what language you first chose in FTU
3) whether your SIM has SIM PIN or not

These answers could help me a lot. Very much appreciated :)

[1] (p.s. the latest built version at comment 0's time and the commit hash on comment 7 did not include my commit, but comment 2's "transition-closed" indicated that the version Ben used in comment 2 included it)

Comment 12

[Ben Francis [:benfrancis]]

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #11) 
> 1) what flags you have used during reset-gaia (anything, including "the
> usual ones" such as DEVICE_DEBUG)

Just DEVICE_DEBUG

> 2) what language you first chose in FTU

The default, English (US)

> 3) whether your SIM has SIM PIN or not

Nope

Comment 13

[Peter Bylenga [:PBylenga]]

Let's get a regression window to find the commit that caused the regression.  Also the original issue is a smoketest blocker even though it looks like we have a commit that is masking results and lowering reproduction rate.

Comment 14

[Gabriela [:gaby2300]]

I hit this bug for the first time today using base image v188, FFOS 2.2 and the latest OTA update.

I was writing a SMS. I left the phone for a few minutes. When I returned to finish writing the message, I had to unlock the phone and I found the keyboard was missing. I closed the app and opened it again but still no keyboard. The only way I could finish writing the message was restarting the phone. Then the keyboard showed up as usual.

Comment 15

[Chris Kreinbring [:CKreinbring]]

Regression window
Last working
BuildID: 20141103040034
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 5999e92e89ff
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken
BuildID: 20141103131914
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 9b03757d6c99
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Working Gaia / Broken Gecko = Repro
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 9b03757d6c99
Broken Gaia / Working Gecko = No repro
Gecko: 5999e92e89ff
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5999e92e89ff&tochange=9b03757d6c99


Mozilla Inbound
Last working
BuildID: 20141103092837
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: ccaeff47aa20
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken
BuildID: 20141103094737
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 2ab425b4c278
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Working Gaia / Broken Gecko = Repro
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 2ab425b4c278
Broken Gaia / Working Gecko = No repro
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: ccaeff47aa20
Gecko pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ccaeff47aa20&tochange=2ab425b4c278

Comment 16

[Joshua Mitchell (Inactive)]

We are currently investigating these results (the regression-window) on our end - it looks like this might be a double-window - will update when we have something to report.

Comment 17

[John Lu [:mnjul][Please NI or I'll miss]]

Folks,

Unfortunately I (still) cannot reproduce the bug with STRs of comment 0 and comment 14, with latest Gecko/Gaia:
Gecko (from PVT, engineer build): https://hg.mozilla.org/mozilla-central/rev/9c51ab5be6bb, BuildID=20141104160201
Gaia (flashed by reset-gaia): 726c83231f74d7145d66f25af4b97908a0d8ad6f
This is on Flame-KK v188.

However, I do occasionally encounter bug 1092608 during FTU (for Wifi password, and for SIM PIN), which I believe is s separate issue.

Comment 18

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

I just reproduced this once on Flame v188 + latest master.

It will go into the following function and try to show the keyboard.
StateManager.prototype._updateActiveState()

However, we have a promise queue for each task needed to start the keyboard, but none of them is run when this issue is reproduced.
Guess the promise queue is broken by a previously rejected promise.

Comment 20

[Chris Kreinbring [:CKreinbring]]

Regression window
Last working
BuildID: 20141029054810
Gaia: a9a847920b51b79c4ad4ad339f0a005777a6228c
Gecko: c6989e473f97
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken
BuildID: 20141029131614
Gaia: 0dfc1996eb583c8b507a82bf6b8319624bba23ea
Gecko: 8345ae427a3f
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Working Gaia / Broken Gecko = Repro
Gaia: a9a847920b51b79c4ad4ad339f0a005777a6228c
Gecko: 8345ae427a3f
Broken Gaia / Working Gecko = No repro
Gaia: 0dfc1996eb583c8b507a82bf6b8319624bba23ea
Gecko: c6989e473f97
Gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6989e473f97&tochange=8345ae427a3f


B2G Inbound
Last working
BuildID: 20141029073813
Gaia: 30e37915865af8eb8164a50e7512e68f40967961
Gecko: 817df6f416b3
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken
BuildID: 20141029091112
Gaia: 30e37915865af8eb8164a50e7512e68f40967961
Gecko: f5b374bb59ab
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Working Gaia / Broken Gecko = Repro
Gaia: 30e37915865af8eb8164a50e7512e68f40967961
Gecko: f5b374bb59ab
Broken Gaia / Working Gecko = No repro
Gaia: 30e37915865af8eb8164a50e7512e68f40967961
Gecko: 817df6f416b3
Gecko pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=817df6f416b3&tochange=f5b374bb59ab

Comment 21

[Joshua Mitchell (Inactive)]

Broken by Bug 1082001 - can you take a look Andre

Comment 22

[:gerard-majax]

That's strange, I have been dogfooding since for a while and not experiencing any issue. Besides, regression windows in comment 20 and in comment 15 do not match.

Comment 23

[:gerard-majax]

Given people are reproducing in keyboard, which lives likes an app, maybe this is going to be fixed by bug 1092941 ?

Would you mind taking the patch from bug 1092941 and give it a try ? If it does not help, please enable DEBUG in all js/jsm files in dom/settings, and capture logcat from the very early bootup phases.

Comment 24

[:gerard-majax]

Could it also be related to bug 1089405 ?

Comment 25

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Yes, this regression window makes sense to me, as I suspect one of our settings writing action broke our promise sequence.

I'll try to reproduce this issue first and then test that patch.
Thanks for Arthur and Edgar's help, I'll try to reproduce by the following steps:
 1. Use settings app to change themes for many times, repeatedly.
 2. Kill settings app.
 3. Try to launch keyboard.

Comment 26

[:gerard-majax]

Rudy, since you work on this, maybe you could assign, yourself :). In the meantime, if you succeed to reproduce do not hesitate to enable the dom/settings/ logging, in case you cannot find anything wrong on your side. But according to your comment, I get that my code may just be exposing your issue.

If it turns out it's a gecko-side bug, having as much as STR and logging would be very helpful :)

Comment 27

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Yeah, thanks for the advice.

With the patch in bug 1092941, this issue is gone.
But I agree with you that we should fix the issue at keyboard side, so that it won't be blocked by settings access failure.

Comment 28

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Patch V1

This is patch for keyboard app side, now it will start (create) a new queue when queue.run() is invoked, so that it won't be blocked by the previous never-resolve promise queue.

Tim, could you please review if this is a proper fix?
Thanks.

Comment 29

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

Comment on attachment 8518093 [details] [review]
Patch V1

The purpose of the queue itself *is* to make sure task are queued. Please identify what not resolving instead of breaking the queue.

Comment 30

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

It seems that we have already find the root cause.

(In reply to Rudy Lu [:rudyl] from comment #27)
> Yeah, thanks for the advice.
> 
> With the patch in bug 1092941, this issue is gone.
> But I agree with you that we should fix the issue at keyboard side, so that
> it won't be blocked by settings access failure.

IMHO we should not be trying to workaround this in keyboard app. However, if you think we should workaround on the keyboard side for the misbehaving API, let's add a timeout protection in SettingsPromiseManager instead? The code is ugly but shouldn't be that ugly with promise interfaces.

Comment 31

[:gerard-majax]

(In reply to Rudy Lu [:rudyl] from comment #27)
> Yeah, thanks for the advice.
> 
> With the patch in bug 1092941, this issue is gone.
> But I agree with you that we should fix the issue at keyboard side, so that
> it won't be blocked by settings access failure.

I would be following Tim, we should not workaround API issues, especially when we have a patch for this ..

Comment 32

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #30)
> It seems that we have already find the root cause.
> 
> (In reply to Rudy Lu [:rudyl] from comment #27)
> > Yeah, thanks for the advice.
> > 
> > With the patch in bug 1092941, this issue is gone.
> > But I agree with you that we should fix the issue at keyboard side, so that
> > it won't be blocked by settings access failure.
> 
> IMHO we should not be trying to workaround this in keyboard app. However, if
> you think we should workaround on the keyboard side for the misbehaving API,
> let's add a timeout protection in SettingsPromiseManager instead? The code
> is ugly but shouldn't be that ugly with promise interfaces.

Totally agree that a workaround in keyboard app side is not necessary.
My intention is to make the keyboard startup won't be blocked by a failed setting access in the previous queue, even when that won't occur if the settings API work correctly, since that settings access is not a critical part in keyboard start up.

I did not add timeout to SettingsPromiseManager, because it is still possible for any task in the queue to fail like settings, for example, getText() never resolve or something.

--
If the workaround here is not necessary, guess we could dupe this to bug 1092941.