User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Sent messages take a lot of time to be indexed. They are indexed : - either if I restart Thunderbird, - or if I open the "Sent" folder. Although I have "Check this folder for new messages" checked for my sent folder, and imap.check_all_folders_for_new set to true, the messages don't get downloaded, and indexed, until I open the sent folder. This is quite annoying since they don't show up in search results. I'm designing an extension that allows you to see your own messages in threads (see https://addons.mozilla.org/en-US/thunderbird/addon/54035) and it's quite confusing to open up a thread and not find your own messages until you go look for them in the "Sent" folder. Reproducible: Always
Yeah, I'm seeing this too. I suspect we aren't generating the required notification for gloda to know about newly sent messages.
*** Bug 537019 has been marked as a duplicate of this bug. ***
*** Bug 540207 has been marked as a duplicate of this bug. ***
We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one. Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird. Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited. If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider. To qualify, this bug must either: a) make the upgrade experience from TB2 very painful for a large number of users or b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes) Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release. Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.
sid0 or bienvenu, any chance of having the cycles to fix the generation of notifications for newly sent mail in the sent folder for beta 2?
Given where we are, not going to try and assign this to a 3.0 release as it is more appropriate in a later release.
:bienvenu, :asuth, given the current activity around these issues, do you think we could target a fix for the 3.3 release?
(In reply to comment #7) > :bienvenu, :asuth, given the current activity around these issues, do you think > we could target a fix for the 3.3 release? I'm trying to get it into 3.3 but it doesn't block 3.3, I don't believe.
Created attachment 504159 [details] [diff] [review] v1 utilize the new msgKeyChanged notification This patch depends on the fix from bug 574441. The focal point of the patch is that the gloda move test has been modified to use "fast-path" offline operations in the "move it there" case and (continue to) not to use offline operations in the "move it back". We verify that in the fast-path case gloda does not attempt to reindex the message but in the slow-path case it does. (Gloda will still generate itemsModified notifications, though.) We also verify that the book-keeping dictionary does not leak cruft. I also used logsploder to make sure the event sequence in the tests looks sane.
pushed to trunk: http://hg.mozilla.org/comm-central/rev/afa759fe196c
protz makes a good point in IRC that we didn't actually fix what the subject of this bug is about, so I am reopening. The patch I landed is a nice patch, but I only put it on this bug because it seemed like gloda should otherwise already be doing all the right things and the dependency suggested this was a good place to put it. We should only close this bug once we have a test that verifies the thing the subject says. I have no idea why the desired result is not happening, and a further complication is that I'm not entirely sure our current test framework allows us to realistically test the situation. (At least, the gloda framework. Gloda forces updateFolders...) protz, if you would like to pursue this or otherwise look into it, please be my guest :)
protz, what amount of delay do you typically see? (don't think I've ever seen this - perhaps I have immunity because I configure Sent pointing to Inbox, and put replies in same folder as original)
*** Bug 640553 has been marked as a duplicate of this bug. ***
The issue I describe here was just fixed by bug 646226.
or
