Open Bug 533499 Opened 10 years ago Updated 8 months ago

When quickly cycling through messages with [, ], (go forward, and go back in history) message preview pane can be stale (race condition)

Categories

(Thunderbird :: Folder and Message Lists, defect)

x86
All
defect
Not set

Tracking

(Not tracked)

People

(Reporter: benjamin.lerner, Unassigned, NeedInfo)

References

(Blocks 3 open bugs)

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: TB 3.0 rc2

Using the [ and ] keys, it's possible to cycle through messages faster than TB can update the message preview pane.  I've seen two ways the message preview pane can become stale; I don't know if they're separate bugs or not:

* If one of those messages has attachments, and you stop cycling just 1 message past that attachment, you might wind up with the preview of the new message but the attachments of the old (in #attachmentList).  Slowly going back one ([) and then forward (]) will reset the message pane.

* Even if the message doesn't have attachments, and you cycle quickly enough, it's possible that the message header (#collapsedHeaderView or #expandedHeaderView) will show the header of the current message, but the body of a previous one.  Slowly going back one ([) and then forward (]) will reset the message pane.

Reproducible: Sometimes

Steps to Reproduce:
1. Have a folder with many messages, and browse through them to build up a long back/forward history list.  Have at least one message with attachments.
2. Hold down the [ key to cycle backwards in the history, stopping very very briefly on the message with the attachment, and...
3. press ] to cycle forward.
4. Slowly press [ and then ].

Actual Results:  
3. You may wind up with stale attachment and/or header information.
4. You will see the corrected message header.

Expected Results:  
The message header, body, and attachments should be loaded atomically, and not be susceptible to inter-message corruption.

The [ and ] keys are great timesavers for me -- I typically will chase down some long thread in a newsgroup folder or a mailing list, then zoom back to my inbox.  The [ key is the fastest keyboard way to do that (just one keypress!)
Ben :

Any error messages in Tools -> Error console when Thunderbird get confused ?

Can you observe the issue while running Thunderbird in -safe-mode (http://kb.mozillazine.org/Safe_mode) ?

Can you share with us the hardware on which you are experiencing this issue ?
Keywords: perf
No, I didn't notice any error messages in the console that I could attribute to this.  It's tricky to reproduce -- the next time I get an email thread with an attachment, I'll retry in safe mode and see.

I've seen this behavior in TB2 on a Dell XP laptop, and in TB2/3 on an XP box at school.  There's a linux box with TB3rc1 I can try this on, perhaps, and see if that reproduces it, too.

It seems to me that both this and the other bug I filed (bug 533504) are both exacerbated when using a theme such that there's more to draw per refreshing the screen...

sorry this is a bit vague.  I've seen this happen often enough, but never figured out a completely consistent repro.

Perhaps this is also related, or another staleness bug: 
1. In Inbox, have some new messages to read.  In a blog, have some new posts.  Make sure you haven't visited that blog folder yet (so that there's no current selection in that folder).
2. Using N, read through the inbox, and then say yes to go to the blog posts.
3. *Sometimes* the folder view will select the blog folder, the message list will refresh to the contents of that blog folder, *no message will be selected*, and the preview pane will be blank.  To refine that slightly further, the first blog post will have a dotted border (like it had been selected but then focus was lost, or something) rather than be actively highlighted.
4. Pressing [ then selects and displays the first unread blog post.  

There are some weird interactions going on here between navigating between folders, new (unread and just downloaded, not just marked unread) messages, and focus/selection/display.
Whiteboard: dupme
Joe, can you reproduce?
Ben, did this get worse in version 3, compared to version 2?
Yes I was able to reproduce the "wrong attachment" case.
Further, the wrongly displayed attachment is actionable (and from the wrong message.
Didn't see the wrong header/body case yet, but I wouldn't doubt it.
Tested with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2pre) Gecko/20100122 Lanikai/3.1b1pre ID:20100122032008

Just as an aside, the very rapid [/]needed to reproduce is nothing I might do in normal use.
@comment 4: thanks for the repro :) @comment 3: yes, it's worse in TB3 compared to TB2.  I never saw it in TB2; I do see it occasionally in TB3.  As I said in the initial report (and regarding comment 4), I mostly hold down [ to zoom back in my history, to "undo" a long excursion into mailing lists or other folders, and get back to my inbox.  Additionally, another advantage rapid-[ has is that it sometimes sidesteps another bug I've been having (bug 533504), and shoots "past" the null values in the history and gets me back where I want to be, even though clicking the back button itself won't work...
Ben, Joe, can you reproduce this with version 3.1?  and/or bug 527711 and/or bug 533504?

let's (finally!) add the proper names to the summary: go forward, and go back
Component: Mail Window Front End → Folder and Message Lists
QA Contact: front-end → folders-message-lists
Summary: When quickly cycling through messages with [, ], message preview pane can be stale (race condition) → When quickly cycling through messages with [, ], (go forward, and go back in history) message preview pane can be stale (race condition)
Whiteboard: dupme
(In reply to comment #6)
> Ben, Joe, can you reproduce this with version 3.1?  and/or bug 527711 and/or
> bug 533504?
Yes, I can still see it in 3.1.4, on both an older XP box (dell optiplex GX270, mentioned in comment 2) and a new Win7 laptop (dell studio 1558, replacing the laptop in comment 2).

As another data point, I'm using the Mailing List Manager extension by Shane Caraveo.  If I cycle quickly through messages, I may wind up with a message pane that is a private message to me, but for which the Mailing List Manager bar is still visible.  Again pressing [ and then ] (or vice versa) fixes things.  So maybe the problem is between displaying the message body in the preview pane, and when "decorations" (for lack of a better term, but the attachment pane, the mailing list bar, etc) get to look at the message and decide whether to show themselves?
Phenomenon of this bug was observed many times in test for bug 565852, and is still easily be observed with test case of bug 565852.
(1) IMAP folder, offline-use=off (Disk Cache or Memory Cache is used)
(2) default prefs settings related to downloading
    mail.imap.mime_parts_on_demand=true
    mail.server.default.fetch_by_chunks=true
(3) multipart/mixed with text/plain and multiple big PDF attachments.
    mail-0 : Subject=Rest Room, body=rest room, simplest text/plain mail.
             Probably held in Memory cache because very small mail. 
    mail-1 : Subject=AAA-1, body=aaa-1, attachments=PDF-1, PDF-2, PDF-3
    mail-2 : Subject=BBB-2, body=bbb-2, attachments=PDF-2, PDF-3, PDF-1
    mail-3 : Subject=CCC-2, body=ccc-2, attachments=PDF-3, PDF-1, PDF-2
    Note:
    Mails of 10MB to 20 MB was used in my test with max 70Mbps connection,
    to force long download time of PDF attachment by open of attachment,
    and to force long download time of whole mail data in offline-use=on case.
    To see phenomenon of this bug, such large PDF files are not required.
(4) Folder Properties, Repair Folder => headers are fetched
    Do "Click mail-X, wait for mail display at message pane, click mail-0"
    for X=1 to 3.
    Note: If Tb 3.1, bug 565852 occurs. "click mail-0" is to exclude
          affect by that bug upon first mail viewing.
(5) Click mail-0 => immediately shown at message pane. 
(6) Click mail-1 => (logout/select if repeated test)
                    fetch body[1] of mail-1.
    Before mail-1 is fully shown at messag pane, click mail-2. 
    => logout is probably issued. login/select/fetch body[1] of mail-2.
    Before mail-2 is fully shown at messag pane, click mail-3. 
    => logout is probably issued. login/select/fetch body[1] of mail-3.
(7) Repeat step (6) multiple times.

Phenomenon like next can be seen almost always by above test.
  when mail-1 is clicked, mail data of mail-3 is shown at message pane.
  when mail-2 is clicked, mail data of mail-1 is shown at message pane.
  when mail-3 is clicked, mail data of mail-2 is shown at message pane.
  If other mail is not clicked, mail data of previously clicked mail is shown,
  then mail data of current mail is shown at message pane after a while.
 
Because of IMAP folder of offline-use=off, fetch body[1] is always issued upon mail click(it's current design/implementation of Disk Cache use of Tb). And because there is no way to request IMAP server to cancel fetch, logout is issued in order to issue fetch body[1] for newly clicked mail. And, because logout/re-login/select/fetch body{1} takes long, time between internal steps during "mail click to mail display" becomes always long. It's trick that phenomenon of this bug can easily be observed by test case of bug 565852.

If local mail folder, or if IMAP folder of offline-use=on and mails are already sych'ed to offline-store, above execss steps/time doesn't exist.
Bug 599119 is one of causes of "longer time to show a mail than needed". According to Bug 599119, following was a workaround in some cases.   
> plugin.scan.plid.all = false

Ben Lerner(bug opener) and Joe Sabash:
Is plugin.scan.plid.all=false a workaround of your case?
(it can do nothing on "IMAP folder of offline-use=off" case.)
Is "IMAP folder of offline-use=off" or "IMAP folder of offline-use=on, but not sync'ed yet" involved in your case?

(In reply to comment #4)
> Yes I was able to reproduce the "wrong attachment" case.
> Further, the wrongly displayed attachment is actionable (and from the wrong
> message.

"Attachments in attachment pane for mail of no attachment" was observe several times during test for bug 565852 and some bugs.
  When mail-0 is clicked after click of mail-X(X!=0), attachents of mail-X is
  shown at attachment pane. "Open" works normally on the attachment of mail-X.
"Header pane display + message body display" and "attachment pane display" seem independent internal tasks.

FYI.
Mail data held in Disk Cache is like next after fectch body[1].
  Subjext: AAA-1
  Content-Type: multipart/mixed; boundary="xxx"

  --xxx
  Content-Type: text/plain

  aaa-1
  --xxx
               <= If writing to Disk Cache is interfered at this step,
                  no attachment is shown, and attachment icon disappers.
  X-Mozilla-IMAP-Part: 2
  Content-Type: application/pdf; name=...
  Content-Transfer-Encoding: base64
 
  This body part will be downloaded on demand.
  --xxx
               <= If writing to Disk Cache is interfered at this step,
                  some attachments are not shown at attachment pane.
  Parts for other PDF attachments.
  --xxx--
I have no IMAP folders enabled: I have POP accounts set to use the Local Folders as the common inbox, some blogs and some NNTP newsgroups.  (This is true for both the machines I mentioned above.)
(In reply to comment #9)

For POP accounts set to use the Local Folders as the common inbox.
Is next effective work around of this bug's phenomenon?
  plugin.scan.plid.all=false

For some blogs and some NNTP newsgroups.
If data of RSS feed or news article is not downloaded yet, I think similar situation to my IMAP test may occur.
If newsgroup, newsgroup properties/synchronization/"download now" downloads data of news articles to local file. (similar to local mail folder, and similar to IMAP folder of offline-use=on and mail data is already sync'ed)

Does your problem occur even after download of whole news article data to local file?
If yes, does plugin.scan.plid.all=false effective workaround?

Please note that I believe problem you pointed in comment #0 really exists as seen in your newsgroup case and in my test with IMAP, and I think root cause of this bug is not slowness in mail display. It merely that this bug's phenomenon is ordinary not exposed to user if slowness is sufficiently reduced.

Confirming by your newsgroup case(usually, articles is not downloaded yet for Work Offline) and my IMAP offline-use=off case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems to help but not fix it.  Certainly I'm seeing it less frequently than before, but I happen to be logged in to this machine via remote desktop (which is *great* for exposing race conditions!) at the moment, and cycled rather slowly through a few messages (~5-10), all POP messages in Local Folders and with plugin.scan.plid.all=false.  I currently have a screen where the message header, message body and mailbox list view are all in sync, but the attachments pane shows the wrong message.

I have noticed that [ and ] don't seem to work very well when your navigation history consists of one message in one folder, followed by another message in another folder, ... The first message in each folder doesn't seem to show up in the [/] history.  I have no idea if that's related, but the message whose stale attachment is visible was such a message.
Just an FYI, but I've been noticing this behavior for a long time on my Mac. All I generally need to do to reproduce is to go to an RSS feed with a lot of messages and then delete several really quickly. The one message it comes to rest on has its headers displayed, but the content is not correct. It doesn't happen every time, but quite regularly.
FYI.
As for phenomenon of "attachment(s) of previous mail at attachment pane", reliable "Steps To Reproduce problem using IMAP folder" has been provided by bug 612279.
Duplicate of this bug: 608719
Another FYI --

the "quickly" browsing requirement for this behavior may actually be a red herring.  I've witnessed this and bug 608719 multiple times.

Note that bug 608719 is unlikely to be about "stale" data, they simply seem to be pulled out of nowhere.
Blocks: 612279, 719751
No longer depends on: 612279, 719751
Severity: normal → minor
This bug is simply timing issue.
(1) After Load request of a message for mail view,
    HeaderBox, MessageBox, AttachmentBox are independently/asynchronously updated.
    Followibg was observed by Event Listner of these XUL boxes.
      After "onLoad" event of "document" at MessageBox,
      loded event of some elements of AttachmentBox happens.
(2) Load request by "message swich at message pane" can occur at any time,
    after "Load request of previous mail", before "completion of all load action/event"
    at all of HeaderBox, MessageBox, AttachmentBox.

This is different but similat to following phenomenon.
  "single Error Console only" is implemented by "existence check of already opened Error
  Console" upon open Error Console.
  This works pretty well usually.
  However, "Two Error ConSsle" can occur, and I saw it several times.
This is because;
  (1) "Open Error Console" requests window open for "Error Console".
  (2) When other "Open Error Console" request happens,
      Tb's code checks existence of already opened "Error Console".
  (3) If (2) happens before end of (1),
      "Open Error Console" is requested again because "already opened Error Console"
      doesn't exist. So two "Error Consoles" are opened.

Following is needed?
1. Save MessageKey of mail in XUL document's property upon Load request.
2. In any XUL element loader for message display, compare MessageKey,
   and if it's different, stop XUL element load/document element load action.
Severity: minor → normal
OS: Windows XP → All

(In reply to WADA:World Anti-bad-Duping Agency from comment #16)

...
Following is needed?

  1. Save MessageKey of mail in XUL document's property upon Load request.
  2. In any XUL element loader for message display, compare MessageKey,
    and if it's different, stop XUL element load/document element load action.

Sounds exciting. What do you think aceman?

Flags: needinfo?(acelists)

It seems to me this is worse in version 60.

And many potential matches in meta Bug 714489

See Also: → 736951, 1454542
You need to log in before you can comment on or make changes to this bug.