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)
Tracking
(blocking-basecamp:-, b2g18+ fixed)
RESOLVED
FIXED
blocking-basecamp | - |
People
(Reporter: qdot, Assigned: qdot)
References
Details
Attachments
(1 file)
690 bytes,
patch
|
julienw
:
review+
vingtetun
:
approval-gaia-v1+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•12 years ago
|
||
Just put RIL in debug mode. The card state flips from null to ready then back to null. Trying to figure out why now.
Assignee | ||
Comment 2•12 years ago
|
||
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.
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Comment 3•12 years ago
|
||
Another blocking reason: Blocks bb+ 822251
Assignee | ||
Updated•12 years ago
|
Severity: normal → major
Priority: -- → P1
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → kyle
Marking as tracked for v1.1
blocking-basecamp: ? → -
tracking-b2g18:
--- → +
Assignee | ||
Comment 5•12 years ago
|
||
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 6•12 years ago
|
||
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+
Assignee | ||
Comment 7•12 years ago
|
||
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)
Comment 8•12 years ago
|
||
Kyle, BTW, could you check if this bug happens in FTU as well ?
Comment 9•11 years ago
|
||
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+
Comment 10•11 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/c94217aaad7bc0283ee77e68559027a9da8e157f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
status-b2g18:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•