Closed Bug 581330 Opened 11 years ago Closed 11 years ago
All default smart folders empty since update TB3
.0 .6 -> TB3 .1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; nl; rv:184.108.40.206) Gecko/20100713 Firefox/3.6.7 Build Identifier: Thunderbird/3.1.1 Since I've updated to TB 3.1 smart folders Inbox, Drafts, Sent and Trash are empty. All subfolders (3 IMAP- and 2 POP-accounts) still display correct, I just can't view them grouped using the smart folder on top of it. All other folders display correct. Starting TB in safe mode didn't make a difference, neither did removing/adding an account. The errorconsole displays the following code when loading a smart folder: Fout: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.server]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Applications/Thunderbird.app/Contents/MacOS/modules/searchSpec.js :: SearchSpec_applySearch :: line 449" data: no] The exact same error appears everty I click one of the folders Reproducible: Always Steps to Reproduce: 1. Open Thunderbird 2. Wait until application has opened 3. Click on a smart folder (inbox, drafts, outbox, trash) Actual Results: The window where messages get listed is empty Expected Results: Display messages of all accounts in the smart folders. For example inbox messages of all accounts in the inbox folder I'm using the Dutch language pack
this makes us verify all the search scopes in saved folders, and removes the folder from the uri list if it seems invalid. One thing this doesn't do is remove the whole virtual folder if no folders are left in the scope. I'm kinda OK with that... I need to add a unit test for this.
Assignee: nobody → bienvenu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think there's a bug that's horking the unified folders in 3.1, and this repairs the damage, so I'd like to get this on the trunk soon for testing, because I think this should get fixed in a 3.1.x build.
Uhm... am I wrong or is this bugfix sort of "we know we will brake things, so let's fix them afterwards"?! I expected something like "let's fix, so that we will not brake things in the future". :-| It's OK to double-check and so make sure it will work also if something got broken... but when deleting an account, invalid URIs are left within the file... and THAT should be fixed?!
(In reply to comment #4) > Uhm... am I wrong or is this bugfix sort of "we know we will brake things, so > let's fix them afterwards"?! No, it's that things have already been broken, and we have to repair them. > > It's OK to double-check and so make sure it will work also if something got > broken... but when deleting an account, invalid URIs are left within the > file... and THAT should be fixed?! We don't know how to reproduce that issue. Once we've figured that out, we'll fix it as well. Deleting an account generally works, and we have unit tests for it as well.
Oh, and if you know how to reproduce the issue, it would be extremely helpful if you could add that info here.
(In reply to comment #6) > Oh, and if you know how to reproduce the issue, it would be extremely helpful > if you could add that info here. Is there anything I can do to help you analyse this problem? Maybe provide you with some additional data or install some debugging tools?
Please see bug 578148 for actions how to reproduce. Sorry if I didn't state that clear enough... copy paste: 1. Create a new IMAP account in Thunderbird (e.g. email@example.com) 2. Close Thunderbird, have a look at virtualFolders.dat - everything fine 3. Open Thunderbird, delete firstname.lastname@example.org account 4. Close Thunderbird, have a look at virtualFolders.dat - meep! In my opinion the "delete IMAP-account"-Code breaks the file. It doesn't clean up properly!
the bug partly depends on account order, but this does fix what I was able to reproduce...
Comment on attachment 460696 [details] [diff] [review] fix source of corruption, and fix mozmill test to detect it r/sr/a=Standard8. Please land on comm-1.9.2 COMM1927_20100730_RELBRANCH as well (or let me know and I'll do it).
fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
fixed for comm-central 1.9.2 changeset: 5749:05fec90c2035 and rel branch - changeset: 5750:5e8e3a19eca8
You need to log in before you can comment on or make changes to this bug.