1123169 - [email/UI][FFOS7715 v2.1] vscroll/header_cursor/message_list bug resulting in snippets/updates ending up on wrong messages

Status: RESOLVED WONTFIX

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

Description

[ffos_st]

Description:
Inbox screen, there is no theme mail refresh display theme

Device：
SPRD 7715ea

Build Identifier:
20150116105540

Steps to Reproduce:
1)Login sina 163 mailboxes or mailbox, log on to the test machine account sent a message that contains themes
2) refresh the inbox

Actual Result: 
After receiving a new message, refresh the inbox, Show themed message before after the refresh themed shows no theme normal display

Expected Result:
shows the theme normal display

Repro frequency:
1/10,10%

Comment 1

[ffos_st]

If you do not have to refresh the theme on the web page will be no theme. It is doubtful whether there is a problem of data transmission server, because the client get into the theme is empty

Comment 2

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

Can you provide a logcat (https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo) for the case that reproduces?  And ideally a screenshot of when the problem happens and a screenshot of when the problem doesn't happen?

Based on the mention of "themes", I would expect this to be an HTML sanitizer issue where it's removing styling, but that would happen 100% of the time, so I think I'm not understanding the problem and need more information.  Thanks!

Comment 3

[ffos_st]

Attachment: 问题截图1.png

Please see the attached picture, the left is the former refresh right after the refresh. After refreshing the display no subject

Comment 4

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

So this looks like something I saw happen once when reproducing another account.  One other thing I noticed was that the UIDs being issued by the coremail server were fairly large; like at least in the millions.  It's conceivable some type of comparison operation or string manipulation is having trouble with this, although they really shouldn't...

More investigation needed... needinfo-ing me.

Comment 5

[ffos_st]

I do not understand what you're saying, I suspect that the transmission of the data server in question, did not display the subject later lead to refresh

Comment 6

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

I was just thinking out loud; this mainly just needs more investigation with the IMAP connection logged.  Since bug 1116694 is being treated as a blocker and is also a coremail/163.com bug, this investigation will happen as part of fixing that bug.

Comment 7

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

With this patch applied to aid in debugging:
=== patch ===
diff --git a/apps/email/js/cards/message_list.js b/apps/email/js/cards/message_list.js
index d7cbbe2..5b5837f 100644
--- a/apps/email/js/cards/message_list.js
+++ b/apps/email/js/cards/message_list.js
@@ -227,6 +227,7 @@ return [
       // display in the DOM.
       if (this.mode === 'nonsearch') {
         this.vScroll.bindData = (function bindNonSearch(model, node) {
+console.warn('binding msg', model.id, 'to node', node.dataset.index);
           model.element = node;
           node.message = model;
           this.updateMessageDom(true, model);
@@ -1284,6 +1285,7 @@ return [
     },
 
     onMessagesChange: function(message, index) {
+console.log('change:', message.id, 'node index', message.element.dataset.index, 'alleged index', index);
       this.updateMessageDom(false, message);
 
       // Since the DOM change, cache may need to change.
======

And creating a fresh account, I witness this bug happen and produce the following interesting log excerpts.  In this case I'm using a 163.com IMAP account with only 3 messages in the folder, but I seriously doubt this is 163.com specific.  

=== excerpts ===
WLOG: Sync Completed! null days 3 messages synced
WLOG: folder message count 3 dbCount 3 syncedThrough 631123200000 oldest known 1421732433000
WAR: binding msg 4/0/2 to node 0
WAR: binding msg 4/0/1 to node 1
WAR: binding msg 4/0/0 to node 2
WAR: binding msg 4/0/0 to node 0
WAR: binding msg 4/0/1 to node 0
WAR: binding msg 4/0/2 to node 0
WLOG: [slog] mailslice:mutex-released {"folderId":"4/0"}
LOG: message_list complete: 3 items of 3 alleged known headers. canGrow: false
LOG: htmlCache.save: 14447 in 8 segments, lang dir: ltr
WLOG: queueOp 4 downloadBodies pre-queues: local: 0 server: 0
WLOG: runOp(do: {"type":"downloadBodies"
LOG: change: 4/0/0 node index 0 alleged index 2
LOG: change: 4/0/1 node index 0 alleged index 1
LOG: change: 4/0/2 node index 0 alleged index 0
WLOG: runOp_end(do: {"type":"downloadBodies"

======

It seems pretty clear that one of the callers of bindData has gone crazy.  Handing off to :jrburke for now.

Comment 8

[James Burke [:jrburke]]

I am having a hard time reproducing this. I did see something briefly last week, where a snippet for one message went to the snippet area of an incorrect item, but I did not have enough logging in place to trace how I did that, then could not get it to happen again.

This week, when updating to both latest v2.1 and master, I cannot seem to reproduce the original bug or excessive updateDataBind calls.

I tried with a 163.com account as well as an activesync account, which both had three messages in the folder I was viewing.

With expanded logging, I see the onMessagesChange type of console message twice for each message, but it makes sense: one comes from the initial setData which calls renderCurrentPosition. The other comes from updateDataBind as part of messages_splice in message_list. This does not seem unusual: we do the setData one in case no other slice events come in, and the slice splice one happens when getting info/updates from the backend.

The weirdness I saw last week was using a 163.com account, perhaps some of the recent backend changes that landed to fix some things with coremail servers had an effect?

I am at a loss though to figure it out further. If someone has a specific steps to try to trigger it, or an account that seems to trigger it, I am willing to look further. Otherwise, I suggest trying to retest with latest code to see if it still reproduces.

Comment 9

[BMO Automation]

Firefox OS is not being worked on