Closed Bug 581330 Opened 11 years ago Closed 11 years ago

All default smart folders empty since update TB3.0.6 -> TB3.1

Categories

(Thunderbird :: Folder and Message Lists, defect)

x86
macOS
defect
Not set
minor

Tracking

(blocking-thunderbird3.1 .2+, thunderbird3.1 .2-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
blocking-thunderbird3.1 --- .2+
thunderbird3.1 --- .2-fixed

People

(Reporter: jasper.hopman, Assigned: Bienvenu)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; nl; rv:1.9.2.7) 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
Version: unspecified → 3.1
Attached patch proposed fix (obsolete) — Splinter Review
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 believe this is the same as bug 578148 but will verify once the fix lands.
Blocks: 578148
Attached patch fix with unit test (obsolete) — Splinter Review
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.
Attachment #460365 - Attachment is obsolete: true
Attachment #460554 - Flags: superreview?(bugzilla)
Attachment #460554 - Flags: review?(bugzilla)
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. testimap@bla.com)
2. Close Thunderbird, have a look at virtualFolders.dat - everything fine
3. Open Thunderbird, delete testimap@bla.com 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...
Attachment #460554 - Attachment is obsolete: true
Attachment #460696 - Flags: superreview?(bugzilla)
Attachment #460696 - Flags: review?(bugzilla)
Attachment #460554 - Flags: superreview?(bugzilla)
Attachment #460554 - Flags: review?(bugzilla)
blocking-thunderbird3.1: --- → .2+
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).
Attachment #460696 - Flags: superreview?(bugzilla)
Attachment #460696 - Flags: superreview+
Attachment #460696 - Flags: review?(bugzilla)
Attachment #460696 - Flags: review+
Attachment #460696 - Flags: approval-thunderbird3.1.2+
fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
fixed for comm-central 1.9.2 changeset:   5749:05fec90c2035
and rel branch - changeset:   5750:5e8e3a19eca8
Target Milestone: --- → Thunderbird 3.2a1
You need to log in before you can comment on or make changes to this bug.