Closed
Bug 298285
Opened 19 years ago
Closed 19 years ago
new unread messages don't appear when switching to folder with them
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: myk, Assigned: Bienvenu)
Details
Attachments
(1 file, 1 obsolete file)
861 bytes,
patch
|
mscott
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
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•19 years ago
|
||
putting in the 1.1 bucket now that we've got easy steps to reproduce
Target Milestone: --- → Thunderbird1.1
Reporter | ||
Comment 3•19 years ago
|
||
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.
Flags: blocking-aviary1.5?
Assignee | ||
Comment 4•19 years ago
|
||
the problem is limited to imap (and perhaps news), and is that for some reason we're not downloading the headers. Taking.
Assignee: mscott → bienvenu
Assignee | ||
Comment 5•19 years ago
|
||
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•19 years ago
|
||
clearing the flag. Myk, this is already in our 1.1 bucket
Flags: blocking-aviary1.5?
Comment 7•19 years ago
|
||
David, could this be related to another 1.1 blocker, Bug 277842 which I have been able to reproduce and have been looking at.
Assignee | ||
Comment 8•19 years ago
|
||
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.
Attachment #192002 -
Flags: superreview?(mscott)
Comment 9•19 years ago
|
||
Comment on attachment 192002 [details] [diff] [review] proposed fix is this the right patch?
Assignee | ||
Comment 10•19 years ago
|
||
Comment on attachment 192002 [details] [diff] [review] proposed fix sigh, no.
Attachment #192002 -
Attachment is obsolete: true
Assignee | ||
Comment 11•19 years ago
|
||
Attachment #192006 -
Flags: superreview?(mscott)
Assignee | ||
Updated•19 years ago
|
Attachment #192002 -
Flags: superreview?(mscott)
Comment 12•19 years ago
|
||
Comment on attachment 192006 [details] [diff] [review] proposed fix much better
Attachment #192006 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Updated•19 years ago
|
Attachment #192006 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #192006 -
Flags: approval1.8b4? → approval1.8b4+
Updated•19 years ago
|
Product: Core → MailNews Core
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Component: Mail Window Front End → MailNews: Backend
Product: Thunderbird → Core
Resolution: --- → FIXED
Target Milestone: Thunderbird1.1 → ---
Version: unspecified → Trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•