1063310 - [email] When sending multiple attachments, all but the first are sent as zero-byte attachments.

Status: VERIFIED FIXED

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

Description

[Shing Lyu [:shinglyu]]

Attachment: Screenshot: the photo's size is 0K

Build Information
Device: Flame
Gaia      a47ecb6368c015dd72148acde26413fd90ba3136
Gecko     757931d0149e
BuildID   20140904000203
Version   34.0

Description
  If one cancel a "Attach by camera" action, the previously attached photo (also by camera) will become 0K and fail to be opend.

Steps to Reproduce
* Open the E-mail app.
* Compose a new mail. 
* Attach a video.
* Click the "paper clip" icon to attach.
* Select "Camera".
* Take a picture, and click "Select".
* Click the "paper clip" icon and select "Camera" again.
* Don't take any picture, click the "x" button to cancel.
* Send the mail to yourself.
* Open the received email, the photo is corrupted (shows 0K)

Expected Results
  The photo took in the first attampt is sent with the email.

Actual Results
  The photo is a corrputed one, it's size is 0KB.

Other Notes


Reproduction Frequency: always

Comment 1

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

I'm unable to reproduce with aurora/2.1 flame just now with a few different permutations, build 20140907160203.  Assuming you can still reproduce this on a recent build, please provide a logcat captured over the time period of the reproduction.  See https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for info on how to provide a useful logcat.

Please also indicate:
- whether the camera app was open or not when you triggered the activity from the email app.  (ex: was it visible in the task switcher before you started the email app).
- what rotation you took the picture with

I reviewed the camera app's source and it seems like its use of postResult/postError is probably correct, so it's possible this is a different memory-backed Blob problem a la bug 1063658 (which is why whether the camera app process is open matters).  The logcat will absolutely indicate what the problem is.  I'd suspect that if the video matters at all to the repro it would be because it could cause the job/op queue to get backlogged enough so that we completely miss the chance to access any memory-backed Blob.

Comment 2

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 3

[Shing Lyu [:shinglyu]]

Attachment: logcat output during the reproduction

I have attached the logcat output. You can grep "compose: attach" to see three attachement activities. The first one is a video in the gallery. The second is taking a picture using the camera app. The third is the canceled camera attempt.

As for your question:
 - No, the camera app was not open. I rebooted the phone before the test.
 - I took pictures in vertical position.

Thank you.

Comment 4

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

[Blocking Requested - why for this release]: Minor regression in IMAP parser or (symmetrically) SMTP composition.  Should be easily addressed, etc.

Thanks very much for the log!  The involvement of cancelling a camera attachment is unrelated to the problem.  The IMAP parser seems unhappy.  This is almost certainly a regression from bug 885110.  The first excerpt, which is repeated in varying forms:

I/Gecko   ( 1837): WLOG: runOp(do: {"type":"download","longtermId":"0/1T","lifecycle":"do","localStatus":"done","serverStatus":"doing","tryCount":0,
"humanOp":"download","messageSuid":"0/0/10","me)
I/Gecko   ( 1837): WERR: browserbox IMAP error parsing imap response: Error: Unexpected end of input at position 32
I/Gecko   ( 1837): n.prototype.getAttributes/n<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1488:1
I/Gecko   ( 1837): n.prototype.getAttributes/n</<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1523:17
I/Gecko   ( 1837): n.prototype.getAttributes/n<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1522:13
I/Gecko   ( 1837): n.prototype.getAttributes@app://email.gaiamobile.org/js/ext/composite/configurator.js:1526:16
I/Gecko   ( 1837): t.prototype.getAttributes@app://email.gaiamobile.org/js/ext/composite/configurator.js:1483:16
I/Gecko   ( 1837): @app://email.gaiamobile.org/js/ext/composite/configurator.js:1702:24
I/Gecko   ( 1837): r.prototype._processServerQueue@app://email.gaiamobile.org/js/ext/composite/configurator.js:1828:22
I/Gecko   ( 1837): r.prototype._addToServerQueue@app://email.gaiamobile.org/js/ext/composite/configurator.js:1819:9
I/Gecko   ( 1837): r.prototype._onData@app://email.gaiamobile.org/js/ext/composite/configurator.js:1811:20
I/Gecko   ( 1837): t/a</<@app://email.gaiamobile.org/js/ext/worker-bootstrap.js:7985:1
I/Gecko   ( 1837): o.catchSocketExcept
I/Gecko   ( 1837): WERR: [slog] imap:normalized-error {"error":{},"errorName":"Error","errorMessage":"Unexpected end of input at position 32","errorStack":"n.prototype.getAttributes/n<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1488:1\nn.prototype.getAttributes/n</<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1523:17\nn.prototype.getAttributes/n<@app://email.gaiamobile.org/js/ext/composite/configurator.js:1522:13\nn.prototype.getAttributes@app://email.gaiamobile.org/js/ext/composite/configurator.js:1526:16\nt.prototype.getAttributes@app://email.gaiamobile.org/js/ext/composite/configurator.js:1483:16\n@app://email.gaiamobile.org/js/ext/composite/configurator.js:1702:24\nr.prototype._processServerQueue@app://email.gaiamobile.org/js/ext/composite/configurator.js:1828:22\nr.prototype._addToServerQueue@app://email.gaiamobile.org/js/ext/composite/configurator.js:1819:9\nr.prototype._onData@app://email.gaiamobile.org/js/ext/composite/configurator.js:1811:20\nt/a</<@app://email.gaiamobile.org/js/e
I/Gecko   ( 1837): WERR: imap:onerror {"error":"unknown","host":"imap.googlemail.com","port":"993"}

Comment 5

[Pi Wei Cheng [:piwei] (inactive)]

Issue is reproducible using the original STR on Flame 2.1, Flame 2.2, and Open C 2.1.

Observed behavior: Following the STR, the email sent contains a 0 KB image. Repro rate: 4/4

Device: Flame 2.1
BuildID: 20140909121851
Gaia: d6932e393b53ad7393a2fa78bd80db87bdfea616
Gecko: 420d3d42be19
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Device: Flame 2.2 Master
BuildID: 20140909070054
Gaia: 4abb193ddae0f9780ad12ffe5e31772feee3926a
Gecko: 4d1793da0b96
Version: 35.0a1 (2.2 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Open_C 2.1
BuildID: 20140909121851
Gaia: d6932e393b53ad7393a2fa78bd80db87bdfea616
Gecko: 420d3d42be19
Version: 34.0a2 (2.1)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

------------

Issue is NOT reproducible on Flame 2.0.

Observed behavior: Following STR, the email sent correctly contains the image taken. Bug repro rate: 0/3.

Device: Flame 2.0
BuildID: 20140909105257
Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab
Gecko: 96a9bd2e7840
Version: 32.0 (2.0)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 6

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

No need to hunt down a range.  It's bug 885110.  The code throwing an exception didn't exist before that bug and we haven't made any other changes.  So it's that bug.

Comment 7

[Candice Serran (:cserran)]

blocker justification: regression to core functionality (downloading attachments)

Comment 8

[Marcus Cavanaugh [:mcav]]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/339

This was caused by incorrect math on my end, resulting in (attachments > 1) being sent as zero-byte attachments.

Previously, test_compose_blobs only verified that one attachment succeeded; I've updated the test to verify that multiple attachments succeed properly (and fail without this patch).

Comment 9

[Marcus Cavanaugh [:mcav]]

master: https://github.com/mozilla-b2g/gaia/commit/40436b1d01921e9ac80d6afe227ea5c845a2b137

Comment 10

[Marcus Cavanaugh [:mcav]]

Comment on attachment 8488110 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/339

Requesting approval for 2.1: https://github.com/mozilla-b2g/gaia/commit/40436b1d01921e9ac80d6afe227ea5c845a2b137 -- this is a regression that causes attachments beyond the first to not be sent properly.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): n/a
[User impact] if declined: attachments would not be sent correctly
[Testing completed]: manual + automated
[Risk to taking this patch] (and alternatives if risky): none
[String changes made]: no

Comment 11

[[:fabrice] Fabrice Desré]

(In reply to Marcus Cavanaugh [:mcav] <[e-mail]> from comment #10)
> Comment on attachment 8488110 [details] [review]
> Link to Github pull-request:
> https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/339
> 
> Requesting approval for 2.1:
> https://github.com/mozilla-b2g/gaia/commit/
> 40436b1d01921e9ac80d6afe227ea5c845a2b137 -- this is a regression that causes
> attachments beyond the first to not be sent properly.
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #): n/a
> [User impact] if declined: attachments would not be sent correctly
> [Testing completed]: manual + automated
> [Risk to taking this patch] (and alternatives if risky): none
> [String changes made]: no

I don't see any new or updated tests in what landed on master. Where are they?

Comment 12

[Marcus Cavanaugh [:mcav]]

They're in the pull request attached to this bug[1]; they're compiled into the email backend, which lives at http://github.com/mozilla-b2g/gaia-email-libs-and-more. Those tests don't actually get compiled into the Gaia tree, to prevent code bloat.

[1]: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/339/files

Comment 13

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/2f15cebae1c4cff7e985899d692903820cd2dba1

Comment 14

[Edward Chen[:edchen]]

[Environment]
Gaia-Rev        b3f9b97d16a1ab55f80239d63c1a85c3da3d39ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-aurora/rev/2c6e3261c47b
Build ID        20140921160204
Version         34.0a2
Device Name     flame
FW-Release      4.3
FW-Incremental  110
FW-Date         Fri Jun 27 15:57:58 CST 2014
Bootloader      L1TC00011230

[Result]
PASS

Comment 15

[Duane Dixon [:ddixon]]

Issue is verified fixed in Flame 2.2, 2.1 (Full Flash, Nightly). 

Actual Results: Attached files (pictures, videos) in emails sent from the Email App are labelled with the correct file sizes. 
 
Device: Flame Master
Build ID: 20141013040202
Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f
Gecko: f547cf19d104
Version: 35.0a1 (Master)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame 2.1
Build ID: 20141013001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Version: 34.0a2 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0