298285 - new unread messages don't appear when switching to folder with them

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

When I hit "n" to go to the next unread message, and Thunderbird switches to the
next folder with new unread messages, it sometimes doesn't display the new
messages, even though the folder pane indicates there are new messages in that
folder (and indeed there are, since if I exit the folder and reenter it a few
times it eventually displays the messages).

Most of my folders are set to the custom view "New Mail and Tasks," which
displays both labeled and unread messages (and thus shouldn't be preventing the
new messages from showing up).  And this does happen even to folders with no
view set.  So it's not that my views exclude unread messages.

But now that I think about it, it does seem to happen less frequently since I
reset most folders to the default "All" view, and the last few times I
experienced it, I was going from a folder with a view set to a folder without a
view set, so it may be the view on the folder I'm leaving that is causing the
problem rather than the view on the folder I am entering.

FWIW, these are all IMAP folders on multiple accounts, and I've reproduced the
problem both when hitting "n" to go to the next unread message (my profile is
configured to switch to the next folder with unread messages without prompting
me first) and when I click on a folder with unread messages.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

I've done some more testing, and the problem is specifically when going from a
folder with a view to a folder with unread messages.  I can reproduce it
consistently.  Just go to an IMAP folder with no unread messages, set a view,
then hit "n" to go to the next unread message in an IMAP folder.

The problem isn't limited to "n".  It also manifests when I click a folder in
the folder pane to go to it, as long as the folder I was in beforehand had a
view set on it.

Comment 2

[Scott MacGregor]

putting in the 1.1 bucket now that we've got easy steps to reproduce

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Actually, it's not even view-specific.  You can see the same effect going from a
folder in which you've done a quicksearch.  For someone like me who regularly
uses views and quicksearch (I'd use a view in almost every folder if it weren't
for this bug), this significantly impairs multi-folder usability.

Comment 4

[David :Bienvenu]

the problem is limited to imap (and perhaps news), and is that for some reason
we're not downloading the headers. Taking.

Comment 5

[David :Bienvenu]

this is really strange - I think we are actually downloading the headers, but
when we initially open the second folder, we're creating a view type that
matches the current view type. We then open a new view when the folder is
finished loading, but I don't think that view hears about the new headers. To
make it a little more strange, just when you just click on the second folder, we
also create the wrong kind of view, but we create the correct view when trying
to restore the last selected message.  I'm not sure, but it seems like an
accident that it works at all...

Comment 6

[Scott MacGregor]

clearing the flag. Myk, this is already in our 1.1 bucket

Comment 7

[Scott MacGregor]

David, could this be related to another 1.1 blocker, Bug 277842 which I have
been able to reproduce and have been looking at.

Comment 8

[David :Bienvenu]

Attachment: proposed fix

the destruction of the search session used in the previous view was cancelling
the imap url to fetch the headers for the other folder. The fix was not to stop
running urls if we're not currently running a url.

Comment 9

[Scott MacGregor]

Comment on attachment 192002 [details] [diff] [review]
proposed fix

is this the right patch?

Comment 10

[David :Bienvenu]

Comment on attachment 192002 [details] [diff] [review]
proposed fix

sigh, no.

Comment 11

[David :Bienvenu]

Attachment: proposed fix

Comment 12

[Scott MacGregor]

Comment on attachment 192006 [details] [diff] [review]
proposed fix

much better