Intermittently the keyboard doesn't open when tapping on the Alarm name field in the Clock app. STR (about 1 in 5 frequency): 1. Open clock app 2. Tap new alarm 3. Tap Alarm Name field 4. Keyboard field does not open Device: Flame Gaia 23aa7eccd9966683b872e9d744a595b8e311eb4c Gecko https://hg.mozilla.org/integration/b2g-inbound/rev/8a5b05581196 BuildID 20140701044753 Version 33.0a1 ro.build.version.incremental=eng.cltbld.20140624.101744 ro.build.date=Tue Jun 24 10:17:54 EDT 2014 This was also picked up as an intermittent on TBPL: https://bugzilla.mozilla.org/show_bug.cgi?id=1032707 https://bugzilla.mozilla.org/show_bug.cgi?id=1032704

NB; there are no errors or anything suspicious in the logcat.

QA Wanted for branch checks.

This bug repro's on: Flame 2.1, Flame 2.0, Buri 2.1 Actual Results: There is a small window of time (approx 1 second) when the new alarm window is opening that the user can tap in the Alarm Name field where the keyboard will not pop up. Waiting longer than that amount of time seems to always produce the keyboard. Environmental Variables: Device: Flame Master Build ID: 20140630183300 Gaia: 90bb898e8401f5fb98edcf38293073c5c26ab7bd Gecko: 83c09fe3a658 Version: 33.0a1 (Master) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Device: Flame 2.0 Build ID: 20140630193053 Gaia: 28392b0960667772731131f527c4c74c05d750b1 Gecko: f60209f2f0bb Version: 32.0a2 (2.0) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Device: Buri Master Build ID: 20140630183300 Gaia: 90bb898e8401f5fb98edcf38293073c5c26ab7bd Gecko: 83c09fe3a658 Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg ----------------------------------------------- ----------------------------------------------- This bug does NOT repro on: Flame 1.4, Actual Results: Every time the user taps in the Alarm Name field, the keyboard will pop up. Environmental Variables: Device: Flame 1.4 Build ID: 20140630000201 Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8 Gecko: 8cba60bc12ef Version: 30.0 (1.4) Firmware Version: v122

Josh - I think you need to provide a blocking triage assessment here.

Zac, Do you see the flashing caret when the keyboard is not showing up? I can't see the caret with the small video. I suspect the input is simply not focused if that's the case (e.g. Clock app have something covered top of the input for example). If that is not the case, I know we have some quirks in Gecko when you try to focus on a input field during it's CSS transition. I have found bug 869512 but maybe this is not exactly the same.

Thankyou Croesch! Tim, the caret is not present. When the keyboard opens normally the clock app also highlights the input field with a blue bar along the bottom border of the field but in this case that blue bar does not appear. In my experience I've found it not opening even 1 second after it has transitioned in. The intermittent automated test also waits for the element to have reached x == 0 but perhaps that is not precisely the end of the transition as there still seems to be a race of some type going on.

OK, this is probably not a keyboard app / input management / input method API bug if the caret is not present.

(In reply to Jason Smith [:jsmith] from comment #5) > Josh - I think you need to provide a blocking triage assessment here. Right! - Not nomming as a blocker - issue seems very dependent on timing - "There is a small window of time (approx 1 second) when the new alarm window is opening that the user can tap..."

Firefox OS is not being worked on