User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 - Build ID: 20091204171430 I usually work in filtered folder view, i.e. the folder window on the left hand side only shows folders which contain unread messages. I have several e-mail accounts, a news account, lots of RSS feeds and also several virtual folders which are shown and updated in this view. When I read a message in a certain folder and at the same time new messages are fetched, my currently displayed folder/message is automatically switched to some random(?) folder for which new messages have just arrived. Maybe this is due to an update in the folder view. Anyway, it is quite disturbing and definitely a bug that a folder is switched in this unwanted manner. It is especially bad if the message I read was the last unread one in the current folder, because after the folder view has been updated the folder is gone and I must switch to another view (all folders) to manually find it again and continue reading the previous message. Reproducible: Sometimes Steps to Reproduce: 1. Switch to "unbread" folder view 2. Read a message 3. Make TB fetch new messages 4. In many cases, TB will switch to some random unread folder after the folder view has been updated 5. The previously read message is gone from the message view because the current folder has just been switched Actual Results: See "details". Expected Results: Currently displayed folder is *not* switched, stays stable, so I can continue reading messages in that folder. As far as I remember, TB2 did not show this disturbing behaviour.
Does it happen in -safe-mode (http://kb.mozillazine.org/Safe_mode) ?
Yes, it does. I just tested it by sending myself an e-mail to three of my accounts, going to a virtual folder containing RSS messages, reading the last unread RSS feed element there (no none are unread anymore) and fetching all e-mails via Shift-Ctrl-T.
I just had a new experience: It happened three times during one rather lengthy fetching process. I even was not reading messages at the beginning, had the message view hidden with F8. I just watched the fetching, full-text indexing and spam filtering process in the course of which TB jumped to different folders twice. Then I switched to a folder of my own choice and read a message. There it happened for the third time. There still were unread messages in all corresponding folders, by the way. Sorry, this phenomenon is hard to describe, but I see it several times every single day since I upgraded to TB3, so it should not be too hard to reproduce.
(In reply to comment #3) > Sorry, this phenomenon is hard to describe, but I see it several times every > single day since I upgraded to TB3, so it should not be too hard to reproduce. I've switched that view let's see how things go.
Ok I've been running for some time in that mode now and it doesn't happen to me. Aureliano could you give this one a try ?
(In reply to comment #5) > Aureliano could you give this one a try ? Next week, now I'm away ;-)
Should I cook up a screen video recorded in safe mode? Would it help you understand the issue in any way?
(In reply to comment #7) > Should I cook up a screen video recorded in safe mode? Would it help you > understand the issue in any way? That would help for sure.
Created attachment 422750 [details] Flash movie #1 Flash movie #1 showing how currently displayed Junk folder/message are switched to another folder after new messages were fetched. Recorded in TB 3.0.1 safe mode.
Created attachment 422751 [details] Flash movie #2 Flash movie #2 showing how currently displayed Junk folder/message are switched to another folder after new messages were fetched. It happens while I am typing a new message in a composer window. Recorded in TB 3.0.1 safe mode.
Very visible on your screen captures. David any idea what could be happening here ?
Yes, we rebuilt the folder view, probably because a new folder was added because it went from not having unread messages to having unread messages. The currently selected folder did not have any unread messages, so it was not included when we rebuilt the view, so we could not select it. In general, we should not be rebuilding the view, or, if we do, we need to make sure the selected folder is in the rebuilt view, so we can select it correctly.
I opt for the latter (rebuild view + make sure the currently selected folder and message are still kept in view and in focus). This would kind of match the behaviour of TB 2.0.x where AFAIK views were not updated as nicely as in TB 3, but the current folder was kept in the list. Not updating is not an option because it means a loss of functionality, but switching folders is also not acceptable.
There's a middle road, which is to add the folder(s) that went from not having unread to having unread to the view, but don't remove the folders that no longer have unread.
It seems like the key balance is between updating the view such that people can see the list of unread folders (and swapping out the read folders) but never swapping out the current folder from under them.
Hasn't been any comments on this bug for about a month and a half. Just wondering what the status is - whether there's a fix planned at some point in the future. I'm also suffering from this bug, and it's rather annoying. Thanks!
Is there any way this bug might be able to get some love? It's been driving me crazy every since I upgraded to TB3 - marking my unread messages read and turning using TB on a daily basis into a real chore, as I have to go manually fixing what it keeps automatically messing up. As this is functionality that was working in TB2 which got broken in TB3, I'd think this issue should really deserve some attention. Would like to be able to contribute a patch myself but I'm not a c++ developer (or familiar with TB's code), so it would take me a very long time to try to fix this. TIA!
If this is the same as bug 495020, then, there's a patch in that bug waiting for review.
I'll take that as implicit confirmation that this is a dup :-)