Closed Bug 822477 Opened 12 years ago Closed 11 years ago

[contacts] "Import SIM Contacts" incorrectly disabled if SIM card disabled on mobile network

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

x86_64
Gonk (Firefox OS)

Tracking

(blocking-basecamp:-, b2g18+ fixed)

RESOLVED FIXED
blocking-basecamp -
Tracking Status
b2g18 + fixed

People

(Reporter: qdot, Assigned: qdot)

References

Details

Attachments

(1 file)

Repro:

1. Find an old SIM card that will no longer connect to the network it was made for, but has contacts on it.
2. Put SIM card in phone, boot
3. Go to Contacts -> Settings

Expected:

Import from SIM is enabled unless SIM is PIN/PUK locked

Actual:

Import from SIM is disabled

Notes:

The check in contacts/js/contacts_settings.js shows that we're checking the existence of mozMobileConnection (this should always work) and then checking whether the status of the card is "ready". mozMobileConnection says that the status can be null, 'absent', 'pinRequired', 'pukRequired', 'networkLocked', 'ready'. So apparently we're getting something other than ready back. If I kill the check for ready and always return true just to make the button come up, I can import my contacts from my SIM with no problems. 

Blocking Need:

People will possibly be changing SIMs for their new phone, at which point they may want to import from an old deactivated SIM, then swap the new SIM in.
Just put RIL in debug mode. The card state flips from null to ready then back to null. Trying to figure out why now.
Ok, the cardstate is flipping from READY to NOTREADY, which is translated as null. This means that we're treating the card as if it has an unknown error even when it just can't activate itself on the network. Creating a new bug for this since we're now into gecko territory, blocking this bug on it.
Blocks: 822251
No longer blocks: 821537
Another blocking reason: Blocks bb+ 822251
Depends on: 822522
Severity: normal → major
Priority: -- → P1
Assignee: nobody → kyle
No longer blocks: 822251
Marking as tracked for v1.1
blocking-basecamp: ? → -
tracking-b2g18: --- → +
This is the easy fix for the moment. The cardstate should only be null if there's a network exception, which means the card should still be ok to read from at least. If the card isn't even in, we'll get "absent" state.
Attachment #695864 - Flags: review?(alberto.pastor)
Comment on attachment 695864 [details] [diff] [review]
Patch 1 (v1) - Make Contact Import from SIM work even if SIM can't hit cellular network

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

r=me, thanks !
Attachment #695864 - Flags: review?(alberto.pastor) → review+
Comment on attachment 695864 [details] [diff] [review]
Patch 1 (v1) - Make Contact Import from SIM work even if SIM can't hit cellular network

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):
Attachment #695864 - Flags: approval-gaia-master?(21)
Kyle, BTW, could you check if this bug happens in FTU as well ?
Comment on attachment 695864 [details] [diff] [review]
Patch 1 (v1) - Make Contact Import from SIM work even if SIM can't hit cellular network

Safe one liner that will let you use the sim import functionality even inside an elevator.
Attachment #695864 - Flags: approval-gaia-master?(21) → approval-gaia-master+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: