Search Messages window loses result display in status bar "xx matches found" after a fraction of a second
Categories
(Thunderbird :: Search, defect)
Tracking
(Not tracked)
People
(Reporter: francesco, Unassigned, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Search Messages window loses result display in status bar "xx matches found" after a fraction of a second.
Likely regressed by bug 1901846. Overall the implementation in that bug to show each message for 750ms and to only drop messages when the queue is longer than 10 entries doesn't appear to be correct. For example when moving many messages, the folder count in the folder tree is way ahead of the status bar display. If I interpret it correctly, the last message in the queue will be displayed after 7.5 seconds when it is no longer relevant.
| Comment hidden (metoo) |
|
||
Comment 2•9 months ago
|
||
Not sure if this is the same issue, but I've seen this when trying to copy, e.g., 100 messages. When it successfully finishes, in status bar I see final "75 of 100" and not a final message "100 of 100".
|
||
Comment 5•14 days ago
|
||
Wait, status messages are dropped after being held back by other stuff long enough? Sorry, but that appears very stupid to me.
Here's a suggestion: If you want, show messages for a minimum time span. But then only drop those messages that are no longer relevant, like "looking up server", "connecting to server", "fetching stuff". That's nice to know while it's lasting longer, but I don't want to see that long after it's finished. And usually those activities are finished in milliseconds. Then keep those messages that indicate a final state, like "message moved" or, in my case, "compressing done, 123 MB freed". Never drop any message of that category.
This may mean that status messages need an indication of whether they're indefinitely relevant/interesting, or messages of already completed activities might need to be marked as obsolete so that they don't even need to be shown when it would be their turn in the queue. Or simply keep track of such temporary messages inside the task and when done remove them from the queue, whether they've been displayed already or not.
Also, as the "compressing done" type message should come last, don't reorder messages in the queue, and that most interesting message will be there in the end. That would be correct behaviour. Not blindly dropping anything because of its caused age.
The same applies to the status progress bar. That usually goes wild and often stays stuck in the middle at the end. So the user never knows what's going on. Is it done? Is it safe to close the app now? Is it stuck? Do I need to be worried about my data being corrupted this time?
Actually, progress bar updates don't need to be shown for a minimum amount of time. Always keep them up-to-date. There's no point that the user certainly gets to know that the process was once at 45% before it went to 80%. Again, the progress bar is only interesting to the user if something takes longer.
All in all, this chaos gives the user the impression that Thunderbird runs very uncontrolled and unreliable. And Thunderbird in fact is unreliable. It has lost my mbox data files or folder index files more than once. Mostly I guess because of too quick interactions. So synchronisation is a problem here. I want to be extra careful and not make Thunderbird do two things at once. (Actually I shouldn't need care about that, but I do.) Therefore, I need to know when something is finished. Thunderbird can't even tell me that right now.
Description
•