845816 - [Email] No Alert to user when SD card removed or when in USB storage mode while downloading the attachment from Email

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Leo]

1. Title : No Alert to user when SD card removed while downloading the attachment from Email
2. Precondition : Email should be working
3. Tester's Action : Email - Inbox - Open a mail with attachments - start download - remove SD card.
4. Detailed Symptom (ENG.) : No information or alert to user, download icon shows continuously
5. Expected : Some information or alert should display to user.
6.Reproducibility: Y
1)Frequency Rate : 100%
7.Gaia Revision: 6916e18d1f72936e892543cf4a104a7d457f78ad

Comment 1

[Leo]

Hi Andrew,

I would like to know your opinion on this issue. This issue little similar to issue 832927. But 832927 is Removal of SD Card while viewing the Image.
This issue related to removal of SD Card while downloading the attachment.
Do you think that this also can be addressed or resolved by fixing issue 832927?

As per my understanding 
we are downloading the attachment at "onDownloadAttachmentClick" of "message-cards.js"  with the method "attachment.download". But in the callback function we are returning if there is no file
      if (!attachment._file)
        return;
It means that we continuously wait till the file is downloaded. To check the SD Card removal for both Downloading case and viewing case, its better to check at "getAttachmentBlob" method. To do this I have to remove the attachment file check at "downloaded" callback of "attachment.download". 

Please suggest me the best possible way to fix these issues.

Thanks,
Leo

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

(In reply to leo.bugzilla.gaia from comment #1)
> As per my understanding 
> we are downloading the attachment at "onDownloadAttachmentClick" of
> "message-cards.js"  with the method "attachment.download". But in the
> callback function we are returning if there is no file
>       if (!attachment._file)
>         return;
> It means that we continuously wait till the file is downloaded. To check the
> SD Card removal for both Downloading case and viewing case, its better to
> check at "getAttachmentBlob" method. To do this I have to remove the
> attachment file check at "downloaded" callback of "attachment.download". 

The method is called at most one time.  The (!attachment._file) check exists because we call the download callback when the download either completes or fails.  If !!attachment._file, then the download was successful.  If !attachment._file, it failed.  We probably should have a comment in front of that check, documentation on the downloadAttachments methods, and more explicit propagation of errors so we could maybe avoid that check.

Since the devicestorage API is capable of generating change events, one possibility is to do something like this:
- Before initiating the download, check to make sure the devicestorage in question is available.  Immediately fail if it's not available.
- Keep the reference to the devicestorage around while downloading.  Register a change listener so that we will receive an 'unavailable' event if the SD card is removed.
- If we receive an 'unavailable' event, abort the download, generating an error code that we relay to the front-end, like 'sdcardremoved'.  When the UI receives this, it could display an error message then like 'download aborted because the SD card was removed.'

The changes would happen in the gaia-email-libs-and-more repo under data/lib/mailapi/jobmixins.js in the do_download method.  data/lib/mailapi/imap/folder.js and data/lib/mailapi/activesync/folder.js would also want their downloadMessageAttachments methods to now return a function that could be used to cancel the download process.  Since the folder connection changes would be more involved, it might suffice to currently have do_download just end up ignoring the return value of the download process if we declare that we have aborted the download.

Comment 3

[Alex Keybl [:akeybl]]

If this bug cannot be recovered from by reinserting the SD card and killing the app, we may block on that behavior (please renominate). But we do not feel this is a blocker if it doesn't cause data loss.

Comment 4

[Leo]

Hi Alex, 

This is not recovered after re inserting the SD card, we have to kill the application to reuse.
Will post more details.

Thanks

Comment 5

[Yeojin Chung [:YeojinC]]

This issue also occurs in Buri 1.4.

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140514000204
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: 7788969f70b0
Version: 30.0
Firmware Version: v1.2-device.cfg
----------------------------------------------

This issue also occurs in Flame 1.4.

1.4F Environmental Variables:
Device: Open_C 1.4F MOZ
BuildID: 20140514000204
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: 7788969f70b0
Version: 30.0
Firmware Version: v10F-3

Comment 6

[James Burke [:jrburke]]

Note also, as found in bug 1027001, download can fail if the phone is in "USB storage" mode, accomplished by doing this:

(1) You have to plug in usb line to your phone
(2) Turn on "USB storage" (Settings -> USB storage)

An alert to the user that downloading will not work while in USB storage mode should also be provided as part of this fix, since the download pathway does get an error for this case, it is just not surfaced to the user yet.

Comment 9

[BMO Automation]

Firefox OS is not being worked on