I had exported 514 contacts to my SIM card using Android's contact manager. Then I imported them to B2G and only 250 got imported and many contacts are missing. Android currently says that there are 344 contacts on a SIM card (I guest that the rest are contacts with only email address filled without phone number).

Bartosz, This seems to be a similar issue to the one reported in bug 832898. as I said there once bug 835555 lands please recheck this as I believe that patch should be solving your issue. best

[UX-P1], [TEF_REQ] because import from SIM must import all contacts from SIM not a user undefined subset of them.

(In reply to Jose M. Cantera from comment #1) > This seems to be a similar issue to the one reported in bug 832898. as I > said there once bug 835555 lands please recheck this as I believe that patch > should be solving your issue. Unfortunately that didn't solve the case. I had a progress bar but it was saying that there are only 250 contacts on the SIM card.

Currently we support only 254 SIM contacts as it's the minimum requirement from our parters.

Hi, Just fyi. Maximum number of contacts stored in the SIM card depends on type of SIM, although most common is up to 250 contacts. From Telefonica side, it's only requested to be able to import/export contacts from/to SIM card up to 250, so this would not be an issue. Thanks! David

(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #4) > Currently we support only 254 SIM contacts as it's the minimum requirement > from our parters. Why can't we support more?

(In reply to Mounir Lamouri (:mounir) from comment #7) > (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #4) > > Currently we support only 254 SIM contacts as it's the minimum requirement > > from our parters. > > Why can't we support more? This bug is in our TODO list but just not has so much priority, currently we're focus on Multi-SIM, if you can help to speed up that, it will be very appreciated.

(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #8) > (In reply to Mounir Lamouri (:mounir) from comment #7) > > (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #4) > > > Currently we support only 254 SIM contacts as it's the minimum requirement > > > from our parters. > > > > Why can't we support more? > > This bug is in our TODO list but just not has so much priority, currently > we're focus on Multi-SIM, if you can help to speed up that, it will be very > appreciated. I understand that this is not done yet and will be done as soon as you guys will have some bandwidth. However, I wonder why the limitation has been set to 254 contacts. Is there more work to do to have more contacts? Does that imply supporting some specific hardware? (the hardware being the sim card in that case)

(In reply to Mounir Lamouri (:mounir) from comment #9) > I understand that this is not done yet and will be done as soon as you guys > will have some bandwidth. However, I wonder why the limitation has been set > to 254 contacts. Is there more work to do to have more contacts? Does that > imply supporting some specific hardware? (the hardware being the sim card in > that case) One phone book set could have several fields : name, number (EF_ADN), additional number (EF_ANR), email (EF_EMAIL), ... etc. Each field (or Elementary File) has at most 254 records (0x00 ~ 0xff, but 0x00 is an invalid record number). In order to support > 254 contacts, we need to read more than 1 phone book sets. Currently we only read 1 phone book set.

Correct my previous comment: (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #10) > One phone book set could have several fields : name, number (EF_ADN), > additional number (EF_ANR), email (EF_EMAIL), ... etc. > Each field (or Elementary File) has at most 254 records >(0x00 ~ 0xff, but 0x00 is an invalid record number). and 0xff is also an invalid record number. So the record number ranges from 0x01 ~ 0xfe -> total 254 records.

Comment on attachment 735565 [details] [diff] [review] Part 1: Support more phonebook sets when reading ICC contact Review of attachment 735565 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +11392,5 @@ > + if (!pbr.adn) { > + let error = onerror || debug; > + error("Cannot access ADN."); > + return; > + } That's a little bit confusing. Can ADN be omitted?

Move pbr.adn check into parsePbrTlvs.

Comment on attachment 735579 [details] [diff] [review] Part 1: Support more phonebook sets when reading ICC contact. v2 Review of attachment 735579 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +11108,5 @@ > > + // EF_ADN is mandatory if and only if DF_PHONEBOOK is present. > + if (!pbr.adn) { > + throw new Error("Cannot access ADN."); > + } Second thought, throw exception here causes more problem in error handling. Some related functions already use onerror callbacks. Can't we return NULL here instead?

move the pbr.adn check outside parsePbrTlvs and use onerror callback.

Comment on attachment 735660 [details] [diff] [review] Part 1: Support more phonebook sets when reading ICC contact. v3 Addressed comments.

Comment on attachment 735567 [details] [diff] [review] Part 3: Support more phonebook sets when adding ICC contact. Review of attachment 735567 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +11298,5 @@ > + if (!pbr.adn) { > + let error = onerror || debug; > + error("Cannot get ADN."); > + return; > + } Should find in next PBR like what you've done below. @@ +11305,5 @@ > + pbr.adn.fileId, > + onsuccess, > + function (errorMsg) { > + findFreeRecordId.bind(this, pbrIndex + 1); > + }.bind(this)); Here.

Comment on attachment 735569 [details] [diff] [review] Part 5: xpcshells tests. Review of attachment 735569 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/tests/test_ril_worker_icc.js @@ +2088,5 @@ > + * Verify ICCContactHelper.updateICCContact with appType is CARD_APPTYPE_USIM. > + */ > +add_test(function test_update_icc_contact() { > + let worker = newUint8Worker(); > + let record = worker.ICCRecordHelper; recordHelper? @@ +2113,5 @@ > + * Verify ICCContactHelper.findFreeICCContact > + */ > +add_test(function test_find_free_icc_contact() { > + let worker = newUint8Worker(); > + let record = worker.ICCRecordHelper; ditto.

Remove the pbr.adn check as we have done this in Part 1 patch.

Addressed comments.

check if onerror is defined before calling it.

Comment on attachment 735568 [details] [diff] [review] Part 4: Support more phonebook sets when updating ICC contact. Review of attachment 735568 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +11606,5 @@ > + if (!pbr.adn) { > + let error = onerror || debug; > + error("Cannot access ADN."); > + return; > + } I should also remove this.

remove the pbr.adn check.

Rebase. This patch has been r+ by vicamo.

Rebase. This patch has been r+ by Vicamo.

Rebase. This patch has been r+ by Vicamo.

Update wrong patch.

Rebase. This patch has been r+ by Vicamo.

Rebase. This patch has been r+ by Vicamo.

http://hg.mozilla.org/projects/birch/rev/e465ed12846d http://hg.mozilla.org/projects/birch/rev/502bedabba41 http://hg.mozilla.org/projects/birch/rev/b3c4b6d69d60 http://hg.mozilla.org/projects/birch/rev/f21652870d51 http://hg.mozilla.org/projects/birch/rev/fe184c67d869

https://hg.mozilla.org/mozilla-central/rev/e465ed12846d https://hg.mozilla.org/mozilla-central/rev/502bedabba41 https://hg.mozilla.org/mozilla-central/rev/b3c4b6d69d60 https://hg.mozilla.org/mozilla-central/rev/f21652870d51 https://hg.mozilla.org/mozilla-central/rev/fe184c67d869