Closed Bug 751562 Opened 12 years ago Closed 12 years ago

Filters which move emails to folders broke after 12.0.1

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird14 fixed, thunderbird15 fixed)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 16.0
Tracking Flags:
Tracking Status
thunderbird14 --- fixed
thunderbird15 --- fixed

People

(Reporter: bugzilla, Assigned: Bienvenu)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

proposed fix
3.12 KB, patch
neil
: review+
Details | Diff | Splinter Review
fix addressing Neil's comments, for trunk.
3.13 KB, patch
Details | Diff | Splinter Review
patch for aurora (probably applies to beta as well)
3.97 KB, patch
standard8
: approval-comm-aurora+
standard8
: approval-comm-beta+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Accepted the upgrade to 12.0.1 for Thunderbird on 04/30, after which filters for my POP3 account which move incoming emails to different subfolders are triggered for "organizing" my incoming emails on each restart of the Thunderbird program.


Actual results:

The filters which move incoming POP3 emails to different subfolders in Thunderbird are now having problems locating those subfolders since my upgrade to 12.0.1.

The error message reads:

"The folder 'Folder1' could not be found, so filter(s) associated with this folder will be disabled. Verify that the folder exists, and that filters point to a valid destination file."

After receiving the above message when a filter for "Folder1" meets the criteria to move an incoming email to it, I can Edit that filter (which is now disabled), see that the previously saved "Folder1" selection for the "Move to" operation has been blanked out, then reselect "Folder1" and save the filter again. After re-enabling the filter via the filter list checkbox, I can run it manually and it works fine during that Thunderbird session.

However, if I close Thunderbird and reopen it, if that re-enabled filter is triggered for a new incoming email, I will receive the same error message shown above and its folder selection field value will once again be blanked out.

Also noticed a potentially more general issue with filters and folder values within them on 12.0.1:

If I open "Tools" -> "Message Filters" after restarting Thunderbird, any filter which moves files to a folder shows a blank folder value when first I "Edit" that filter. But, closing that filter edit dialog and then re-hitting the "Edit" button from the filter list shows the appropriate folder name in the "Move to" field for that same filter.


Expected results:

The filters which move incoming POP3 emails to different subfolders in Thunderbird should actually move the new emails to folders when a respective filter's criteria gets triggered (e.g., match a From address value, etc.).

I regressed my Thunderbird install to 11.0.1 + Lightning (my only extension) to 1.3 and the filter behavior was corrected: filters properly moved incoming emails to their respective folders.

I don't know enough about the internals of Thunderbird to be sure, but is my problem reported here at all related to https://bugzilla.mozilla.org/show_bug.cgi?id=748090 ?
That bug is fixed in 12.0.1 so it should be different. However, your problem may is similar to bug 714364. That bug just does not mention the folder targets gettting corrupted (blank). And the fix there is just to enable the filters again (not fix the targets).

The error console seems OK. Only the gloda error is interesting, why would it fail at move/copy. Can you try right-click on a folder (that has the problem) then Properties -> Repair folder?
Component: General → Filters
Product: Thunderbird → MailNews Core
QA Contact: general → filters
Bug 714364 does seem similar in the blanking of their Folders field value, but it mentions that incoming emails are correctly routed before the field blanking seems to occur.

My error condition prevents incoming emails from being moved correctly.  Also, editing and re-enabling the affected filter in my error situation provides a temporary fix: while Thunderbird remains running, the corrected filters operate as expected and their Folder field values look as expected, but after stopping and restarting Thunderbird the error condition occurs all over again and their folder values are blanked.

I attempted to "repair" one of the folders related to a filter that has given me this error message and subsequent tests still exhibited the same error I have reported.

Further exploration:

Testing just now confirmed that some other filters still work; I can't see any differences between the filter types and logical conditions that would make one filter work vs another in my setup.  They each search for different values in order to sort emails into different folders.

I decided to Delete one of the problem filters and recreate it exactly as it was before.  Then, I enabled it and restarted Thunderbird.  The result was something a bit new in this case: no error message popped up on Thunderbird restart and the filter remained enabled, but the email landed in the Inbox because the filter's "Move Message to" value was blanked (as before).  I have since reselected the proper folder and saved that filter for a few restarts of Thunderbird and it gets blanked out at each startup (as before).  Older filters with this error condition still cause a message popup to occur, though.
Can you paste a sample filter definition (that misbehaves) from your msgFilterRules.dat file (it is stored along the files that contain your mail folders)?
It should look like this:
name="test name"
enabled="yes"
type="17"
action="Move to folder"
actionValue="mailbox://aceman@mail.sk/Inbox/Folder/test"
condition="AND (subject,contains,xyz)"
Depends on: 714364
Here is what one of the problem filters looks like after it has been correctly enabled and Thunderbird shut down:

name="Route American Express"
enabled="yes"
type="17"
action="Move to folder"
actionValue="mailbox://mymail@mymailserver.com/Use%20and%20Buy/Products-Services/AMEX"
condition="OR (from,contains,americanexpress.com) OR (from,contains,aexp.com)"


Here is how it appears after Thunderbird is restarted and the error has occurred:

name="Route American Express"
enabled="no"
type="17"
action="Move to folder"
actionValue="mailbox://mymail@mymailserver.com/Use%20and%20Buy/Products-Services/AMEX"
condition="OR (from,contains,americanexpress.com) OR (from,contains,aexp.com)"
And after you view this filter in the editor the folder picker (target) is blank?
Strange, it seems identical.

Can you try disabling the Global search and indexer in Preferences -> Advanced -> General ?
Disabling that option causes no apparent difference in the error condition being raised, from what I can see.

Of note: the Folder field value is only turned off in msgFilterRules.dat after an email triggers the filter, it seems - just starting and stopping Thunderbird does not affect the filter's state.
If we don't think "Use%20and%20Buy/Products-Services/AMEX" exists when we try to run the filter, we'll disable the filter. Does the folder exist?
I can confirm that the folder exists in Thunderbird and filter work fine with that value if I reselect the folder within the associated filter, then run that filter in the same Thundbird session.

This problem only occurs when filters run on incoming mail during a Thunderbird restart, it seems.

Overlaying my current install back to Thunderbird 11.0.1 with Lightning 1.3 works fine for the same filters (as have all past versions since I instantiated these filters+folders a couple years back).
Keywords: regression
bugzilla@ooofest.com(bug opener), do you see error like following in Error Console?
> Discovering folders for account failed with exception: [Exception...
> "Component returned failure code: 0x80550013 [nsIMsgFolder.subFolders]"
> nsresult: "0x80550013 (<unknown>)"
> location: "JS frame :: resource:///modules/MailUtils.js :: MailUtils_discoverFolders :: line 77"  data: no]

If Tb profile was created by Tb 12.0.1 en-US and is used by en-US version only, above error was not shown. However, once the Tb profile was used by localized Tb(Tb 12.0.1 ja in my case) and folders were shown in localized folder name, above error was shown for each account except Local Folders upon restart of Tb by both Tb en-US and Tb ja. If panacea.dat is deleted and all .msf of all Tb's special folders(Inbox.msf, Trash.msf, ...) are deleted and Tb en-US is restarted, all special folders were shown in original English name again and above error disappeared.

Above error doesn't seem to affect ordinal filter execution, but it may affect on filter execution in some circumstances.
Do you use localized Tb?
Did you use your Tb profile by Beta/Aurora/Trunk daily builds?

Do you see your problem with Tb's -safe-mode?
(thunderbird.exe -safe-mode. no Lightning) 

Do you see your problem with newly created profile by Tb 12 and a problematic POP3 account only?
Please don't forget to set "Leave Messages on Server" and to disable any auomatic mail deletion in your test.
(In reply to bugzilla from comment #0)
> However, if I close Thunderbird and reopen it, if that re-enabled filter is
> triggered for a new incoming email, I will receive the same error message
> shown above and its folder selection field value will once again be blanked
> out.

If auto-compact is enabled and is executed without prompt(mail.purge.ask=false), big different between "just after restart of Tb" and "after using Tb for a while" is "silent execution of auto-compact upon first mail download after restart and filter move". Once auto-compact is invoked, Tb won't schedule auto-compact again for an hour by "1 hour timer". This timer is reset to ZERO by restart of Tb. 
If auto-compact is invoked by filter move, and if auto-compact & filer move for other mail is executed cocurrently, filter move action may be interfered by auto-compact. And it may cause internal filter execution error and it may produce faked "folder not found" condition.  

Do you enable auto-compact? (Tools/Options/Advanced/Network&Disk Space, Disk Space)
If yes, is mail.purge.ask=true used? (via Tools/Options/Advanced/General, Config Editor)
(In reply to WADA from comment #9)
> bugzilla@ooofest.com(bug opener), do you see error like following in Error
> Console?
> > Discovering folders for account failed with exception: [Exception...
> > "Component returned failure code: 0x80550013 [nsIMsgFolder.subFolders]"

I do not see code 0x80550013 in the error log or dialogs that pop up when this error condition occurs.

> If Tb profile was created by Tb 12.0.1 en-US and is used by en-US version
> only, above error was not shown. However, once the Tb profile was used by
> localized Tb(Tb 12.0.1 ja in my case) and folders were shown in localized
> folder name, above error was shown for each account except Local Folders
> upon restart of Tb by both Tb en-US and Tb ja. If panacea.dat is deleted and
> all .msf of all Tb's special folders(Inbox.msf, Trash.msf, ...) are deleted
> and Tb en-US is restarted, all special folders were shown in original
> English name again and above error disappeared.

I am temporarily running an US system with Japan Locale settings (to help display proper fonts for another program), so deleted panacea.dat and all .msf files, then restart Thunderbird - same errors occurred.  I tried deleting and recreating one of the problem filters that cause this error condition and reset all conditions, but again the same error occurred.
 
> Do you use localized Tb?

I use an English Thunderbird, but it was upgraded to 12.0.1 on this Locale = Japan setting.  Thunderbird has been upgraded many times on this same temporary Locale setting (i.e., I switch back and forth).

> Did you use your Tb profile by Beta/Aurora/Trunk daily builds?

No, only the major releases that auto-update provide.

> Do you see your problem with Tb's -safe-mode?

Yes.

> Do you see your problem with newly created profile by Tb 12 and a
> problematic POP3 account only?

My profile was created before Thunderbird 12.0.1 and I only use POP3 with this account.

> Please don't forget to set "Leave Messages on Server" and to disable any
> auomatic mail deletion in your test.

OK - I have been recreating some of the trigger conditions by sending emails with specific subject values to help testing move along, but can leave messages on the server for now.
(In reply to WADA from comment #10)
> Do you enable auto-compact? (Tools/Options/Advanced/Network&Disk Space, Disk
> Space)

Yes, for when it detects that at least 20MB can be saved.

> If yes, is mail.purge.ask=true used? (via Tools/Options/Advanced/General,
> Config Editor)

This value was "false", so I set it to "true" and retried the test, but the same error condition occurred.
For what it's worth, without changing anything else in my system, I reverted back to Thunderbird 11.0.1 and Lightning 1.3 without making any changes, re-indexing, etc. and all looks + works as expected when it comes to the filters moving new mail into specified folders.
(In reply to David :Bienvenu from comment #7)
> If we don't think "Use%20and%20Buy/Products-Services/AMEX" exists when we
> try to run the filter, we'll disable the filter. Does the folder exist?

Could this be something like exiting on SetSpec() failure? Something what bug 186724 changed, but that only landed in TB13 so there would be an unexplained discrepancy.
What is the language of the user interface of your Thunderbird? Do you use a version other than English?
(In reply to :aceman from comment #15)
> What is the language of the user interface of your Thunderbird? Do you use a
> version other than English?

The language is English on Windows 7 Home Edition, though I've used a different Locale setting at various times to better support some specific applications (i.e., not Thunderbird).
So you downloaded the en-US version of Thunderbird?
(In reply to :aceman from comment #17)
> So you downloaded the en-US version of Thunderbird?

Yes.
Flags: in-testsuite?
Flags: in-litmus?
Blocks: 752866
Same happens for me on Win7 32-bit and on Linux 64-bit (Kubuntu 12.04 with TB 13.01, mozilla distribution).
On Win7 I reverted to 11.0.1 and then the problem is not there.
On Kubuntu I installed TB 13.0.1 and then copied my saved Win7 64-bit TB profile.

This profile (the one now used on Kubuntu), is a different one than the one used on Win7 32-bit. It was in an earlier incarnation copied from WinXP 32-bit to Win7 64-bit. On that Win7 64-bit system the same problem with the filters also occurred, and was no longer there when reverting back to TB 11.0.1. On Kubutu, with TB 13.0.1 the problem is there again.
Additional (to the previous comment) observation on the Linux 64-bit system: After opening TB, and attempting to move a message using the move button, sub-folders are not accessible in that menu. The sub-folders only become accessible once a message somewhere lower down in the tree has been opened.

Perhaps the issue for which this is a comment is related to that phenomenon. It looks as if TB is lazy in opening and listing available folders. While that is good in some situations, perhaps it is slightly too lazy.
I have observed something similar while changing code in the Extra Folder Columns extension. I loop over the subfolders of a folder using .subFolders and then .getNext() until .hasMoreElements() is false. This works for the 1st level of folders. However sometimes when getting into lower levels (2nd and more) the .getNext() call returns "undefined" so I can't get the properties of the folder I want. It happens on folders that are not yet visible in the folder pane, because their parent is collapsed. After uncollapsing the parrent these bad folders start to work fine and also after they are collapsed again.

Also, the folders are instantaneously fixed if in some account I open the Copy to menu on a msg and expand the list to see the problematic folders. It seems TB now fetches their data. After that they work fine in the loop I mentioned.

So it really looks like TB is not fetching folder properties even when they are requested in some cases. This is on TB 16a1.
To those who see the problem with filters:
Do you have all the target folders specified in the misbehaving filters visible/expanded in the left folder tree pane? Or are they collapsed (their parents have the + signed grippy)?
My folders are typically collapsed during each Thunderbird restart, when the filters run on new, incoming email.
Can you try leaving all the folders expanded (showing the "-" sign grippy) before TB restart?
. . . and, that was key: testing on v13.0.1 does reveal that the filters cannot find my subfolder when Thunderbird starts with all folders collapsed, which causes the error condition I reported at the beginning of this bug report.

However, if first I expand the folder tree to target folders for my filters, then restart Thunderbird, newly incoming emails on TB startup route correctly to those folders via the filters and the filters remain enabled.

Good find.
this implies that DiscoverSubFolders with deep = true isn't doing a true deep discovery for the berkeley mailbox store. I'll look into it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming that with all folders expanded in the tree before restarting TB, both issues are gone. The filters work as they should, and so does moving messages.
I also typically restart TB with all folders collapsed.

This is in the Linux environment. Haven't tried the Windows environment, yet.
Upgraded TB from 11.0.1 to 13.0.1 on Win7 32-bit. Same result: when starting TB with the trees expanded filters work alright, when starting TB with the trees collapsed the problem appears.
I've verified that DiscoverSubFolders with deep = true isn't doing a deep discovery. I couldn't reproduce the bug with a test profile because GetChildWithURI does a deep discovery as a side effect, which discovers all folders. In any case, this should be easy enough to fix by adding ".sbd" when trying to find child folders.
Assignee: nobody → dbienvenu
Status: NEW → ASSIGNED
Attached patch proposed fix — — Splinter Review 
this fixes it for me. I just have to check that it doesn't break any of our existing tests, and see if I can add a unit test for it.
For some reason I can't reproduce the problem with the extension on my Linux test install of TB16. I could try it out later if there is a trybuild for Windows where I see the problem consistently.
OK, now I somehow got the problem on linux. And after applying the patch it gets even worse so it does not fix it.
I can't say if it fixes the original reporter's problem.
(In reply to :aceman from comment #32)
> OK, now I somehow got the problem on linux. And after applying the patch it
> gets even worse so it does not fix it.
> I can't say if it fixes the original reporter's problem.

What does worse mean? Filters that weren't disabled before are now disabled?
Unfortunately, I don't have a local build environment for testing the proposed patch under Windows - is there a means for me to obtain this pre-built or should I look into establishing a development environment?
(In reply to bugzilla from comment #34)
> Unfortunately, I don't have a local build environment for testing the
> proposed patch under Windows - is there a means for me to obtain this
> pre-built or should I look into establishing a development environment?

David could produce you a trybuild for Windows.

(In reply to David :Bienvenu from comment #33)
> What does worse mean? Filters that weren't disabled before are now disabled?

My problem from comment 21 (which I suppose is caused by the same underlying issue) got worse. Some folders that were resolved fine before now fail (i.e. getNext() on subfolder iterator returns "undefined").
(In reply to :aceman from comment #21)
> I have observed something similar while changing code in the Extra Folder
> Columns extension. I loop over the subfolders of a folder using .subFolders
> and then .getNext() until .hasMoreElements() is false. 
Are you checking if a folder has subfolders before calling subFolders and getNext and hasMoreElements?
Yes, this is the code:
if (aFolder.hasSubFolders) {
  let subFolders = aFolder.subFolders;
  while (subFolders.hasMoreElements()) {
    let subFolder = subFolders.getNext();
    ... do stuff on subFolder and it throws as subFolder is sometimes "undefined" ...
  }
}
(In reply to :aceman from comment #37)
> Yes, this is the code:
> if (aFolder.hasSubFolders) {
>   let subFolders = aFolder.subFolders;
>   while (subFolders.hasMoreElements()) {
>     let subFolder = subFolders.getNext();
>     ... do stuff on subFolder and it throws as subFolder is sometimes
> "undefined" ...
>   }
> }

I'm really hard-pressed to see how that issue is related to this issue. Are you calling QI(Ci.nsIMsgFolder) on the subFolder before doing anything with it? And you don't have to check if a folder has sub folders, as long as it's while (hasMoreElements) instead of do { } while(hasMoreElements) - it was unclear from your previous comment.

Is it the first time through the loop that you're getting undefined, or are there sometimes subfolders and then the last one is undefined? dumping the aFolder.URI and then subFolder.URI might be helpful.
I do no QueryInterface(Ci.nsIMsgFolder) on subfolder, where should I add it?

The relation to this issue is this:
The undefined entries go away as soon as I expand some parent of the problematic folder.

The dump is like this:
Whole account is collapsed.

Timestamp: 25.6.2012 16:46:07
Error: mailbox://nobody@Local%20Folders/test6
Source File: chrome://extra-cols/content/main.js
Line: 69

Timestamp: 25.6.2012 16:46:07
Error: undefined
Source File: chrome://extra-cols/content/main.js
Line: 74

Timestamp: 25.6.2012 16:46:07
Error: undefined
Source File: chrome://extra-cols/content/main.js
Line: 69

(Line 69 is aFolder.URI, line 74 is subfolder.URI)
There is "test61" folder in "test6", and also "test611" in "test61". The "test611" is not even attempted as test61 fails. The loop runs fine as soon as I expand Local folders account.
let subFolder = subFolders.getNext().QueryInterface(Components.interfaces.nsIMsgFolder);
Well, that does help!
Why is it needed only starting at folders 2 levels deep?
(In reply to :aceman from comment #41)
> Well, that does help!
> Why is it needed only starting at folders 2 levels deep?

Maybe some xpcom wrapper caching? I really don't know.
Ok, thanks. So just ignore my comments on this bug starting at comment 21:)

I think I also see the problem reported here (after start of TB16, many of my filters have blank folder targets shown in the filter editor), but I have not yet looked into it if it is this bug or some of my other development.

Can you make a try-build for the guy wanting to test the patch on Windows?
(In reply to :aceman from comment #43)
> Can you make a try-build for the guy wanting to test the patch on Windows?

While I was trying to figure out your issue, I was working on a unit test for the bug and found some other odd things about folder discovery. I'm going to try to reproduce the issue inside TB before doing a try server build.
OK, I've finally reproduced this locally. It's a bit tricky because the following conditions need to be met:

The top level parent has to start with a name alphabetically after INBOX, or else looking for the INBOX causes us to discover all folders, including deeply nested children, before the INBOX.

All special folders in the account must exist (e.g., Sent, Drafts, Templates, Junk) if there are prefs that say to use those special folders, because if they don't exist, we conduct a rather exhaustive search looking for them, which causes us to discover all folders.
windows try server build with my patch should show up here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bienvenu@nventure.com-47091d294f1a
David, I am sorry for being unfamiliar with the build deliver system here, but I tried

thunderbird-16.0a1.en-US.win32.installer.exe	25-Jun-2012 16:15

at

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bienvenu@nventure.com-47091d294f1a/try-comm-central-win32/

and was able to recreate the same error condition which led off this bug report.

Should I be using a different daily build, perhaps?
it doesn't look like my patch got pushed to that try build. I'll try again tomorrow.
Sorry for the confusion; I think this build will have my fix:

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bienvenu@nventure.com-b660ac57bd00
Thanks David - unfortunately, that directory does not yet seem available, so I'll check back periodically.
(In reply to bugzilla from comment #50)
> Thanks David - unfortunately, that directory does not yet seem available, so
> I'll check back periodically.

sorry, I should have said it should be there in an hour or two.
(In reply to David :Bienvenu from comment #49)
third time's the charm? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bienvenu@nventure.com-8e206f657a87 - should be up in an hour or two.
(In reply to :aceman from comment #43)
> I think I also see the problem reported here (after start of TB16, many of
> my filters have blank folder targets shown in the filter editor), but I have
> not yet looked into it if it is this bug or some of my other development.

This manifests itself like this:
After start of TB I go into filter editor and Edit a filter that has a target in a collapsed folder. The folderpicker at the Copy action is blank. I close the dialog and Edit the filter again. Now the target appears correctly.

David, your patch seems to fix this problem for me (compiled myself on trunk on Linux). After the patch the target folder shows up at first open of filter edit dialog. Let's see what the reporter sees.
Comment on attachment 620691 [details]
Thunderbird error console values taken after the filter error message is shown

This attachment does not seem to contain anything helpful.
Attachment #620691 - Attachment is obsolete: true
Attachment #635919 - Flags: review?(neil)
David, the build at

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bienvenu@nventure.com-8e206f657a87/try-comm-central-win32/

worked normally in my testing and I could not reproduce the error condition which led to this bug report.

Looks good, thank you.
Comment on attachment 635919 [details] [diff] [review]
proposed fix

>-  nsresult AddSubFolders(nsIMsgFolder *parent, nsIFile *path, bool deep);
>+  nsresult AddSubFolders(nsIMsgFolder *parent, nsCOMPtr<nsIFile> &path, bool deep);
Since it wasn't clear from the quick skim of the patch that was all that I have time for right now, why this change?
(In reply to neil@parkwaycc.co.uk from comment #57)
> Comment on attachment 635919 [details] [diff] [review]
> proposed fix
> 
> >-  nsresult AddSubFolders(nsIMsgFolder *parent, nsIFile *path, bool deep);
> >+  nsresult AddSubFolders(nsIMsgFolder *parent, nsCOMPtr<nsIFile> &path, bool deep);
> Since it wasn't clear from the quick skim of the patch that was all that I
> have time for right now, why this change?

because I wanted to do

+    path = do_QueryInterface(dirFile);

and I already had a comptr handy...
(In reply to David Bienvenu from comment #58)
>  I wanted to do
> 
> +    path = do_QueryInterface(dirFile);

You hadn't noticed that we'd got rid of nsILocalFile?
Oh, I guess this needs to go on branches too...
Comment on attachment 635919 [details] [diff] [review]
proposed fix

r=me for branches which still use nsILocalFile, but for trunk, you could try using something like this:

nsresult rv;
nsCOMPtr<nsIFile> tmp; // at top level so we can safely assign to path
bool isDirectory;
path->IsDirectory(&isDirectory);
if (!isDirectory)
{
  rv = path->Clone(getter_AddRefs(tmp));
  NS_ENSURE_SUCCESS(rv, rb);
  path = tmp;
  nsAutoString leafName;
  path->GetLeafName(leafName);
etc.

But please remove the do_QueryInterface on trunk either way!
Attachment #635919 - Flags: review?(neil) → review+
http://hg.mozilla.org/comm-central/rev/304b06e5a6d4
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 16.0
Comment on attachment 638402 [details] [diff] [review]
patch for aurora (probably applies to beta as well)

[Triage Comment]
a=me for Aurora & beta, as I think we should fix this regression for the next release.
Attachment #638402 - Flags: approval-comm-beta+
Attachment #638402 - Flags: approval-comm-aurora+
For what it's worth, I can confirm that this fix worked after the v14.0 update automatically installed for my Thunderbird client today.

Thanks again!
Thanks for the confirmation.
Status: RESOLVED → VERIFIED
No longer blocks: 752866
There seems to have been some sort of reversion. 
I am having this problem with 24.1.0 and have been for some time.
I am sorry, I don't know exactly when it started.
I am using IMAP over SSL and the folder names meet the conditions outlined by David in comment 45.
System is Fedora 19 x64.

If I re-enable the filter by ticking the check box, without expanding the offending target folder, and re-run the filters, the filter is disabled again. If I expand and collapse the target folders parent, All is ok again. TB runs 24/7 on this desktop and the problem reappears periodically. Not sure what period yet.

Is there an option to say "Leave my filter settings alone. I know better than you what folders I have." ? This feature must be very annoying for road warriors who occasionally don't have access to some target folders, but would like the filters to just work next time they do.
It seems that the unit test from comment 44 was never attached so we do not detect regressions. David, would you be able to find it?
Flags: needinfo?(mozilla)
(In reply to :aceman from comment #75)
> It seems that the unit test from comment 44 was never attached so we do not
> detect regressions. David, would you be able to find it?

Bienvenu isn't active.  But this seems pretty important. Can you sort it out with someone else's help?
Flags: needinfo?(mozilla) → needinfo?(acelists)
No, I have no idea what Bienvenu had in mind.
Flags: needinfo?(acelists)
Depends on: 1070646
From my reading of this bug, it was about local folders, and the most recent reporter is using IMAP. Folder discovery is fairly different for IMAP. My first question would be whether jcmajor is using IMAP subscription or not. My guess is not, which opens up a whole raft of issues because we don't build up the whole folder tree with an LSUB of all folders.
In case it helps, here are some things that may or may not be playing a role here.

- I am using IMAP over SSL against dovecot + maildir. 
- The doveot is on ubuntu.
- I have changed distro from fedora to ubuntu 14 and the problem occurs less often but persists.
- For virtualisation, I have my eth port bridged (ie outside the control of NetworkManager) and this causes NetworkManager to misrepresent the connected status.
- I have not explicitly subscribed to any folders, however a subscription file does appear in my dovecot mail store. The entries in this file reference all folders and subfolders in the mail store, including the ones that vanish. The entries do not appear to be sorted at all except possibly in accidental order of folder creation.

I am following this thread, so feel free to request any further info that helps or to test something and I'll do my best.

At the very least, if it could stop changing my config for me, that would significantly reduce the irritation.

Regards
John
(In reply to David :Bienvenu from comment #78)
> From my reading of this bug, it was about local folders, and the most recent
> reporter is using IMAP. Folder discovery is fairly different for IMAP. My
> first question would be whether jcmajor is using IMAP subscription or not.
> My guess is not, which opens up a whole raft of issues because we don't
> build up the whole folder tree with an LSUB of all folders.

Thanks, but I was more interested in your comment 44, where you mention a unit test for the fix you have done here. Just whether you have the test lying around, because it seems you never attached it.
I started work on a unit test, but I don't have it anymore - My hard drive was wiped when I left and I wasn't able to save all my different trees.

And again, that unit test was for local mail folders, not imap folders, which require a completely different setup.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: