Closed Bug 1083541 Opened 10 years ago Closed 10 years ago

[Usage][Airplane Mode] Launching Usage app with Airplane mode and SIM Pin enabled causes the app to display an endless load screen

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S7 (24Oct)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: Marty, Assigned: edgar)

References

Details

(Keywords: regression, Whiteboard: [2.1-Daily-Testing][FT:RIL])

Attachments

(4 files, 1 obsolete file)

Attached file Usage_log.txt
Description:
If the user has a SIM Pin enabled, and boots the phone with Airplane Mode enabled, the Usage app will display an odd looking loading screen when launched, which the app will not be able to progress past.

Note, if the Usage app is launched just with Airplane mode enabled, it will launch normally.  If it is launched with just SIM PIN enabled, it will display an appropriate error message.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141015001201
2) Perform the initial set up for the Usage app
3) Enable Sim Pin
4) Enable Airplane Mode
5) Restart the device
6) Launch the Usage app
  
Actual:
Usage app displays endless loading screen
  
Expected: 
Usage app displays an error message for the user.
  
Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20141015001201 (Full Flash)
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko: 4853208cb48a
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.
  
Repro frequency: 5/5
See attached: screenshot, logcat

---------------

This issue DOES occur on Flame 2.2
Usage app displays an endless loading screen when launched with Airplane mode and Sim Pin enabled.

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141015040201
Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6
Gecko: 62f0b771583c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Attached image Usage_Screenshot.png
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QAWanted for Branch Checks.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
The bug repros on Flame 2.2 and Flame 2.1 on engineering builds with shallow flash.
Actual result: When the user launches the Usage app with SIM PIN and Airplane Mode active, the screen will show a spinner and a scrollbar with nothing else appearing.

Flame 2.2
BuildID: 20141016070843
Gaia: 5c636a7a54b2c86d8ff6bc1aa1e5f9594c7bc586
Gecko: 77f3ca1fe052
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Platform Version: 36.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.1
BuildID: 20141016093626
Gaia: 1d95ad15e3d222c97d552c79f152f11a5583bd07
Gecko: 9034297eb0ea
Gonk: 
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0 engineering build with shallow flash.
Actual result: When the user launches the Usage app with SIM PIN and Airplane Mode active, the screen will show an error page asking the user to disable Airplane Mode.

BuildID: 20141016082526
Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko: b19fe9009a7c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Platform Version: 32.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
[Blocking Requested - why for this release]: breakage in a major app
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
Blocking given this is a regression  in a major app.
blocking-b2g: 2.1? → 2.1+
Bug 1013847 seems to be the cause of this issue.

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140828223200
Gaia: 6f270b9fee0c1f09863f5e1aa640937a07c7fdae
Gecko: 18ed4643a705
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140828234459
Gaia: f087c45c328f16bf6f8d5a4d9452fa9a27aa6c7b
Gecko: a57d1aa27da9
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: 2a354048f964

First Broken gaia / Last Working gekko - 

Gecko Pushlog: https://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=18ed4643a705&tochange=a57d1aa27da9
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
possibly broken by Bug 1013847 - can you take a look Edgar?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(echen)
QA Contact: jmercado
Attachment #8507643 - Attachment mime type: text/x-log → text/plain
Flags: needinfo?(echen)
Before bug 1013847, gecko reported card as "undetected" (no icc object actually) if gecko can not get card status explicitly, e.g, inserting a CDMA card into GSM devices, or subscription isn't activated. 
But the behavior was obviously wrong, because device has indeed a sim card inserted.

So we correct it in bug 1013847: for above case, gecko should still create a icc object, but reports the card state as "unknown" (unable to get card status explicitly).

From the log in comment #8, when we restart flame with airplane mode enabled, the appIndex is -1 and gecko will report card state as "unknown". But costcontrol seem not handle it well if card state is 'unknown'. [1]

> 
> 6-18 17:34:33.739   205   604 I Gecko   : RIL Worker: [0] iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":-1,"cdmaSubscriptionAppIndex":-1,"imsSubscriptionAppIndex":-1,"apps":[{"app_type":2,"app_state":1,"perso_substate":0,"aid":"a0000000871002f886ff9289050b00ff","app_label":"000000","pin1_replaced":0,"pin1":0,"pin2":0}]}
> 
> 10-16 22:51:10.430  1293  1293 I GeckoDump: (1413514270154-0) CC /index.html: Showing non-ready screen.
> 10-16 22:51:10.440  1293  1293 I GeckoDump: (1413514270154-1) CC /index.html: SIM not ready: unknown
> 

[1] https://github.com/mozilla-b2g/gaia/blob/dae2dc48fe1159db6c359fc421d93fcf5b04b068/apps/costcontrol/js/views/NonReadyScreen.js#L17-L35
Attached patch WIP patch, v1 (obsolete) — Splinter Review
Hi salva, may I have your feedback about this patch? If you are ok with this fix, I can help to provide a PR.
Attachment #8507710 - Flags: feedback?(salva)
Blocks: 1013847
Comment on attachment 8507710 [details] [diff] [review]
WIP patch, v1

Forwarding to Marina as I'm in PTO.
Attachment #8507710 - Flags: feedback?(salva) → feedback?(mri)
Comment on attachment 8507710 [details] [diff] [review]
WIP patch, v1

Review of attachment 8507710 [details] [diff] [review]:
-----------------------------------------------------------------

Although the patch works fine, IMO it's necessary add a premise with this state on the methods where the card state message to show to the user is determined

Please add the premise (|| cardState === 'unknown') on the following lines:

https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/widget.js#L48
https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/views/NonReadyScreen.js#L63

Regards
Attachment #8507710 - Flags: feedback?(mri) → feedback+
(In reply to Marina Rodríguez [:mai] from comment #12)
> Comment on attachment 8507710 [details] [diff] [review]
> WIP patch, v1
> 
> Review of attachment 8507710 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Although the patch works fine, IMO it's necessary add a premise with this
> state on the methods where the card state message to show to the user is
> determined
> 
> Please add the premise (|| cardState === 'unknown') on the following lines:
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/widget.
> js#L48
> https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/views/
> NonReadyScreen.js#L63
> 
> Regards

But if I add those check, the UI will show "Insert a SIM to enable Usage". Should we just show "Card is not ready" (Device has sim card inserted but in an 'unknown' state)?
Flags: needinfo?(mri)
Hi Edgar,
I agree with you, that the best solution could be add a new message to indicate that the simcard is not ready. I put ni to katie to confirm if ux is agree with the new message. 

But currently, on 2.1 branch, we cannot adding a new localized string. 

Regards
Flags: needinfo?(mri) → needinfo?(kcaldwell)
Hi Marina,

We should definitely add an error message for this scenario (assuming the bug cannot be fixed), the message should be specific and understandable to the user. "Card is not ready." is too vague and leads the user to ask additional questions - Which Card? When will it be ready? How long will I have to wait?

UX can help formulate the error message, but we need help understanding what the system is doing - "Device has sim card inserted but in an 'unknown' state", can you share more? Since we know the error is caused by Airplane Mode + SIM pin - is there any specific action the user can take to fix this? Ex: Turn Airplane Mode off? or "Unlock SIM card"?

NI'ing Juwei as she is now the UX designer for Smart Data / Usage App
Flags: needinfo?(kcaldwell) → needinfo?(jhuang)
(In reply to katieC from comment #15)
> Hi Marina,
> 
> We should definitely add an error message for this scenario (assuming the
> bug cannot be fixed), the message should be specific and understandable to
> the user. "Card is not ready." is too vague and leads the user to ask
> additional questions - Which Card? When will it be ready? How long will I
> have to wait?
> 
> UX can help formulate the error message, but we need help understanding what
> the system is doing - "Device has sim card inserted but in an 'unknown'
> state", can you share more?

When flame boots up with airplane mode enabled, gecko only knows there is a sim card inserted, but don't know more detailed information, e.g. is it a GSM card? is it locked? (because the radio is off)
So in such case, gecko reports card state as 'unknown' given that we don't have enough information about the sim card.

> Since we know the error is caused by Airplane Mode + SIM pin - is there any
> specific action the user can take to fix this?
> Ex: Turn Airplane Mode off? or "Unlock SIM card"?
> 

In fact, this behavior is caused by Airplane Mode, nothing related to SIM pin.
Turn Airplane mode off is enough.
Hi Edgar,
Are you taking this bug? 
I'm just making sure to get all 2.1+ assigned :)

Do you happen to know what is the error message for such case in 2.0?

I saw on comment 15 talking about adding new error messages, which I think is too late for 2.1 localization already.
We should consider using the existing strings.
Comment on attachment 8508555 [details] [review]
[mozilla-b2g:master] PR #25358

Thanks Edgard, please land once treeherder is Green.

I'm going to create a follow-up to fix the error message.
Attachment #8508555 - Flags: review+
Assignee: nobody → echen
Blocks: 1086216
NI moved to Bug 1086216 - [Usage][Airplane Mode] Launching Usage app with Airplane mode after restart shows "no sim" message instead "simcard not ready"
Flags: needinfo?(jhuang)
Attachment #8507710 - Attachment is obsolete: true
Master: 764e4fc48da000679b2167de9c2440fbf73b9b1c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8508555 [details] [review]
[mozilla-b2g:master] PR #25358

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Feature
[User impact] if declined: Launching Usage app after airplanemode is disabled, causes the app to display an endless load screen.
[Testing completed]: Yes, manually
[Risk to taking this patch] (and alternatives if risky): Low risk
[String changes made]: No
Attachment #8508555 - Flags: approval-gaia-v2.1?(release-mgmt)
Please remember to set the appropriate flags when landing.
Comment on attachment 8508555 [details] [review]
[mozilla-b2g:master] PR #25358

Requesting verification once this lands on 2.1
Attachment #8508555 - Flags: approval-gaia-v2.1?(release-mgmt) → approval-gaia-v2.1+
Keywords: verifyme
Whiteboard: [2.1-Daily-Testing] → [2.1-Daily-Testing][FT:RIL]
Issue is verified fixed in Flame 2.2, 2.1 (Full Flash, nightly). 

Actual Results: Usage app opens correctly after Restart with Airplane mode on.  

Device: Flame Master
Build ID: 20141022040201
Gaia: 4d7f051cede6544f4c83580253c743c22b0cb279
Gecko: ae4d9b4ff2ee
Version: 36.0a1 (Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1
Build ID: 20141022001201
Gaia: 3d9cc667f4e929861a9a77c41096bbf5a9c1bde0
Gecko: 928b18f7d8ff
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: