Closed Bug 749574 Opened 13 years ago Closed 13 years ago

Default view of folder panel resets at start

Categories

(Thunderbird :: Folder and Message Lists, defect)

12 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: adry, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [gs])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: 1)update thunderbird to 12 2)start tunderbird 3)View -> Folder -> select "Favourite" 4)restart thunderbird assuming there where favourite folders set of course. Actual results: The folder panel doesn't remember to display only "favourites" as selected before. It resets the view style to "all". Expected results: Display favourites in folder panel.
Severity: normal → major
(In reply to Wayne Mery (:wsmwk) from comment #1) > adry, is this you at > https://getsatisfaction.com/mozilla_messaging/topics/ > tb_12_folder_view_reset_with_every_new_start ? that's not me but it's the same problem.
FWIW I am _not_ able to reproduce this running with current trunk or: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120427 Thunderbird/12.0 (which is the tryserver build from bug 748997) Unfortunately, I don't have an unpatched V12 handy to verify that in fact the problem was actually fixed there. The fix there doesn't seem to relate to this bug.
This information is kept in localstore.rdf, which may not update correctly: <RDF:Description RDF:about="chrome://messenger/content/messenger.xul#folderTree" mode="favorite" /> See http://kb.mozillazine.org/Profile_folder_-_Thunderbird how to locate it. You can open it with a text editor with Thunderbird not running to verify whether or not it's updating that entry after changing it and closing Thunderbird.
(In reply to rsx11m from comment #4) > This information is kept in localstore.rdf, which may not update correctly: > > <RDF:Description > RDF:about="chrome://messenger/content/messenger.xul#folderTree" > mode="favorite" /> > > See http://kb.mozillazine.org/Profile_folder_-_Thunderbird how to locate it. > You can open it with a text editor with Thunderbird not running to verify > whether or not it's updating that entry after changing it and closing > Thunderbird. After setting the folder view to "favorite" and closing TB the mentioned entry in localstore.rdf is set to "favorite" as it is supposed to be. When starting TB again the view is not favorites but "all", although the entry in localstore.rdf is still "favorite". Apparently the setting is ignored or not read correctly in v12.
More reports coming in on MozillaZine, at least one use with Lightning 1.4 - http://forums.mozillazine.org/viewtopic.php?f=39&t=2464379
I also have this problem, both in V12 and V12.0.1. Win7 x64.
Bug persists in 12.0.1
Yeah, it would have been a nice surprise if the recent update fixed that... Two more things you can try: - Are there any messages in Tools > Error Console after changing the view, shutting down and then restarting Thunderbird? - Close Thunderbird, rename localstore.rdf in your profile, the restart so that a new localstore.rdf is created from scratch. Is the problem gone after switching the view and then restarting? Since per http://gsfn.us/t/2tnyp it also happens in safe mode (which would make sense if it's a localstore.rdf corruption), probably not worth testing again.
I get the following within the Error Console: generator favorite failed with exception: [Exception... "Component returned failure code: 0x80550013 [nsIMsgFolder.subFolders]" nsresult: "0x80550013 (<unknown>)" location: "JS frame :: chrome://messenger/content/folderPane.js :: ftv_addSubFolders :: line 1734" data: no] If I rename localstore.rdf and a new one is created, the problem still persists.
yes, it most likely has something to do with your folder structure on disk, i.e., it's specific to your user profile. Are your favorite folders all normal local folders?
I got 7 folders within my favorites: 3 IMAP inboxes, 1 POP3 inbox and 3 IMAP 'sent'-folders. What do you mean with "normal local folders"?
The error is NS_MSG_FOLDER_EXISTS, which makes me think we're trying to create the default mailboxes for a server, but don't realize that the mailboxes already exist. Do you have any accounts that "share" local directories on disk, e.g., two pop3 servers that point to the same directory in your user profile dir? This is supposed to be illegal, but some folks find ways around it.
markus: you can check the local directories David is talking about in Account Settings -> Server settings -> Local Directory. Do it for all accounts and see if the value is not the same in multiple accounts.
I checked and there are no multiple entries across the accounts. They all use a different local folder each. There are two googlemail accounts but the second one uses a folder where a "-1" is appended before the ".com" within the folder's name.
Blocks: 750251
UA: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 Build: 20120428123112 Having the same issues as O.P. introduced during upgrade to v.12.0. I've also tried the suggestions listed thus far inc deleting localstore.rdf, safe-mode etc to no effect. I can confirm that the mode entry in <RDF:Description RDF:about="chrome://messenger/content/messenger.xul#folderTree" mode="x" /> in localstore.rdf is being updated correctly when the view is changed, but is not sticking between restarts. For completeness, I'll mention that I am using add-on "Folder Pane View Switcher" to replace funcionality lost in v.8.0., but this of course is rendered moot when using safe-mode. Nevertheless I did try uninstalling regardless but again to no effect.
Is this ready to be confirmed? Perhaps it depends on the method of closing the program? I remember bug where using red [x] behaves differently over File > Exit. In TB, you never know.
Severity: major → normal
(In reply to Thomas D. from comment #18) > Is this ready to be confirmed? Yes. > Perhaps it depends on the method of closing the program? I remember bug > where using red [x] behaves differently over File > Exit. In TB, you never > know. I've tried: - "[x]" (window manager, not really red in my case ;-)) - "File > Exit" and its shortcut ([Ctrl]+[Q]) - Even $ killall thunderbird-bin Still the same, annoying problem.
Presumably you're using a localized version of TB? This might have to do with our handling of localized special folder names.
(In reply to David :Bienvenu from comment #20) > Presumably you're using a localized version of TB? This might have to do > with our handling of localized special folder names. Indeed I use a Polish language version, but with English (after Tools > Add-ons > Disable for Polish and restart) the problem remains (tested well).
Easily reproducible for me on WinXP/TB12.01 STR 1 View > Folders > Favorite 2 Close TB (no matter how) 3 Restart TB Actual View is back to "All folders" Expected View should stay at "Favorite"
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm trying to resolve more bugs than I confirm, but it's really hard... ;)
There is an indication this could get fixed by bug 756316 and bug 759237.
Depends on: 756316, 759237
Bug persists in v13
Bug persists. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
Why the bug doesn't arise in portable versions? e.g. portable 13.0 from portable applications?
regression of bug 402392 ? or what?
Resolved in v14.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
(In reply to rof from comment #30) > Resolved in v14.0 > > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 confirmed
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I'm well pleased - thank you to all the devs that helped fix this. In the grand scheme of things I know it may not be a show stopper, but it certainly makes a difference to me. Cheers & have a pat on the back :)
Thank you for reparing Thunderbird in version 14. It makes a great difference for me.
Thanks to all who contributed to solve this issue! Using Thunderbird is comfortable again ;)
You need to log in before you can comment on or make changes to this bug.