User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 StumbleUpon/1.9995 (Debian package 1.0.3-2) Build Identifier: Thunderbird version 1.0.2 (20050331) (Not sure - this could a duplicate of bug 267691, though different platform.) I've got two usenet accounts, each with several subscribed newsgroups. All newsgroups are set to View->Thread->Threads with Unread. Intermittently, any one or more of these newsgroups reverts to View->Threads->All. Does not require Thunderbird be restarted. Can happen if newsgroup A is okay, after switching to newsgroup B and then back to A, A's View->Thread pref could have changed. Happens relatively often, perhaps a couple of times in any session. Reproducible: Sometimes Steps to Reproduce: 1. View newsgroup A (with correct View->Threads). 2. View newsgroup B. 3. View newsgroup A again, View->Threads may have changed. Actual Results: View->Threads may have changed. Expected Results: View->Threads should have remained with its original setting.

I'm seeing the same problem with an IMAP folder. I've set it to View->Threads->Threads with Unread, but it often (not always) converts back to Threads->All (Thunderbird version 1.0.2 (20050317), Windows XP)

I've got more info, and can now create the failure at will. This may not be the only failing case but... I've got an email "folder" followed by "News & Blogs" and another email folder and "Local Folders," and, finally, two newsgroup folders. If I read an RSS entry in one of the "News and Blogs" accounts, and then click on on one of the newsgroups with unread items in one of the newsgroup folders, that newsgroup will ALWAYS have been reset from View->Thread->Threads with Unread to View->Thread->All. No other newsgroups are affected. This happens EVERY TIME I follow this sequence. Debian T'bird version 1.0.2 (20050331). Fails even with all extensions disabled. (Note: I tried to change the status of this bug, but was not able to.)

I am also experiencing the same problem as the others here. I am running TBird version 1.0.2-1.3.3 (20050513) on Fedora Core 3 (kernel 2.6.10-1.770_FC3) on vanilla Athlon 2800 box. I set the "View/Threads/Threads with Unread" on one account and visit another account (Could be news or IMAP or other POP account) to find that the same setting made earlier there has reverted to "View/Threads/All". If I then reset this to the desired "View/Threads/Threads with Unread" and go to another account where I do not want this setting, I then "Get Mail", read say 1 mail and then return to the first account, I find the settings have reverted to "View/Threads/All". This behaviour is NOT acceptable. The setting should be per account and not, as is apparently the case, per TBird instance.

I too was troubled by this same issue and could not figure out the 'constant' that was causing the 'Sort' settings to not be remembered for a couple of my newsgroups, while the other 8 or 9 I had subscribed to were fine. (I only use TB for text-based newsgroup reading, not emails, so can't comment on the email side of things). I tend to keep all of my newsgroups set to: Sort By -> Subject -> Ascending -> Threaded Messages -> Unread Threads -> Unread After realizing there was a problem, I initially tried out a brand new Profile with nothing extra installed, and was able to quickly rule out that it was a bug introduced by any extension(s), but for a long time wasn't quite sure what it was exactly that I'd done in order to make it happen. This past weekend, I was able to do some extensive testing, and have finally been able to pinpoint the steps necessary to reproduce the issue every time: [You might want to try this on a new profile just to confirm that no extensions/themes or previous newsgroup settings are used]. * Verify the initial View settings: 'Sort by->Order Received->Ascending->Threaded', 'Messages->All', 'Threads->All'. * Click on the 'Date' header to sort by date .. then check that the messages are sorted correctly * In the 'View' dropdown just above the message list, change from 'All' to 'Unread' view. * Now Sort by 'Subject'. * Change to 'Sort by-> Threaded' view. * Check that it's sorted properly It is NOT !! -- It is Sorted by 'Subject'.. but the messages are NOT sorted alphabetically (up or down)!! * Switch newsgroups for a minute, remembering what the current View setting is (Sort by 'Subject') * When you return to the initial group, you'll see that it is now sorted by 'Date'. * Sort by 'Subject' again.. and amuse yourself by switching newsgroups again, and watch as every time you'll find it sorted by 'Date' upon your return! * Sort by 'Subject' again, then from the 'View->Sort by' menu, make the 'Subject' sort 'Threaded'. * Check to see if the Subject column is sorted correctly -- it will NOT be sorted properly. * Now change back to View->Sort By->Threads->'All' view. * Make it 'Threaded' again * Check to see if the Subject column it is sorted correctly - it will be now. * Change groups again. * Change the 'View' dropdown from 'All' back to 'Unread'. * Check that it's sorted properly.. it will be. The above test proves that when a user switches to the 'Unread' view (using the drop-down, or the Messages->All' menu item), the Sort settings that are utilized are actually the 'Messages->All'-view settings, despite what the menus and settings-indicators indicate. The last part of the above step-by-step guide confirms that once the 'All' settings have been set to the same as the desired 'Unread' view settings, 'Unread'-sorts are finally sorted corrected (alphabetically, by date, size, etc), and the sort-settings finally appear to be 'remembered' when returning to the newsgroup after leaving it. However, this last statement is not quite correct - the settings are not being 'remembered', but they area actually using the 'All' view settings. (So the obvious quick work-around to the problem is to configure the 'All' view to the way you want your 'Unread' setup to be, and then switch to 'Unread', and it should be set the way you wanted it). I have not examined the source code, but believe the problem is likely caused by 1 of 2 things: 1) The code was simply only written with one "last_view_settings" routine, which defaults to the 'All' view. 2) There is a simple typo somewhere, or the code section for 'All' was simply copy-and-pasted and forgotten to be updated for the 'Unread' routine so that it currently reads something along the lines of "last_view_setting(All)" instead of being "last_view_setting(Unread)"? ** Incidentally, I noticed this which may be related (not sure if it is supposed to do this, but I think not): When changing to an 'Messages->Unread' view using the menu or the drop-down (and obviously coming from the 'All' view), the 'Threads->' submenu no longer shows a bullet to indicate whether the user is in 'All' or 'Unread' mode. Switch back to 'Messages->All' and notice the 'Threads' bullet return, as it should do. I can confirm the issue on both - Thunderbird 1.5RC2 (20051201-15), and on - SeaMonkey 1.0b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219

Sorry, I made a typo/error: I wrote: * Sort by 'Subject' again, then from the 'View->Sort by' menu, make the 'Subject' sort 'Threaded'. * Check to see if the Subject column is sorted correctly -- it will NOT be sorted properly. * Now change back to View->Sort By->Threads->'All' view. "Sort By->Threads->All" should have read * Now change back to View->MESSAGES->'All' view.

This Bug appears to be a duplicate of/duplicated by: Bug 107280, Opened: 2001-10-28 Bug 271036, Opened: 2004-11-20 Bug 279126, Opened: 2005-01-20

Reporter (mozilla@waysoft.com) -- are you still seeing the symptoms you originally reported, with current builds (e.g. TB 1.5rc2 or Seamonkey 1.0b)? (In reply to comment #4) > I tend to keep all of my newsgroups set to: > Sort By -> Subject -> Ascending -> Threaded > Messages -> Unread > Threads -> Unread Support for threading with a view enabled (e.g. "Unread") was only recently implemented; TB 1.5 and Seamonkey 1.0 will be the first official releases with this feature. (I now see that View | Threads | Unread is superfluous, as it's now possible to turn on threading with View | Messages| Unread .) > [steps to reproduce] > * Check that it's sorted properly > It is NOT !! -- It is Sorted by 'Subject'.. but the messages are NOT > sorted alphabetically (up or down)!! I see this. (I'm not sure if it's the same bug as reported here.) This applies when the 'Unread' view (and maybe other views) is in use, but not when 'All' messages are displayed. > * Switch newsgroups for a minute, remembering what the current View > setting is (Sort by 'Subject') > * When you return to the initial group, you'll see that it is now sorted > by 'Date'. I see this sorted by Order Received (which looks a lot like 'by date'). But 'Threading' is turned off at this point. Also, at this point, the View|Threads submenu has no selection, as you mention later -- which *is* kinda what this bug is about. (No errors seen in the JS console at this point.) > [etc.] > The above test proves that when a user switches to the 'Unread' view [...], > the Sort settings that are utilized are actually the 'Messages->All'-view > settings, despite what the menus and settings-indicators indicate. I see this behavior, and I agree it's both unexpected and undesirable. However, I'm not sure that it's *this* bug: reporter said nothing about using the message views; he's talking about having the settings working as expected while viewing a newsgroup, switching to a different group or folder, then returning the newsgroup and having those settings forgotten. (In reply to comment #6) > This Bug appears to be a duplicate of/duplicated by: > Bug 107280, Opened: 2001-10-28 Yes, that suite bug looks like it might be the same problem as this bug -- but again, that's not the same as the symptoms you've described in such detail. > Bug 271036, Opened: 2004-11-20 Not a dupe of this bug. > Bug 279126, Opened: 2005-01-20 Not a dupe of this bug.

I hit same thing as comment #2 all the time (reading a News & Blogs folder before a Newsgroup resets the Threads with Unread on the latter). By playing around, I noticed something that may be helpful for debugging. I don't thread the News & Blogs and view Unread messages only. In contrast I set newsgroups to Threads with Unread. In this configuration I can switch from N&B folder to newsgroup and the Threads setting will always be reset to All, even if I have set it back after the last test. But if I also set the N&B folder to Threads with Unread, then the newsgroup will not be reset when selected. Switching from an IMAP folder showing All messages to newsgroup does not reset the Threads with Unread, regardless of the IMAP folder's threading.

Also, I just noticed that switching from a newsgroup that is not Threads with Unread to a N&B that is will also reset the view. So a workaround is to always, or never, use Threads with Unread.

Still a problem with Thunderbird 1.5 (20051201).

xref bug 267727 comment 15 (the last paragraph)

(In reply to comment #9) > Also, I just noticed that switching from a newsgroup that is not Threads with > Unread to a N&B that is will also reset the view. > > So a workaround is to always, or never, use Threads with Unread. > I tried to set all newsgroups as "Threads with Unread" but the problem still persists (Thunderbird version 1.5.0.2 (20060501))

by the way, I noticed that a thread with all messages read is still listed until you read the first message of the thread...

The problem is still present in Thunderbird 1.5.0.8

While researching related issues on bug # 362741 I also encountered this bug. I believe that I understand why this happens. In msgViewPickerOverlay.js, function ViewNewMail, this code is used to search for new messages: gDefaultSearchViewTerms = searchTermsArray; But in commandglue.js, these lines reset the viewType to a quick search type (that is, NOT a threaded with unread type) if that variable is set: else if (gSearchEmailAddress || gDefaultSearchViewTerms || gVirtualFolderTerms) viewType = nsMsgViewType.eShowQuickSearchResults; It seems like it is incorrect to be using gDefaultSearchViewTerms simply to show new mail (and a comment by David in the code shows concerns).

This problem is also present in Thunderbird 2 beta 2 (20070116).

it seems that messages are correctly set as read (since showing only unread messages correctly shows only unread messages) but when switching to threads with unread it shows also thread where no message is unread, but it was not opened in that computer. It probably uses information in the msf or dat file? While I only sinchronize the rc file amongst many computers...

Kent, I'd loved to have read your comment a while ago, since I see this behaviour in SM, too, and it is driving me nuts - and I just identified the very same code as the problem. It'd have saved me some precious time. ;-) I think that the check for gDefaultSearchViewTerms simply doesn't make sense here and I'm running a respective patch for a while now without problems (but maybe my usecase is too narrow). Taking and moving to Core to show it's both SM and TB.

so is there an easy way to fix the problem? This bug indeed always forces me to show only unread messages (instead of show only threads with unread), thus missing all the functionalities of threads...

(In reply to comment #19) > so is there an easy way to fix the problem? So it seems. If you know how to hack your lizard, you could just change the relevant code in commandglue.js, about line 930: Change else if (gSearchEmailAddress || gDefaultSearchViewTerms || gVirtualFolderTerms) to else if (gSearchEmailAddress || gVirtualFolderTerms) I'll post a patch when I'm quite sure it hasn't undesirable side effects.

I guess this requires sources and recompile thunderbird from sources doesn't it?

In this case, no - just a decent zip tool and a text editor. Anyway, the fix in comment #20 doesn't quite suffice anyway, so be patient. :)

While in case of virtual folders we generate their search terms from the new folder, the view search terms of the old folder are kept, causing a wrong viewType to be chosen when creating the gDBView. Since we clear quick searches on folder changes anyway and since it doesn't make much sense to keep the view if the new folder is different, this patch simply drops the offending search terms.

Comment on attachment 260069 [details] [diff] [review] clear view search terms on folder change (SM + TB) thx, Karsten.

So how can this patch be applied? You said there's no need to modify the sources and recompile it, but, I guess, only modify this file, which, however, is not on my system...

The file is inside the $application_directory/chrome/messenger.jar, which is in fact a simple .zip file. Attachment 260069 [details] [diff] landed on trunk.

a=me for 1.1.2

Landed SeaMonkey part on MOZILLA_1_8_BRANCH.

We probably want the TB version for this *after* 2.0 ships.

So I supposed. :) Interested parties ;-) are free to check this in then or ping me to do it, if I forget.

May I ask why this won't be making it into 2.0?

I applied the patch, manually since my version of that file is not as new as yours (1.5.0.10), in fact these are the differences after the modification: diff commandglue.js newcommandglue.js 799a800 > gDefaultSearchViewTerms = null; 880c881 < else if (gSearchEmailAddress || gDefaultSearchViewTerms || gVirtualFolderTerms) --- > else if (gSearchEmailAddress || gVirtualFolderTerms) however, the problem still persists: see the attached screenshot. it shows a newsgroup where threads with all messages read are shown, in spite of having set "view threads with unread"

Are you sure that the folder still _has_ "threads with unread" set? In an unpatched build, setting "threads with unread" for folder A, jumping to folder B which has "View Unread" set, jumping back to folder A will *reset* folder A to "All Threads"! That means if fix the bug then, restart and go A, all threads will be shown... That said, I'm not sure that this patch suffices to fix the bug in 1.5.x, it may depend on other changes already in the pre2.0 branch.

probably I'm posting to the wrong bug... my problem is that even when I set view threads with unread, still threads where all messages are read are still shown (see the attachment of my previous post)...

this problem is still in TB v2.0.0.12. it's driving me *nuts*. will this be fixed during the v2 lifetime or is it something to look forward to in v3?