845656 - [Email] Draft Email is opened to message view and shows BLACK screen on touching back button.

Status: RESOLVED WORKSFORME

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

Description

[Leo]

1. Title : unable to view the Draft folder messages, No response when we touch on draft folder messages
2. Precondition : Email should be working
3. Tester's Action : Email - Menu - Drafts
4. Detailed Symptom (ENG.) :When draft messages are loaded touch on any message. No response not able to view the message.
[After some time some of the messages are opened, then on back button BLACK screen displayed, Have to kill the Email App to use further.]
5. Expected : Should be able to view the draft message.
6.Reproducibility: Y
1)Frequency Rate : 100%
7.Gaia Revision: 6916e18d1f72936e892543cf4a104a7d457f78ad

Comment 1

[Leo]

Since Drafts are not supported.
The issue observed should not occur.
"After some time some of the messages are opened, then on back button BLACK screen displayed, Have to kill the Email App to use further".
so we have to fix this issue.

Thanks.

Comment 2

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

If we are showing a message in the message list, then we already have the body.  This suggests one or more of a few possibilities:
- Touch interaction problems with the build/hardware.  This happened with the Inari devices, for example.
- The draft message body is very large/complicated and it takes us a while to retrieve or load the message body.
- We were synchronizing either the current (drafts) folder, or were still synchronizing another folder in the background (bug/serious bug that will be fixed by landing bug 822882) which was causing us to be very busy and unresponsive, slowing down the load.

Since we haven't removed our dump() logging yet, a logcat would be invaluable.  Also, knowing the type of account in use is also very important.  Please see: https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo

Comment 3

[Leo]

Hi Andrew,
we are using Gmail account.
Draft has at least 20 messages. While loading drafts , click and try to open message. There is no response, if we keep touching on any of the message, suddenly any of the message is opened and shows message view card. on clicking back button, screen goes BLACK.
Note: Issue is not always reproducible , if Drafts has very few messages.
We will soon attach logs.

Comment 4

[Leo]

Attachment: Logs for the Drafts Black Screen issue

Hi Andrew,

Please find the attached logs for the Drafts Black screen issue. Please check.

We would like to know an information for the Drafts Messages scenario.

1. Please let us know the scenario for Drafts message, should it go to composer card or Message reader card.

Thanks,
Leo.

Comment 5

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

Thanks for the log!  The incriminating line that occurs a number of times is:
I/GeckoDump(  601): [31mERR: Problem handling message type: gotBody TypeError: body is null

This is telling us that when you go to click on the message, we are asking the back-end for the body that goes with the message header.  Unfortunately, the body is not there.

This suggests that that one of the following happened:
A) a failure during synchronization of the drafts folder.
B) the message got in the drafts folder via a move operation from within the e-mail app that failed; there exists or used to exist a test case in "moztrap" that encouraged trying to move messages to the drafts folder.  If you were trying this out, that might have happened.

If the problem is case 'A', then what we really want is a log from when that message gets synchronized.  Because we won't re-synchronize a message we have already synchronized, you need to delete the account, re-add it, then make sure to be logging when you enter the 'drafts' folder so we can capture any error message.

Comment 6

[Leo]

Attachment: Logs While loading Drafts freshly

Hi Andrew,

Please find the attached logs when the drafts messages are loaded for the first time.
Please check and let me know if you need any more information.

Thanks
Leo

Comment 7

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

Thank you for the revised log.  It appears that the message in question is a text/html part that is either doing something very bad to our HTML sanitizer or our body part discovery logic.

Would it be possible for you to provide a copy of one of the bad draft messages?  Ideally, the message could be provided intact by accessing the e-mail account with Mozilla Thunderbird and choosing the "Message" menu's "Forward As..." "Attachment" option to e-mail me; you can use this account ([e-mail]) or my MoCo account ([e-mail]).  Also, please indicate if it's okay for me to attach the contents of the message here.

According to the logs, it looks like the 2 newest drafts are fine, but the 6 messages that precede those all share the problem.  So any of those 6 should be fine.

Comment 8

[Leo]

Hi Andrew,

When I see the drafts in the account which I use, First 2 messages are having "To:" fields, subject and body of the message.
But the next 6 email drafts messages are having only "To:" fields and one email with subject as (.) When I select each of those messages they are not opening most of the times. Then, if we select the message other than these 6 (first two) and click on back button BLACK (sometimes WHITE today observed) screen appears.

Please let me know, if you still need those messages.
Thanks
Leo.

Comment 9

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

Leo, yes, having the source of one of those messages would be very valuable.  If you could forward one of the bad messages as described in comment 7 using Thunderbird (or a similar mechanism from another e-mail client), that would still be very useful.

We recently changed the background color of the app from black to white on gaia/master, so it's not surprising that you would see a white background when things break on gaia/master now.  (But on v1-train you would still see black.)

Comment 10

[Leo]

Hi Andrew,

I sent you two emails among those 6 using Thunderbird email client. One has just To field and another has just subject as (.).
Please do not attach the contents here. 

If you need any more information, please let me know.

Thanks,
Leo

Comment 11

[Leo]

In addition to Comment10, 
I forwarded you mails to [e-mail] id.

Thanks,
Leo

Comment 12

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

The content of the messages (which were requested not to be shared) is:

- 1 text/plain message with effectively no body.  There is a newline after the headers delimiting the end of the headers and then no body.  This can be reproduced by taking a text/plain .eml and truncating the message in this fashion.

- 1 multipart/alternative message which is a forward of that message or a similar message.  1st sub-part is text/plain with an inline-forwarded mesage consisting of some blank lines, the inline forward header, more blank lines.  2nd sub-part is text/html.  Contents inside the body are a <br> followed by a standard <div class="moz-forward-container"> with <table> style forward header.

Comment 13

[Alex Keybl [:akeybl]]

(In reply to Andrew Sutherland (:asuth) from comment #12)
> The content of the messages (which were requested not to be shared) is:
> 
> - 1 text/plain message with effectively no body.  There is a newline after
> the headers delimiting the end of the headers and then no body.  This can be
> reproduced by taking a text/plain .eml and truncating the message in this
> fashion.
> 
> - 1 multipart/alternative message which is a forward of that message or a
> similar message.  1st sub-part is text/plain with an inline-forwarded mesage
> consisting of some blank lines, the inline forward header, more blank lines.
> 2nd sub-part is text/html.  Contents inside the body are a <br> followed by
> a standard <div class="moz-forward-container"> with <table> style forward
> header.

Can we harden against this case in any way, to prevent "After some time some of the messages are opened, then on back button BLACK screen displayed, Have to kill the Email App to use further"?

Comment 14

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

(In reply to Alex Keybl [:akeybl] from comment #13)
> Can we harden against this case in any way, to prevent "After some time some
> of the messages are opened, then on back button BLACK screen displayed, Have
> to kill the Email App to use further"?

The code is now hardened as of the recently landed bug 808716, currently only on gaia/master, but tef? is requested/required.

The root parse failures are also likely to be addressed in bug 814257 (the worker thread bug) since I am expanding our test coverage there for confidence that we're not regressing things massively.

Comment 15

[psingapati]

This issue is reproduced in Inbox folder also, When a message is not able to open for some time. Then try to open another message and on back button white screen is displayed.

Comment 16

[psingapati]

Continuing Comment 15,

Please let me know if you want the message body.

Thanks
Praveen

Comment 17

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

(In reply to psingapati from comment #16)
> Please let me know if you want the message body.

If the problem reproduces on gaia/master, then yes, please.

Comment 18

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

We believe this bug may be resolved by recent changes that have landed on all branches of the e-mail app.  Please re-test.

Comment 19

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

(milestone was removed accidentally due to firefox and bugzilla doing bad things when refreshing the page)

Comment 20

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

Per comment 18, we believe we have hardened against this failure on multiple fronts and the underlying processing logic should no longer share whatever failure was triggering the body processing failure in the first case.

Comment 21

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

I am clearing leo+ because the "Daily B2G Blocking Bugs Alert" is still spamming about the existence of this bug; it seems like it doesn't understand the combination of flags in use or something like that.