Closed Bug 993394 Opened 10 years ago Closed 10 years ago

[SIM PIN] Not always possible to insert PIN code after restarting the device

Categories

(Firefox OS Graveyard :: Runtime, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed)

VERIFIED FIXED
2.0 S2 (23may)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: noemi, Assigned: xyuan)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

Attached video PIN_Input_Field.3gp
This has been seen with today's (4/8) master build:
Device: Hamachi
BuildId: 20140408064955
Gecko: d0849cf
Gaia: 0990794
Platform version: 31.0a1

The issue doesn't occur on today's (4/8) v1.4 and v1.3 builds

Pre-requisites:
Use a SIM with PIN enabled

STR
1. Turn on the device, not for the first time, or restart it from long tap on
power off key, to get the Enter SIM PIN screen
2. Try to enter PIN code
2a. Directly in case lock screen is ON
2b. Unlocking screen first in case lock screen is OFF

ACTUAL
2a. In case lock screen is OFF, Enter SIM PIN screen is shown with SIM PIN field but not the keypad, it is not possible to insert PIN code till tapping out of SIM PIN field and tapping in again
2b. In case lock screen is ON, after unlocking the screen, Enter SIM PIN screen is shown SIM PIN field but not the keypad, it is not possible to insert PIN code till tapping out of SIM PIN field and tapping in again

EXPECTED
No matter if lock screen is ON or OFF it should always be possible to enter PIN code. Enter SIM PIN screen should appear with the focus on SIM PIN field and keypad

NOTE: This issue ALWAYS occurs if lock screen is OFF, in case not, it depends on how fast users unlock the screen, if you wait some seconds after restarting the device and before unlocking the screen, the error can't be reproduced
blocking-b2g: --- → 1.5?
Keywords: regression
QA Contact: pcheng
TINDERBOX:
This looks to be a gaia issue.

last working gaia/first broken gecko = NO REPRO
Gaia  db2ef2b61c70889533a0837fa3e053d24e95fdea
Gecko d6e549d77ab2

first broken gaia/last working gecko = REPRO
Gaia  2346ad9002062d70b6b27978c6b942f04192bf1b
Gecko 2b27d0ec27e9

B2G INBOUND:
- Last Working -
Device: Buri ENG Master (2.0) MOZ RIL
BuildID: 20140318202202
Gaia: 854f8d91d77fb1364683bf909f7605c185043c8e
Gecko: 38a3545c5a6c
Version: 31.0a1
Firmware Version: v1.2-device.cfg

- First Broken -
Device: Buri ENG Master (2.0) MOZ RIL
BuildID: 20140319000201
Gaia: db2ef2b61c70889533a0837fa3e053d24e95fdea
Gecko: a6476baa3307
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Push log: https://github.com/mozilla-b2g/gaia/compare/854f8d91d77fb1364683bf909f7605c185043c8e...db2ef2b61c70889533a0837fa3e053d24e95fdea
QA Contact: pcheng → mvaughan
I think the window above is incorrect. None of the changesets appear to be relevant to being the cause of this bug.
(In reply to Jason Smith [:jsmith] from comment #2)
> I think the window above is incorrect. None of the changesets appear to be
> relevant to being the cause of this bug.

Another tester and I re-tested the regression window and found that it looks to be correct. We were unable to reproduce this issue on builds before the first broken (even with the knowledge that the repro rate could be quite lower), and can see a clear no repro/repro between the two builds in the window.

Additionally, I re-tested the gaia/gecko swap and the results showed that it is a gaia issue. I, however, incorrectly listed the gaia/gecko swap gaias and therefore the swap should appear as:

last working gaia/first broken gecko = NO REPRO
Gaia  2346ad9002062d70b6b27978c6b942f04192bf1b
Gecko d6e549d77ab2

first broken gaia/last working gecko = REPRO
Gaia  db2ef2b61c70889533a0837fa3e053d24e95fdea
Gecko 2b27d0ec27e9

In case it's helpful, the swap's gaia push log is https://github.com/mozilla-b2g/gaia/compare/2346ad9002062d70b6b27978c6b942f04192bf1b...db2ef2b61c70889533a0837fa3e053d24e95fdea .
Hmm...I can't pin point exactly what commit caused this.

Tim - Do you see anything the gaia push log that might have caused this?
Flags: needinfo?(timdream)
I was original suspect it's due to lock screen but there isn't a commit there. Will bisect.
Assignee: nobody → timdream
Flags: needinfo?(timdream)
I just tried 2346ad9002062d70b6b27978c6b942f04192bf1b and db2ef2b61c70889533a0837fa3e053d24e95fdea on Unagi and I cannot reproduce this bug on both commits.

It does not reproduce on current master (3fd4264899c5459db2bfa2b6cc78ef7f2eef4013) either.

Do I need a Buri to reproduce? If so this sounds like a racing or device specific issue.
Assignee: timdream → nobody
Keywords: qawanted
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> I just tried 2346ad9002062d70b6b27978c6b942f04192bf1b and
> db2ef2b61c70889533a0837fa3e053d24e95fdea on Unagi and I cannot reproduce
> this bug on both commits.
> 
> It does not reproduce on current master
> (3fd4264899c5459db2bfa2b6cc78ef7f2eef4013) either.
> 
> Do I need a Buri to reproduce? If so this sounds like a racing or device
> specific issue.

I was able to reproduce this issue on a Buri, Helix, and Leo using the 04/16/14 Master build.

- Buri Master -
Device: Buri Master MOZ RIL
BuildID: 20140417040206
Gaia: dadf0e60a6421f5b57ee9fc536c6617212805c19
Gecko: c55dfb01a027
Version: 31.0a1
Firmware Version: v1.2-device.cfg
Keywords: qawanted
(In reply to Matthew Vaughan from comment #7)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #6)
> > I just tried 2346ad9002062d70b6b27978c6b942f04192bf1b and
> > db2ef2b61c70889533a0837fa3e053d24e95fdea on Unagi and I cannot reproduce
> > this bug on both commits.
> > 
> > It does not reproduce on current master
> > (3fd4264899c5459db2bfa2b6cc78ef7f2eef4013) either.
> > 
> > Do I need a Buri to reproduce? If so this sounds like a racing or device
> > specific issue.
> 
> I was able to reproduce this issue on a Buri, Helix, and Leo using the
> 04/16/14 Master build.
> 
> - Buri Master -
> Device: Buri Master MOZ RIL
> BuildID: 20140417040206
> Gaia: dadf0e60a6421f5b57ee9fc536c6617212805c19
> Gecko: c55dfb01a027
> Version: 31.0a1
> Firmware Version: v1.2-device.cfg

CORRECTION: I was able to reproduce on the 04/17/14 Master build, not the 04/16.
blocking-b2g: 2.0? → 2.0+
Whiteboard: [systemsfe]
Whiteboard: [systemsfe]
There are a lot of keyboard changes in the regression range. Maybe a regression from enabling OOP keyboard and it's just super slow to start the keyboard app during the boot process?
Component: Gaia::System → Gaia::Keyboard
Flags: needinfo?(rlu)
I could reproduce this on current master with buri device,

With the following case, it is much easier to reproduce,
===
2a. In case lock screen is OFF, Enter SIM PIN screen is shown with SIM PIN field but not the keypad, it is not possible to insert PIN code till tapping out of SIM PIN field and tapping in again

Could not reproduce this with lockscreen=on case, but will track the above case first.

build info
==========
aia      cadddcac2b8ce162a5e27e6dc105557b00a94478
Gecko     https://hg.mozilla.org/mozilla-central/rev/b681a6daea3b
BuildID   20140428160200
Version   32.0a1
ro.build.version.incremental=291
ro.build.date=Wed Dec  4 09:48:04 CST 2013
Assignee: nobody → rlu
Flags: needinfo?(rlu)
I found that with 2a, lockscreen=off case (see comment 10), keyboard app would not get inputcontextchange event, so this looks like a gecko issue to me.

Jan, Yuan,

Could you help take a look?
Thanks.

If you need debug dump at Gaia side, you could take my testing branch,
https://github.com/RudyLu/gaia/tree/keyboard/debug_message_launch
Flags: needinfo?(xyuan)
Flags: needinfo?(janjongboom)
Component: Gaia::Keyboard → Runtime
This looks similar to bug 987549.
See Also: → 987549
Will take a look at it late today and clear the need info flag if I find the cause in gecko.
I am limited availability due to PTO and conferences this week, plus Yuan looks into it :-)
Flags: needinfo?(janjongboom)
Yuan,

Do we have any updates on this?

Steven,

May I know if your team has the bandwidth to help us check input method API related issues?
Thanks.
Flags: needinfo?(slee)
Could not reproduce with today's master build(5/14) with hamachi, even if I made screen lock off.
Flags: needinfo?(xyuan)
Hi Yuan,

Thanks for checking this issue.
However, I still could reproduce this issue with today's build.

If it is not reproducible, could you try to reboot the phones and try again?

==
Gaia      461ea9a09563c2caf1fe5195227d126dadb83dc5
Gecko     https://hg.mozilla.org/mozilla-central/rev/e5f321740d10
BuildID   20140513160204
Version   32.0a1
ro.build.version.incremental=291
ro.build.date=Wed Dec  4 09:48:04 CST 2013
Flags: needinfo?(slee) → needinfo?(xyuan)
Hi Rudy,

I rebooted the phone several times and cannot reproduce it either.

The keypad would not be shown immediately after the phone reboots, but with several seconds delay.

The build info:

==
Gaia      e5669376
Gecko     2f8af55d6e9a (https://hg.mozilla.org/mozilla-central/rev/2f8af55d6e9a)
Version   32.0a1
Flags: needinfo?(xyuan)
Attached video not reproducible.ogv
I recorded a video for comment 18.
Hmm, very strange.

Yuan,

Did you flash your hamachi and start the test from scratch?
That is what I did to reproduce this issue, so no custom code or any thing, btw, I'm flashing engineering build with https://github.com/Mozilla-TWQA/B2G-flash-tool.

If you still could not reproduce it, could you provide a patch that could dump debug log at Gecko part of code, that I could collect some logs for this issue?
Thanks.
Flags: needinfo?(xyuan)
Not sure this helps, but logged what I saw,
 1. When I re-flash Gaia to my phone with SIM card inside, I found this issue is gone!
    After rebooting the phones several times, I found I could NOT reproduce it as you said.

 2. I tried to remove the SIM and boot the phone again.
    And then shutdown the phone and insert the SIM card back into it and reboot, and then I could see this issue reproduced.
    No clue why this step is relevant.
It seems to be SIM card related.

I reflashed the phone completely with a China Unicom SIM card and cannot reproduced it,
but with a China Mobile SIM card, I can reproduced it.
Flags: needinfo?(xyuan)
Yuan,

Do you think this is a Gecko issue?
If yes, please help on this.

Let me know if you think we should tackle this from Gaia side.
Thanks.
Assignee: rlu → nobody
Flags: needinfo?(xyuan)
Let me try to solve it.
Assignee: nobody → xyuan
Flags: needinfo?(xyuan)
The cause of this bug is similar to bug 987549.

We need a short time to initialize the keyboard app iframe, which is a mozbrowser. We must activate the app mozbrowser after the BrowserElementChildPreload.js of the mozbrowser loads.

When system reboot, we activate the keyboard app mozbrowser before it is initialized. That's why we fail.
Status: NEW → ASSIGNED
Attached patch gecko v1 (obsolete) — Splinter Review
When calling the SetInputMethodActive method of a mozbrowser, we should wait until the BrowserElementChild of the mozbrowser being initialized.

If the BrowserElementChild is not ready, the calling will be pending.
Attachment #8424709 - Flags: review?(fabrice)
Attachment #8424709 - Flags: review?(fabrice) → review+
Attached patch gecko v1Splinter Review
update commit message to include the reviewer.
Attachment #8424709 - Attachment is obsolete: true
Attachment #8425297 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/7225400d9c79
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S2 (23may)
Depends on: 1020726
Tested and working
Hamachi
2.0
Gecko: 18002f7
Gaia: 459e69f
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: