Repro: 1. Go to Contacts -> Settings -> Export contacts 2. Tap on 'to SIM' 3. Select several contacts 4. Tap on 'Export' (ER1) Expected: ER1. A screen with progress bar is shown. Also, there is an option to Cancel Actual: ER1. The screen with progress bar is shown but the Cancel button isn't showed. Notes: This bug has been checked on: branch: master Gaia:43cf923 Gecko:7dc9265

Hi, I think this is something that we missed in the global export functionality. We need a global way of canceling any export type. Changing title, to perform the changes needed in order to propagate to all the strategies. Thanks!

is the cancel function already implemented in each of the export scenarios (BT/USIM/SD Card...)? if so, the general cancel funcionality can move to backlog

Joe, we can move this to backlog, but we will need to implement it at some point, otherwise Ayman is going to kill me and you as well ;)

We have the same problem in the "export to memory card". We maintain this bug for two screens, but if necessary we can open a new bug.

triage: not a blocker for v1.2 but 1.3? to keep in radar for 1.3

triage: add to backlog bug 891754

from triage point of view, this could be a target. Wilfred ?

We set it as a 1.4 target

Adding to backlog for tracking

I have a patch almost ready (tests missing), but discovered I can't really export to SIM any contact on master (created bug). I'll re-check tomorrow with different builds

(In reply to Fernando Campo (:fcampo) from comment #11) > I have a patch almost ready (tests missing), but discovered I can't really > export to SIM any contact on master (created bug). > > I'll re-check tomorrow with different builds Can you provide logs? Still happening in different builds? Thanks!

It could be related to t(In reply to Francisco Jordano [:arcturus] from comment #12) > (In reply to Fernando Campo (:fcampo) from comment #11) > > I have a patch almost ready (tests missing), but discovered I can't really > > export to SIM any contact on master (created bug). > > > > I'll re-check tomorrow with different builds > > Can you provide logs? Still happening in different builds? > It could be related with this Bug 957051 - [OPEN C_1.3] It can not export the contacts to SIM card. I am suffering it too, but it seems to be QC issue, hope it helps!

(In reply to Maria Angeles Oteo (:oteo) from comment #13) > It could be related to t(In reply to Francisco Jordano [:arcturus] from > comment #12) > > (In reply to Fernando Campo (:fcampo) from comment #11) > > > I have a patch almost ready (tests missing), but discovered I can't really > > > export to SIM any contact on master (created bug). > > > > > > I'll re-check tomorrow with different builds > > > > Can you provide logs? Still happening in different builds? > > > > It could be related with this Bug 957051 - [OPEN C_1.3] It can not export > the contacts to SIM card. > > I am suffering it too, but it seems to be QC issue, hope it helps! Yeah, definitely looks like a duplicate. Provided logs anyway, but changing dependency. Thanks Maria Angeles!

Whoa, another problem discovered. - Currently, the export to SIM is a determinative process, meaning it's done one by one so we can use the progress bar, we know how many contacts has been processed, and also we can stop it at certain point, leaving us with some contacts successfully exported, and some other not. - Export to SD (and hence BT) are not determinative. This means that the conversion to vcard is done as whole (or in batches, at least), and then exported to destination as a block. This means we don't know how many contacts had been done and how many are left, so no progress on visuals. Moreover, if we cancel the process during conversion to vcard (or anytime before saving it on destination), none of them will be exported. Apart from this, that needs to be taken into account by UX for the cancellation process (ni? Ayman as I don't see it reflected on the wireframes), we also need a modification on the conversion to vcard, or do the contact-vcard-export process one by one, if we want to be able to cancel the exporting process. For this I'll try to speak to Sergi, as I remember he had some proposal for it.

(I'm on the move now, I will write a longer reply when I have some time later today) As far as I remember, we can't do append to files in sd-card. Is that constrain going to change any time in the near future?

added to 1.5 targetted

Ok, so I've been researching after Sergi's comment 16, and ended up on bug 855952, that deals with appending on storage files. It's an old bug, and it seems it has been forgotten for a while, so I'm trying to shake it a little. Hopefully we'll get some answer soon. But, if worst case scenario (wontfix, or ETA too late for 1.5), maybe we should think about a temporary solution for the use case we have right now, this is, we are unable to append, and we only can write the file after all the exporting process is done, so cancelling the flow will let us with 0 contacts exported. So I'm asking Ayman if this is acceptable from an UX point of view (nonetheless, we already have a spinner instead of a progress bar for non determinative processes), or we should definitely push for appending to storage before fixing this bug.

(In reply to Fernando Campo (:fcampo) from comment #18) > Ok, so I've been researching after Sergi's comment 16, and ended up on bug > 855952, that deals with appending on storage files. It's an old bug, and it > seems it has been forgotten for a while, so I'm trying to shake it a little. > Hopefully we'll get some answer soon. > > But, if worst case scenario (wontfix, or ETA too late for 1.5), maybe we > should think about a temporary solution for the use case we have right now, > this is, we are unable to append, and we only can write the file after all > the exporting process is done, so cancelling the flow will let us with 0 > contacts exported. > > So I'm asking Ayman if this is acceptable from an UX point of view > (nonetheless, we already have a spinner instead of a progress bar for non > determinative processes), or we should definitely push for appending to > storage before fixing this bug. Hi Omega, Could you please give us the UX point of view about if this approach would be acceptable for a short term solution or we should wait till Bug 855952 is fixed?. Thanks!

ni? Contacts UX owner Carrie. :)

Clearing ni to Ayman since Carrie will take it. Thanks!

Hi guys, I'm fine with canceling the whole exporting process (0 exported) if the user taps "cancel". Actually, I think this is the correct flow. Because if we have exported 20 out of 50 contacts while the user cancels export, they can't have any idea about which 20 contacts have been exported already. So I'm fine with this temporary solution, but can we adopt it for SIM card export as well? In this way, the behavior will be consistent no matter it's for SIM card or SD card. Thanks!

Hi Jose, would you mind reviewing the patch? As previously mentioned, the current solution will behave as follows: * under BT and SD Card scenarios the user will cancel the full exporting process (till Bug 855952 is fixed) * in case of SIM card scenario, the exporting process will stop at the time of selecting cancel Regards

Comment on attachment 8420886 [details] patch v1.0 it looks good but we need to refine a couple of details I left on GH. Talk to me tomorrow thanks

Comment on attachment 8420886 [details] patch v1.0 please land once Travis is green thanks!

Master: 7f387cbcbe3c9bbfbff8410318c575d9b6cabb65

Related with this: https://bugzilla.mozilla.org/show_bug.cgi?id=1013937

(In reply to Loli from comment #27) > Related with this: > https://bugzilla.mozilla.org/show_bug.cgi?id=1013937 With this new development has broken the flow.

Verified and working Hamachi 2.0 Gecko: 785d39a Gaia: 7f258db