Quick FIlter should not begin until I stop typing the search terms
Categories
(Thunderbird :: Search, defect)
Tracking
(Not tracked)
People
(Reporter: steevo, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
I use the message search function. It might be quick search. The second one, that searches the one folder or account.
When I type a search term to find matching messages, the search begins searching as soon as I type the first character. I have many messages so this causes a very serious performance problem.
Essentially the system stalls on the first or second character and other characters typed are not entered, and the rotating wait symbol in the screen is spinning.
It might be 10 or 20 seconds or more before control of the system returns to me and more chars can be typed.
Actual results:
The search begins immediately, and the system stalls.
Expected results:
The search begins immediately, but it should not begin until I click enter.
|
||
Comment 1•4 years ago
|
||
Thanks. This is covered by bug 944942
Wayne, that's seven years old. It's hardly what I would call covered, unless covered just means we know about it.
The thing about Thunderbird, it's about the only email client that I have found that can gracefully check my 20 addresses.
I realize a lot of "users" today just use a phone app or webmail, so there is a need for a client that can do what I need it to do.
I migrated from Eudora, which had lightning fast X1 search built in. I wonder what that X1 thing is and does it still work?
I was a mail administrator some years ago, and a spam analyst. So power user, sure.
I am no one's developer, so I don't know how to fix this. But I know the smart guys do know how. I hope.
Seven years is a long time. Is anyone going to work on this?
I think the easiest fix would be to add a button to start search after the search terms are typed. so if you make a mistake typing you can correct before you begin.
|
|
||
Comment 4•4 years ago
|
||
It is pretty evident from looking at the lack of activity in the bugs that no one is working on this.
We tend not to use "fixes" that add preferences or work for the user, and that avoid fixing underlying issues. Performance degraded when a mime change was made many years ago, so one of the underlying issues is bug 1055077. It's not near the top of things to be worked on.
Wayne,
Well, there are actually two issues here.
The mime change that has not been addressed, and the main problem that the quicksearch starts trying to search when you type the first character. If that didn't start until invoked this performance problem might be mostly solved. Because searching for a search term the user didn't need to search for is just nonsense. It would be OK if it took no time, so maybe the mime search problem if ever solved might resolve the performance problem. But that is just part of the problem.
Right now typing an "a" in the quicksearch box commences a search for "a" but you might have meant to search for "asparagus." No need to have a performance problem searching for something you never needed to search for. Not starting the search until your query is done would address that issue.
So two problems, an underlying performance problem, and a search UI architecture problem.
Is that a different way of looking at the issue?
|
|
||
Comment 6•4 years ago
|
||
What you are seeing and describing is stated at bug 1055077 comment 0. So the solution is to fix bug 1055077
Wayne,
Except that jsmime issue has languished for over 6 years. As of now it seems that is #WontFix. Let's just accept that for the moment.
So the problem with the search starting earlier than the user wants still remains. If we have to wait for something that will never be fixed to address this defect, well, that is a quite puritanical approach to this issue. And yeah, I have been involved in discussions on Bugzilla before that had some of the devs insisting on such a puritanical approach to the problem that it will never be fixed.
This should be fixed as a search invoked early issue.
If the problem caused by the jsmime problem is ever fixed and it seems unlikely after all these years, the search function not being started early is still valid. Because the used didn't want to search for a, as, asp, he wanted to search for asparagus.
Description
•