963584 - Keyboard sometimes does not show on (Keon, Inari, Desire Z)

Status: RESOLVED DUPLICATE of bug 968957

(Firefox OS Graveyard :: Vendcom, defect)

Description

[:gerard-majax]

After bug 959198 got fixed, I've updated my tree (gecko: 88ae3cbcd8893bb56174edb37046d3ed1943c483; gaia: cc10bd5) and when I enable APZC for contents, restart the device, keyboard never appears.

This is 100% reproductible on HTC Desire Z, even after reset-gaia, default locale.

Comment 1

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

Attachment: Additional info from IRC chat

Comment 2

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

(Btw since this is not an officially supported device we probably won't spend much time, if any, on this bug. But if there are people who are interested in helping debug this issue I can provide assistance)

Comment 3

[:gerard-majax]

Strangely, Nexus S is fine and Inari too.

Comment 4

[:gerard-majax]

Killing the keyboard app, it works again.

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I can reproduce it 100% on a keon with/without APZC so it's not clear to me that it is related.

Comment 6

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

Moving component based on comment 5

Comment 7

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

I cannot reproduce this issue on buri,
aia      6586d2b8b43c6997be5cf5895bbdf3dd20490725
Gecko     http://hg.mozilla.org/mozilla-central/rev/ba31f271fbd0
BuildID   20140127160545
Version   29.0a1

And I don't think this is a keyboard app issue if it is device-dependent.

Comment 8

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

Oh, I found I reproduced this once on buri with the same gecko above and reflashed the latest gaia on it.
However, it seems intermittent.

Comment 9

[:gerard-majax]

(In reply to Rudy Lu [:rudyl] from comment #8)
> Oh, I found I reproduced this once on buri with the same gecko above and
> reflashed the latest gaia on it.
> However, it seems intermittent.

It's clearly not intermittent in my case. 100% reproductibility.

Comment 10

[Anthony Ricaud (:rik)]

I just reproduced this on a fresh Buri with an engineering build.

Gecko: 20140128040224
Gaia: 0783aa5a417e404f5d2034f236137a1582580c7f

Comment 11

[Botond Ballo [:botond]]

I just saw this on Nexus 4. Interestingly, it didn't happen immediately after I pulled anything, but rather immediately after I did 'reset-gaia'.

Killing the keyboard app fixed it for me as well.

Comment 12

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #11)
> I just saw this on Nexus 4. Interestingly, it didn't happen immediately
> after I pulled anything, but rather immediately after I did 'reset-gaia'.
> 
> Killing the keyboard app fixed it for me as well.

And I have not had the problem since. Maybe 'reset-gaia' does something that triggers the problem?

Comment 13

[:gerard-majax]

And now I trigger this also on Inari, after doing some reset-gaia.

Comment 14

[Julien Wajsberg [:julienw]]

And on Peak.

Not intermittent, happens 100% after a reboot.

Comment 15

[Julien Wajsberg [:julienw]]

I did some tries with/without APZC, and actually, _rebooting_ with a disabled APZC make this bug disappear while _rebooting_ with enabled APZC make this bug happen.

Comment 16

[Julien Wajsberg [:julienw]]

Just got something weirder that I saw also some days ago: after a reboot, I get a keyboard, but it's displayed very weirdly (like wrong resize operations, a too big black suggestion area). And it works fine once I kill the keyboard app.

I'll attach a screenshot of this.

Comment 17

[Julien Wajsberg [:julienw]]

Attachment: 2014-01-29-13-50-52.png

You see that the keyboard overlaps the Messages app's composer area.

Comment 18

[Julien Wajsberg [:julienw]]

So, looks like it's an APZC issue after all ;)

Comment 19

[David Flanagan [:djf]]

Can AZPC set a viewport and somehow affect the nubmers returned by window.innerWidth or document.documentElement.clientWidth?

Those can affect the definition of 1rem and affect the height of the keyboard, so could possibly explain the weird screenshot attached above.

Comment 20

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

Turning on APZC does trigger a different code path with respect to setting the CSS viewport (which affects window.innerWidth), so yeah it could be returning different values there. However in all cases that I'm aware of the new value is "correct" whereas the old value might have been incorrect. If you can check to see what the value is in the app with and without APZC it might help narrow this down.

Comment 21

[Julien Wajsberg [:julienw]]

QAWanted: can we check whether that reproduces in 1.3 and 1.4 on a Buri?

Here is the STR:
* boot the phone
* launch the SMS app
* press the "new message" button
* tap the composer

Expected:
* the keyboard shows up and Messages' window is correctly resized

Actual:
* either the keyboard is not shown, or it overlaps some part of the app's window (see 8368080)

Thanks!

Comment 22

[:gerard-majax]

With APZC enabled, 100% reproductibility on Inari running master with SIM PIN enabled. Disabling APZC circumvent the issue.

Comment 23

[Julien Wajsberg [:julienw]]

Just want to mention that the keyboard issue might or might not be related to bug 964216 where another fix landed today.

Comment 24

[Peter Bylenga [:PBylenga]]

Attachment: Composer_Keyboard_Graphical_Issue.png

I was able to reproduce the results shown in new attachment using the steps found in Comment 21 on the latest nightly Buri v1.4.

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140130040201
Gaia: 0bc0e703df197d46dfffb9ac65cb85d2e3e10c4a
Gecko: bf49e4428906
Version: 29.0a1
Firmware Version: v1.2-device.cfg


I could not reproduce the results seen in attachment 8368080 [details] using the steps found in Comment 21 on latest nightly Buri v1.3.

v1.3 Environmental Variables:
Device: Buri v1.3 MOZ
BuildID: 20140131004001
Gaia: 0ddcd8da5bfe1b48c73502ef29220e92f2db6b73
Gecko: 32e45047b663
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Comment 25

[Peter Bylenga [:PBylenga]]

See also Bug 963601, I ran into it after serving this qawanted and the distortions seem to be of equivalent size.

Comment 26

[:gerard-majax]

Keyboard app does not even run now:
$ adb shell b2g-ps
APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      77    1     188500 96332 ffffffff 00000000 S /system/b2g/b2g
Usage            app_173   173   77    67732  26672 ffffffff 00000000 S /system/b2g/plugin-container
Homescreen       app_190   190   77    77388  35980 ffffffff 00000000 S /system/b2g/plugin-container
Calendar         app_204   204   77    77704  31628 ffffffff 00000000 S /system/b2g/plugin-container
(Preallocated a  root      320   77    65208  22640 ffffffff 00000000 S /system/b2g/plugin-container
$ 

And there is no keyboard at all in settings !

Comment 27

[Jan Jongboom [:janjongboom] (inactive)]

What I saw on a Peak was that the keyboard was rendered and running et al, but the client keyboard sent a height of 0px to the system app (keyboard_manager) which is why you don't see anything. Haven't investigated further.

Comment 28

[Jan Jongboom [:janjongboom] (inactive)]

Alright, so that seems because the height of the keyboard window with APZ (via window.innerHeight) is 0. And without APZ its 640 so something flaky is going on.

Pinging Vivien.

Comment 29

[Julien Wajsberg [:julienw]]

jan, can you point to the actual code that gets the innerHeight ?

Comment 30

[Jan Jongboom [:janjongboom] (inactive)]

:julienw,

Specifically the info gets communicated in keyboard.js in the updateTargetWindowHeight function. It uses | IMERender.ime.scrollHeight| to get the height. But that's 0 because at that moment (or any given moment) the window height is 0, as you can see in render.js, function resizeUI, line 711.

Comment 31

[Dale Harvey (:daleharvey)]

Now happening on my helix

Comment 32

[Julien Wajsberg [:julienw]]

Vivien told me a lot of APZC fixed have been happening, did someone tried on a recent (as of today) Gecko build? I haven't yet but I will.

Comment 33

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Julien Wajsberg [:julienw] from comment #32)
> Vivien told me a lot of APZC fixed have been happening, did someone tried on
> a recent (as of today) Gecko build? I haven't yet but I will.

If someone brings me  device where this happen 100% I will happily work on it :)

Comment 34

[Bill Maggs (bmaggs)]

No keyboard showing up on Nightly builds on both Peak and Keon as of 065606 (Peak) and 025350 (Keon). 0 pixel problem? Who can I bring one of these devices to to check on it in California?

Comment 35

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

I'm building master for Peak and Helix right now. If I can repro I'll debug it.

Comment 36

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

Attachment: Backtrace of keyboard app crash (Peak debug build)

My Peak build is a debug build, and the first time after a reset-gaia when I bring up the keyboard, the keyboard app crashes because of an assertion failure. It could be that this manifests as the keyboard not showing in non-debug builds. We should figure out what's going on here.

Comment 37

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

BenWa, do you know this code? ^

Comment 38

[Milan Sreckovic [:milan] (needinfo for best results)]

We'll block on this as it affects the developers a great deal, as that's where Peaks are mostly.

Comment 39

[Benoit Girard (:BenWa)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #36)
> Created attachment 8370116 [details]
> Backtrace of keyboard app crash
> 
> My Peak build is a debug build, and the first time after a reset-gaia when I
> bring up the keyboard, the keyboard app crashes because of an assertion
> failure. It could be that this manifests as the keyboard not showing in
> non-debug builds. We should figure out what's going on here.

I don't know the Gralloc code all that well TBH. Have you checked adb lolcat? Sometimes there's Gralloc timeouts that can occur. Otherwise Sotaro or Taiwan GFX team may be of better help.

Comment 40

[Botond Ballo [:botond]]

(In reply to Benoit Girard (:BenWa) from comment #39)
> Have you checked adb lolcat?

'adb lolcat' actually works and is an alias for 'adb logcat'. Nice :)

Comment 41

[Bill Maggs (bmaggs)]

Nobody but me reproing this on Keon? There are many more of those in developers' hands.

Comment 42

[sarsenyev]

I'm having the same issue when changing other language than English, they keyboard didn't show up even after resetting.
In "Keyboard's settings" only numbers are selected, to make the keyboard appear user needs to select "English" from the menu
Maybe it's a base image issues and needs to be re-based to work it properly

Device: Buri 1.3 MOZ
BuildID: 20140203181708
Gaia: bb36b4164d3e51ca04b612e507e1178f80bf240d
Gecko: 9731b0b7fa78
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 43

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

Attachment: Logcat for gralloc failure (Peak)

Sotaro, have you seen the crash in comment 36 before? I'm attaching logcat from a non-debug build when I first bring up the keyboard.

Comment 44

[Benoit Girard (:BenWa)]

From the log it looks like the Keon isn't set up to fallback to ashmem gralloc when the super limited pmem runs out. Sotaro can you confirm?

Comment 45

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

Attachment: Logcat for gralloc failure (Peak debug)

Here's the logcat from a debug build on Peak. gdb caught the SIGSEGV from the MOZ_ASSERT at just after the logs at timestamp 13:41:00 (there's a 20 second gap where I was broken in gdb). There's some warnings from RotatedBuffer.cpp here if that's of any help.

Comment 46

[Milan Sreckovic [:milan] (needinfo for best results)]

Nick, anything that looks interesting in the log?  This just based on Kats' last comment about RotatedBuffer.

Comment 47

[Nick Cameron [:nrc]]

The RotatedBuffer warnings are because we couldn't lock a draw target to draw into - almost certainly because we could not allocate the gralloc memory as indicated by the failure messages just above the warnings. So, the warnings are caused by the allocation failure, they don't give any indication of why the allocation failure happens.

Comment 48

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

Putting needinfo back on sotaro for comment 36/comment 43.

Comment 49

[Sotaro Ikeda [:sotaro]]

(In reply to Benoit Girard (:BenWa) from comment #44)
> From the log it looks like the Keon isn't set up to fallback to ashmem
> gralloc when the super limited pmem runs out. Sotaro can you confirm?

The fallback is fixed by Bug 905882. And I confirmed the following peak's source code does not have a fallback code.
 - https://github.com/gp-b2g/hardware_qcom_display


code aurora's diffs are the following.

https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/commit/?h=b2g_ics_1.2&id=be8edec21365db5fd27f34e72b1bacea28453214

https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/commit/?h=b2g_ics_1.2&id=d5cd12fff68b768eab1e444cdc5eac6e8823220a

Comment 50

[Jean Gong :jgong]

PM team triaged this bug. This remains a blocker.

Comment 51

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

(In reply to Sotaro Ikeda [:sotaro] from comment #49)
> (In reply to Benoit Girard (:BenWa) from comment #44)
> > From the log it looks like the Keon isn't set up to fallback to ashmem
> > gralloc when the super limited pmem runs out. Sotaro can you confirm?
> 
> The fallback is fixed by Bug 905882. And I confirmed the following peak's
> source code does not have a fallback code.
>  - https://github.com/gp-b2g/hardware_qcom_display
> 
> 
> code aurora's diffs are the following.
> 
> https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/
> commit/?h=b2g_ics_1.2&id=be8edec21365db5fd27f34e72b1bacea28453214
> 
> https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/
> commit/?h=b2g_ics_1.2&id=d5cd12fff68b768eab1e444cdc5eac6e8823220a

Unfortunately this doesn't mean a whole lot to me. I read through the bug you referenced and it sounds to me like the fallback was only set up for hamachi, which means that some (all?) other devices will still have this problem. Is that correct? Is it possible to get the fallback code on other devices?

Comment 52

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 53

[Sotaro Ikeda [:sotaro]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #51)
> 
> Unfortunately this doesn't mean a whole lot to me. I read through the bug
> you referenced and it sounds to me like the fallback was only set up for
> hamachi, which means that some (all?) other devices will still have this
> problem. Is that correct? Is it possible to get the fallback code on other
> devices?

Current b2g phone's manifest reference caf 1.2 source. All b2g device that uses caf 1.2 source already include the change. geek phone is not using caf 1.2 source. Therefore the problem happens. The change code is gonk's hw dependent code. About the peak, the geek phone should be responsible for it.

Comment 54

[Sotaro Ikeda [:sotaro]]

I checked the following b2g-manifest. It seems only hamachi device's manifest uses caf's "b2g_ics_1.2". It might be better to ask mwu about code maintenance policy.
  https://github.com/mozilla-b2g/b2g-manifest

NB, qcom does not provide support to ics_chocolate(old code). They provide support only to ics_strawberry. b2g's code apply CodeAurora(qcom)'s patches only to ics_strawberry, not to ics_chocolate, because of no qcom support. I know unagi and inari uses ics_chocolate. So the patches did not applied to unagi and inari. IIRC, geek phone seems to use ics_chocolate.

Comment 55

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

mwu, is there anything preventing us from moving other devices to ics_strawberry to get the above fixes?

Sounds like from what Sotaro's saying, we would need the Geeksphone people to update their manifest as well?

Comment 56

[Michael Wu [:mwu]]

We can also update leo to b2g_ics_1.2 - it's mostly a matter of having time to test the manifest changes.

Unagi is not supported.

Inari was updated to ics_strawberry in the 1.1 update, I believe. Our manifest may need to be updated.

Geeksphone devices are on neither ics_strawberry nor ics_chocolate. They're based off some other branch. However, we can submit pull requests to their repos.

Comment 57

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

Do you know should look into doing this?

Comment 58

[Sotaro Ikeda [:sotaro]]

This is [POVB] problem. So set it again to "1.3?". Could [POVB] be a 1.3 blocker?

Comment 59

[Jason Smith [:jsmith]]

(In reply to Sotaro Ikeda [:sotaro] from comment #58)
> This is [POVB] problem. So set it again to "1.3?". Could [POVB] be a 1.3
> blocker?

Nope.

Comment 60

[Michael Wu [:mwu]]

I want Dale to be happy though.

We can update our manifests, but in most cases people are doing gecko+gaia flashes, so the problem is better fixed by picking up an updated base image. So I don't consider fixing the inari/leo manifest as important as making sure people have access to a 1.2 base image. I think the only remaining thing to improve things to devs is to submit a pull request to the geeksphone repo.

Comment 61

[Emanuel Hoogeveen [:ehoogeveen]]

I'm not sure if it adds anything at this point, but I also saw this on my ZTE Open after flashing it to the master branch. Note that to be able to flash the Open to anything other than the official ZTE packages, I had to apply the boot.img from bug 925502 comment #27 (but with that, 1.3 is working fine).

Comment 63

[:gerard-majax]

Something recently changed, I don't reproduce this anymore on Nexus S nor Desire Z. Maybe it's related to NUWA/OOP keyboard changes that recently landed ?

Comment 64

[Dale Harvey (:daleharvey)]

There has been various keyboard fix landings, I suspect this is fixed, will close resolved when I get a chance to test if noone else does it before me

Comment 65

[Dale Harvey (:daleharvey)]

In particular https://bugzilla.mozilla.org/show_bug.cgi?id=967587

Comment 66

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

This was fixed by bug 968957. Some discussion also in bug 968501, and bug 968991 was filed as a follow-up to fix the underlying issue and re-enable OOP keyboards.

Comment 67

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

Also it looks like the whole gralloc fallback/POVB thing was a red herring. We might still want to do something for that but it's unrelated to the keyboard issue.

Comment 68

[:gerard-majax]

FYI, I've re-enabled APZC for all contents on: Buri, Nexus S and Desire Z. Keyboards shows up correctly on all those.