Closed Bug 1033943 Opened 10 years ago Closed 10 years ago

[B2G] [Dialer] cannot make a call right after unlocking PIN code upon Dialer app

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+)

RESOLVED INVALID
2.0 S6 (18july)
blocking-b2g 1.4+

People

(Reporter: hsinyi, Assigned: drs)

Details

Saw this on buri and flame.

Buri pvt build ID: 20140702160201, master branch, eng. build

STR:

1) Set SIM pin enabled
2) Reboot and skip entering pin in lock screen
3) Launch dialer app
4) Being asked to enter pin, and enter pin. Then status bar shows signal bar correctly. SIM pin is unlocked.
5) Enter a number on dialer keypad and dial out

Actual result:
Cannot dial out due to "No network connection" error. If you close the dialer app, re-launch it, re-dial, then call could be made successfully.

Expected result:
After pin unlocked, call can be made without re-launching the dialer app.
QA Wanted for branch checks.
Keywords: qawanted
QA Contact: ekramer
This issue DOES reproduce on Flame 2.1, Flame 2.0, Flame 1.4, and Buri 2.1
   
Flame Master (2.1)
BuildID: 20140708040218
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: 465280604ea6
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
      
Flame 2.0
BuildID: 20140708000322
Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko: 3f9d7a3a0b7b
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4
BuildID: 20140707000200
Gaia: 5c9e1e4131d3ac8915ed88b72bb66dc7d97be6a0
Gecko: 2d0c15450488
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri Master (2.1)
BuildID: 20140708034259
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: 465280604ea6
Version: 33.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Actual Results:
Cannot dial out due to "No network connection" error.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Holy guacamole, this is really bad.
blocking-b2g: --- → 1.4?
You can also wait a few seconds and then it works. I might take this.
Assignee: nobody → drs+bugzilla
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Target Milestone: --- → 2.0 S6 (18july)
triage: blocking. it's very annoying to end users.
blocking-b2g: 1.4? → 1.4+
I looked into this some more and I was only able to repro it up to about 2 seconds after entering the PIN. I didn't find that I had to restart the dialer app, though. Here's specifically what's happening:

When placing this call, we're getting conn.voice.emergencyCallsOnly=true here:
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L86

Then, because of this, we're getting a BadNumberError here:
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L136

I tried forcing it to dial anyways here by disabling the check for emergencyCallsOnly:
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L102

This didn't work and the call just failed. So it seems that we're not properly connected but the indicator in the status bar is showing that we are.

Hsin-Yi, is this still happening for you? What happens if you wait a few seconds instead of restarting the dialer?
Status: NEW → ASSIGNED
Flags: needinfo?(htsai)
(In reply to Doug Sherk (:drs) from comment #6)
> I looked into this some more and I was only able to repro it up to about 2
> seconds after entering the PIN. I didn't find that I had to restart the
> dialer app, though. Here's specifically what's happening:
> 
> When placing this call, we're getting conn.voice.emergencyCallsOnly=true
> here:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/
> js/telephony_helper.js#L86
> 
> Then, because of this, we're getting a BadNumberError here:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/
> js/telephony_helper.js#L136
> 
> I tried forcing it to dial anyways here by disabling the check for
> emergencyCallsOnly:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/
> js/telephony_helper.js#L102
> 
> This didn't work and the call just failed. So it seems that we're not
> properly connected but the indicator in the status bar is showing that we
> are.
> 
> Hsin-Yi, is this still happening for you? What happens if you wait a few
> seconds instead of restarting the dialer?

Thanks for the investigation, Doug.

I confirm that a call could be made out if I wait for a few more seconds without re-launching the dialer.
Flags: needinfo?(htsai)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> Thanks for the investigation, Doug.
> 
> I confirm that a call could be made out if I wait for a few more seconds
> without re-launching the dialer.

Hsin-Yi, do you have any suggested next steps? It looks like either the status bar is wrong or the RIL stack is taking a while to update the status. I would suspect the former, since I can't force place a regular call using telephony.dial() for the few seconds after entering a SIM.
Flags: needinfo?(htsai)
(In reply to Doug Sherk (:drs) from comment #8)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> > Thanks for the investigation, Doug.
> > 
> > I confirm that a call could be made out if I wait for a few more seconds
> > without re-launching the dialer.
> 
> Hsin-Yi, do you have any suggested next steps? It looks like either the
> status bar is wrong or the RIL stack is taking a while to update the status.
> I would suspect the former, since I can't force place a regular call using
> telephony.dial() for the few seconds after entering a SIM.

Hey Doug,

I think neither status bar nor RIL stack is wrong. The criteria to show signal bar are slightly different from making a call that is possible status bar gets ready earlier. I seem not have reached this timing difference before, and that's why I filed the bug. But based on your analysis and the code, nothing is wrong. I would close the bug as INVALID. Feel free to reopen it if you don't agree. Sorry for the noise :\
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(htsai)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.