Closed Bug 910182 Opened 11 years ago Closed 10 years ago

[CONTACTS] Export functionality: add missing cancel export for any type of export

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v1.4 affected, b2g-v2.0 fixed)

VERIFIED FIXED
2.0 S2 (23may)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- fixed

People

(Reporter: b.paloma, Assigned: mai)

References

Details

(Whiteboard: [caf priority: p2][CR 673068][priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail)

Attachments

(2 files)

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
blocking-b2g: --- → koi?
Whiteboard: [u=commsapps-user c=contacts p=0]
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!
Summary: [CONTACTS] There isn't a cancel button when tapping on 'Export' in the Export Contacts screen. → [CONTACTS] Export functionality: add missing cancel export for any type of export
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
Flags: needinfo?(francisco.jordano)
Whiteboard: [u=commsapps-user c=contacts p=0] → [u=commsapps-user c=contacts p=0][comms-triaged]
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 ;)
Flags: needinfo?(francisco.jordano)
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.
Blocks: 887776
Blocks: 915641
Blocks: 915649
triage: not a blocker for v1.2 but 1.3? to keep in radar for 1.3
blocking-b2g: koi? → 1.3?
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] → [u=commsapps-user c=contacts p=0][comms-triaged] burirun2
triage: add to backlog bug 891754
blocking-b2g: 1.3? → ---
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] burirun2 → [u=commsapps-user c=contacts p=0][comms-triaged] burirun2,burirun3
blocking-b2g: --- → madai?
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] burirun2,burirun3 → [u=commsapps-user c=contacts p=0][comms-triaged] permafail
blocking-b2g: madai? → 1.4?
from triage point of view, this could be a target. Wilfred ?
Flags: needinfo?(wmathanaraj)
We set it as a 1.4 target
Blocks: 1.4-comms-targeted
No longer blocks: comms_backlog
Flags: needinfo?(wmathanaraj)
blocking-b2g: 1.4? → -
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] permafail → [u=commsapps-user c=contacts p=0][comms-triaged] permafail burirun1.3-3
Adding to backlog for tracking
blocking-b2g: - → backlog
Assignee: nobody → fernando.campo
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
Depends on: 979948
(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!
Depends on: 957051
No longer depends on: 979948
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] permafail burirun1.3-3 → [u=commsapps-user c=contacts p=0][comms-triaged] permafail
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.
Flags: needinfo?(sergi.mansilla)
Flags: needinfo?(aymanmaat)
(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?
QA Contact: lolimartinezcr
blocking-b2g: backlog → 1.5?
Flags: needinfo?(cawang)
added to 1.5 targetted
blocking-b2g: 1.5? → backlog
Depends on: 855952
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.
Flags: needinfo?(sergi.mansilla)
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged] permafail → [u=commsapps-user c=contacts p=0][comms-triaged], permafail
QA Contact: lolimartinezcr
(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!
Flags: needinfo?(ofeng)
ni? Contacts UX owner Carrie. :)
Flags: needinfo?(ofeng)
Clearing ni to Ayman since Carrie will take it. Thanks!
Flags: needinfo?(aymanmaat)
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!
Flags: needinfo?(cawang)
Whiteboard: [u=commsapps-user c=contacts p=0][comms-triaged], permafail → [priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail
No longer blocks: 1.4-comms-targeted
Assignee: fernando.campo → mri
Attached file patch v1.0
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
Attachment #8420886 - Flags: review?(jmcf)
QA Contact: lolimartinezcr
Comment on attachment 8420886 [details] [review]
patch v1.0

it looks good but we need to refine a couple of details I left on GH. Talk to me tomorrow

thanks
Attachment #8420886 - Flags: review?(jmcf)
Comment on attachment 8420886 [details] [review]
patch v1.0

please land once Travis is green

thanks!
Attachment #8420886 - Flags: review+
Master: 7f387cbcbe3c9bbfbff8410318c575d9b6cabb65
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
feature-b2g: --- → 2.0
Target Milestone: --- → 2.0 S2 (23may)
(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
Status: RESOLVED → VERIFIED
Whiteboard: [priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail → [CR 673068][priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail
Whiteboard: [CR 673068][priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail → [caf priority: p2][CR 673068][priority][u=commsapps-user c=contacts p=0][comms-triaged], permafail
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: