865619 - [Email] Image attachment with file name in Korean, not shown properly and also it is downloading continuously

Status: RESOLVED WORKSFORME

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

Description

[Leo]

1. Title : Image attachment with file name in Korean, not shown properly and also it is downloading continuously.
2. Precondition : Send an email with an image attachment file name with Korean
3. Tester's Action :launch Email -> Load Inbox -> Check the email that has Image attachment that was sent from another client-> See the attachment name -> not displayed properly -> Click on download
4. Detailed Symptom (ENG.) :
It loads the attachment continuously
5. Expected : Email attachment name should be shown properly and it should download properly and show option to view.
6.Reproducibility: Y
	1)Frequency Rate : 100%
7.Gaia Master/v1-train : Reproduced
8.Gaia Revision: 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c
9.Personal email id:  [e-mail]

Comment 1

[psingapati]

Attachment: Logcat logs

Logs attached for Image attachment with Korean file name

Comment 2

[psingapati]

Hi Andrew,
Please let me know , if you need any test image with korean file name.
Thanks.

Comment 3

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

There seem to be 2 problems in here:

The MIME word =?EUC-KR?B?waa48SC++LTCIMO3us4gxsTAzyAwMDQxOS5qcGc=?= is not being decoded.  I'm extracting this from the logcat where we are actually trying to save a file with that name, so it's possible it's actually something more complex that's causing us to fail to decode the mime-word.

We are trying to save a filename with a '?' in it which is not supported by the sdcard's file-system.  We should run a sanitization pass on the filename to nuke/fold illegal characters and limit the length of the file-name.


Could you provide the source of the message, at least the bit where the attachment name is so I can see how the attachment name is encoded?  Thanks!

Comment 4

[psingapati]

I have forwarded the email to [e-mail]
Please check
Thanks.

Comment 5

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

The message got re-encoded when you forwarded it inline; I no longer see any indication of a euc-kr encoding.  Please either provide the source of the message as an attachment to the bug (by using "File" "Save As..." then saving the .eml file and attaching it to the bug), or re-forward the message using the "Message" menu's "Forward as..." "Attachment" options.

Comment 6

[psingapati]

Attachment: Test image .eml file attached

Test image .eml file is attached as per above comment.

Comment 7

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

I think you attached the wrong e-mail.  The attached e-mail works fine-ish in the e-mail client[1] and also does not feature EUC-KR encoding, and features a different attachment filename than the e-mail you had forwarded me (which matches the filename from the logcat log: "제목 없는 첨부 파일 00419.jpg").

Can you find that e-mail message and attach it to the bug instead?  Thanks!


1: It downloaded over 2g fine (but sloooowly), and saved to disk.  However, the spinner did not go away correctly on its own.  This may be related to a failure of our logcat logging to properly display the filename of the file we saved to disk.  The log entry looked like:
I/Gecko   ( 1655): WLOG: saved attachment to sdcard \
with corrupt ANSI afterwards.  So there may be some encoding issue with our dump() impl on android in workers and it's conceivable that could have thrown an exception which could be involved with our failure to update the UI.  Although this came out okay when we tried to open the image:
I/GeckoDump( 1655): LOG: trying to open sdcard,한글1.JPG type: image/jpeg
but that is GeckoDump rather than Gecko, so it may just be doing the right encoding path.

Upon re-entering the message display, however, the attachment was properly shown as downloaded and if I hit the view button it displayed fine in the gallery, suggesting no fundamental problem.

Comment 8

[psingapati]

I think when I am forwarding email it might be coming as inline image or so. Not able to figure out what exactly was happened.
 I sent you mail, with account details.
Please check with that account.

Thanks

Comment 9

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

I used the provided credentials to use the gmail UI to try and find a mail with a euc-kr encoding, but couldn't find any.  I connected a b2g18 unagi running gaia/master (which should be the same as v1-train) e-mail to the account and couldn't find any e-mail that choked during message display, attachment downloading, or attachment display.

For thoroughness I also copied the euc-kr mime-word out of the provided logcat (was that a different account?) and added it to our unit tests.  The unit tests were fine, but I did notice we aren't fully supporting rfc 2231 encoding so I logged Bug 867909 and provided unit tests and a fix for that.  But that bug should not affect what was reported here on the logcat since that was showing us a MIME word that did not decode versus the weird rfc 2231 encoding.

If you are still able to reproduce, please attempt to reproduce on both v1-train and master and provide result and the e-mail in question.

Comment 10

[psingapati]

Hi 
This issue is not reproducible now with the Gaia Version 8560da0c79b293cb421e33dc9b99f2afc12b6fdf

File name displayed properly in Korean.

Thanks