The Quick Filter UI's responsiveness is poor in large folders. The scenarios where I really observe this are mostly: I change the search term, but do an error and need to correct. I enter a search term for fields different from those used in the last Quick search. After any change to the search criteria, a refresh of the search results is immediately triggered, unless the search term is being modified through keyboard input, in which case there appears to be a ~1 s delay for performance. This bug will show in many scenarios, but the following example clearly demonstrates. In a 30484-message folder, performing a quick search for "asdfgh" on Recipients and Body takes approximately 30 s to display results (0 matches). So if the fields Recipients and Body have already been selected and I type "asdfgh" at normal speed, Thunderbird is done about 30 s after I start typing. However, if I start again from an empty term with the same fields preselected, but I intentionally trigger several searches by waiting 1 second between each keypress, it will take approximately 80 s for the search to complete. Since in this case my typing lasts for 8 seconds, it is normal that the whole process is longer, but the fact that it takes about a minute longer shows that Thunderbird is not optimized for gradual entry of quick search criteria. Unfortunately, it is also designed to launch quick searches automatically, so this scenario must be familiar to many (I have a hard time trusting Bugzilla when it tells me this wasn't already reported). The UI for search criteria is far from responsive. When I type slowly, letter-by-letter, the "a" appears immediately, but the "s" appears many seconds later. The other letters ("dfgh") appear at the same time, a lot later. After about 90 seconds, the tab icon stops spinning, and the search appears to be complete. But a few seconds later, the icon starts spinning again, so that the real end comes about 20 seconds after the first apparent end. I have crafted the Summary to help users searching for this ticket, but I have not looked at the code at all, and it is not clear for me what is going on. The whole process is faster than a sequential execution of each search, which suggests that the process may be somewhat threaded. But clearly, the search criteria UI's behavior shows that threads are far from being fully used. I consider it incoherent for the quick filter to launch automatically when it responds so poorly during a search - this could easily be considered as a bug. The above metrics were obtained on a desktop with a quad-core 3.4 GHz CPU and 8 GB of RAM with a profile stored on an SSD. The UI unresponsiveness is extremely easy to experience. The time measurements vary by a few seconds each time, but the difference between the 2 tests is always extremely clear. This happens on both Debian (Icedove) and Windows, and has been happening for years.

This has nothing to do with threading > In a 30484-message folder, performing a quick search for "asdfgh" on Recipients and Body takes approximately 30 s to display results (0 matches). So if the fields Recipients and Body have already been selected and I type "asdfgh" at normal speed, Thunderbird is done about 30 s after I start typing. > When I type slowly, letter-by-letter, the "a" appears immediately, but the "s" appears many seconds later. The other letters ("dfgh") appear at the same time, a lot later. After about 90 seconds, the tab icon stops spinning, and the search appears to be complete. But a few seconds later, the icon starts spinning again, so that the real end comes about 20 seconds after the first apparent end. First, let's be clear on the conditions. 1. Is it necessary for "recipient" to be selected for the problem to occur? If not, it is not part of the required steps to reproduce 2. If "body" is required to reproduce, then folder file size will be the relevant factor in performance, not number of messages. how big is the folder you are testing? (right+click folder, properties) 3. What is View | Folders set to? 4. imap folder, or local account folder?

Hi Wayne, (In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1) [...] > 3. What is View | Folders set to? All (default) > 4. imap folder, or local account folder? This happens with a Gmail account accessed using the IMAP protocol. I cannot reproduce my timings on the machine I described currently. There was no significant change to the Gmail account since I reported, and no change to Thunderbird's configuration. Thunderbird was restarted between the moment when I reported and now. I will report after more testing.

There are 2 issues described in this ticket: 1. The quick filter search criteria UI is unresponsive. 2. The time taken to complete a quick search grows tremendously when the entry of search criteria ends while a quick search is already underway. These issues may have distinct causes and fixes. If so, feel free to consider this ticket as being about 1, 2, or both. In the first cases, I will take care of filing a new ticket should the other issue persist. Issue #1 always reproduces, and has been happening for years (this is what I meant in Description). As Comment 2 shows, issue #2 does not always happen. I do not remember noticing issue #2 before filing this ticket.

(In reply to Filipus Klutiero from comment #2) [...] > > I cannot reproduce my timings on the machine I described currently. There > was no significant change to the Gmail account since I reported, and no > change to Thunderbird's configuration. Thunderbird was restarted between the > moment when I reported and now. I will report after more testing. I now experience issue #2 again on the machine I described. I have experienced twice in a row the timings originally describes, but then a couple of tests did not reproduce. I then reproduced several times with timings which I did not expect. I feel like exactly what happens depends on the timing of my typing. Waiting for too long between keypresses seems to yield different results. There might be both a lower and an upper limit on the delay between keypresses in order to reproduce, but I can hardly see why and what the upper limit would be. This is just a hypothesis.

On approximately 10 reproduction attempts, 3 times part of my entry was flushed. In 2 cases, "dfgh" was lost. In the last instance, only "a" was kept. Note that it is normal that the letters do not appear as soon as they are typed. What I am saying here is that they really never appear. I am way more than 99% confident that all of these cases were not due to some "error" on my side like mistakenly focusing out of the field.

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1) [...] > > > In a 30484-message folder, performing a quick search for "asdfgh" on Recipients and Body takes approximately 30 s to display results (0 matches). So if the fields Recipients and Body have already been selected and I type "asdfgh" at normal speed, Thunderbird is done about 30 s after I start typing. > > When I type slowly, letter-by-letter, the "a" appears immediately, but the "s" appears many seconds later. The other letters ("dfgh") appear at the same time, a lot later. After about 90 seconds, the tab icon stops spinning, and the search appears to be complete. But a few seconds later, the icon starts spinning again, so that the real end comes about 20 seconds after the first apparent end. > > First, let's be clear on the conditions. > 1. Is it necessary for "recipient" to be selected for the problem to occur? No. I can apparently reproduce issue #2 with whatever field selection. The timings vary depending on the fields selected, but there is no enormous difference - it is approximately equally easy to notice the problem whatever fields are selected. Verifying this allowed me to find a much better way to test. With just "Subject" selected, the relative difference between the immediate entry (between 2 and 4 seconds) and the letter-by-letter entry (about 65 seconds) timings is much higher. This high relative difference apparently happens as long as Body is not selected. [...] > 2. If "body" is required to reproduce, then folder file size will be the > relevant factor in performance, not number of messages. how big is the > folder you are testing? (right+click folder, properties) 29106 messages, 888 MB on "disk"

After restarting Thunderbird, I can once again no longer reproduce (at least 4 attempts). This appears related to the bug reported in ticket #1282244. Before I restarted, while I could reproduce, I would see 1 false positive (a mail which was received after the Thunderbird instance was started). The false positives described in that ticket would eventually go away, but I believe this false positive stayed until I restarted. This false positive no longer shows up since Thunderbird was restarted. The last instance on which I reproduced ran for 1 day or 2. Pretty much all I did with it was to clean up the account (tag some mails and delete others). I will keep trying to reproduce this on another machine.

We could say there are 3 problems here, if we separate from issue 1 the fact that in some cases, some of the letters typed are dropped. Let us call that issue 3. I believe I managed to reproduce issue 2 on another machine. There were no false positives in that case. After closing Thunderbird, the process remained until I killed it over 2 minutes later (but that machine has a mere 2 GB of RAM). When trying to reproduce, I reproduced issue 3, which means that reproduces on 2 machines on 2 tested.

I was able to reproduce issue 2 on my desktop for the third time. This also reproduced issue 3. This time the process ended right after I closed Thunderbird.

Also see bug 1055077, JSMime header parsing makes quick filter slow

(In reply to Ben Slade from comment #10) > Also see 1055077, JSMime header parsing makes quick filter slow Right. bug 1055077 is the main blocker