1875103 - Deleting or moving a message from the message list pane, message preview for next message is slow, up to 2 minutes to appear. Progress bar is in "indeterminate" state

Status: NEW

(Thunderbird :: Folder and Message Lists, defect, P2)

Description

[Cliff_G]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Steps to reproduce:

Open TB (classic view). In any folder containing more than one message, including Inbox or any subfolder, delete a message or move a message to another folder (drag and drop to the folder tree pane). In the top right message list pane, the selected message correctly moves to the next relevant message in the list. However, the message preview pane (bottom right) fails to display the appropriate message.

If you group messages (multi-select using ctrl+select) and move those, the messages can sometimes take a long time to move, seemingly the move has not occurred.

Other actions, such as scrolling the message pane, selecting a drop-down menu, etc, are not affected and the program does not appear to have otherwise frozen.

Actual results:

The newly-focused message preview eventually appears, this may take anything up to 30 seconds. This delay often occurs, however, the correct behaviour (immediate display of the preview) can also occur. I have not managed to track down the difference between the two behaviours.

If you group messages (multi-select usign ctrl+select) and move the grouped messages to another folder, the messages can sometimes take a long time to move, seemingly the move has not occurred.

Sometimes, having moved or deleted messages, then selecting a message in the message list pane will cause the message details (from/to/subject etc) to instantly change to read other details, although the position of that message on the screen has not changed.

When the immediate preview display fails, manually selecting a different message will also fail to immediately display the preview text for that message

This is in 115.6.1. After deleting or moving messages, the CPU usage increases and I am fairly sure these two events are linked. The CPU reduces again after a minute or two. (115 uses a higher CPU load anyway than my previous pre-update version (68).)

It also occurred in 115.6.0 but was not fixed by the high CPU fix.

Windows 10 Home.

Expected results:

The new message preview should appear immediately on selection of the next relevant message.

Comment 1

[Cliff_G]

To clarify: "It also occurred in 115.6.0 but was not fixed by the high CPU fix". The bug reported here also occurred in 115.6.0 (as far as I can recall), however, the 115.6.1 fix for the very high CPU (100% in my case) caused by the IMAP CONDSTORE issue has been fixed ok for me. My general view is that TB 115.6.1 uses a higher CPU than 68 did, and that this could be linked to the preview delay report here.

Comment 2

[Cliff_G]

Additional: This problem persists in spite of compacting all folders

Comment 3

[Cliff_G]

Clarification: this is for a POP3 account, all mail on my hard drive

Comment 4

[Cliff_G]

Related bugs?

Bug 533499, Bug 1551343, Bug 714489, Bug 1864713 may relate.

These all look to be the parsing of the folder file for display of the message in the Preview Pane, and also sometimes correct dispplay in the message list pane.

This is an annoying and worrying bug when you have been trying to tidy up email filing by deleting messages, moving messages to other folders etc., particularly when the message details in the messages list change as you step through! The delay alone makes moving messages unusuable at times. I hope this can be reproduced and fixed asap.

If I can assist with debugging please advise.

Comment 5

[Cliff_G]

Additional: the POP mail concerned is not stored on my C: drive - configured to be stored under local directory E:\Thunderbird\Mail\mydomainname.co.uk.

Comment 6

[Cliff_G]

A few more bits of info:

1. I cleared the cache - settings/general/disk space/clear cache. Made no difference.
2. If you close and re-open the preview pane (using F8 key) during the waiting period this makes no difference, preview text display still very delayed.
3. Whilst I said above that other parts e.g. drop-down menus, seemed to be working ok, during further testing I found I could not open a drop-down menu until after the preview message text was finally displayed.
4. I can reproduce this pretty easily - worst when the folder contains a lot of mails (unsurprisingly?)
5. when there is a delay displaying the preview text, double clicking the affected message in the message list does not open the message until after the preview display responds.

Comment 7

[Cliff_G]

/cont...
6. the total mail size under the POP3 account is 8.5GB, 8500 files, 250 folders. (worked fine with TB 68).
7. the bug also occurs on an IMAP account I have (Gmail)

Comment 8

[Cliff_G]

8. does not make a difference if the messages are displayed as threaded or not

Comment 9

[Cliff_G]

9. if, having moved a message, and during the wait for the message preview to update, you go to the folder to which you have moved a message, that message is present in the other folder. If you then go back to the folder from where it was moved, the display can still be lagging.

Comment 10

[Francesco]

Bugs 533499, 1551343, 714489, 1864713 may relate.

Can you please write bug 533499, bug 1551343, bug 714489, bug 1864713 so it get's linkified.

Comment 11

[Cliff_G]

Thanks Francesco. I'm new here so don't have my head around what this platform can do. I assume this is automatic link construction and that I don't need to do the html? We shall see...

So, repeating:

Related bugs?

bug 533499, bug 1551343, bug 714489, bug 1864713 may relate.

These all look to be the parsing of the folder file for display of the message in the Preview Pane, and also sometimes correct dispplay in the message list pane.

This is an annoying and worrying bug when you have been trying to tidy up email filing by deleting messages, moving messages to other folders etc., particularly when the message details in the messages list change as you step through! The delay alone makes moving messages unusuable at times. I hope this can be reproduced and fixed asap.

If I can assist with debugging please advise.

Comment 12

[Cliff_G]

Question: I've read somewhere that over the years TB has used two different folder & file structures. If true, this would be a sensible place for me to dig deeper. My total TB mailbase goes back to the late 90's, and though I've upgraded many times, that data files have been there all along, unchanged in terms of the old mail, and only added to with new mail receipt and filing. POP all the while, and in a specfifed local folder off the C: drive.

So, can anyone shed light on this?

And if you right click a folder and select Properties, there's a repair option. How is this different from compacting? This is another route for investigation.

TIA

Comment 13

[Cliff_G]

Further info: repairing the folder does not help (right click the folder, Properties, Repair folder

Comment 14

[Cliff_G]

Further debugging:

• When the wait is under way, the bottom notification bar text, bottom left, is "Loading message"
• for a folder of 178 MB and 910 messages, after moving one message out to another folder (drag and drop) the wait for the new-focus message is 1 minute 15 seconds to 1 minute 30 seconds. Sometimes the header display area of the new-focus e-mail will display in a few seconds (<5) but not the body. Normally, however, the header info displayed remains as per the email just moved out of this folder.
• For moving a file out of a folder of 360kB, 12 messages, the wait period to see the new-focus email is 5 seconds.

So it's related to folder size.

Comment 15

[Cliff_G]

Attachment: Showing CPU elevation when loading a new-focus message header and body

This clearly shows that whilst Thunderbird is determining what header and body text information to display in the message pane, the CPU goes high. Totally reproducible, this jpg shows 5 periods when no move was under way (the red arrows) and 4 inbetween periods when a move was under way. Each of these periods shown was for moving a single file out of a folder of 186 MB and 910 files

Comment 16

[Cliff_G]

I'd appreciate some feedback and advice on how to set debug parameters. I've got as far as this page: https://wiki.mozilla.org/MailNews:Logging no idea what to do next.

Comment 17

[Cliff_G]

*** WORKAROUND ***

Roll back to 102.15.1 :) Problem all gone, messages load instantly.

(This widens the message list pane vertical spacing, though. Grrr.)

Comment 18

[Cliff_G]

And the high CPU disappears, too, going back to 102

Comment 19

[Matt]

Have you tried starting Thunderbird in troubleshooting mode on a system running in safe mode with networking. The results of both test would be necessary to determine if we are dealing with a Thunderbird internal issue really.

While there have been issues of high bandwidth and high memory and CPU use in the 115 release, still the majority of folk with issues do not have an issue with Thunderbird, but usually a third party product like and antivirus or networking.

Comment 20

[Cliff_G]

(In reply to Matt from comment #19)

Have you tried starting Thunderbird in troubleshooting mode on a system running in safe mode with networking. The results of both test would be necessary to determine if we are dealing with a Thunderbird internal issue really.

While there have been issues of high bandwidth and high memory and CPU use in the 115 release, still the majority of folk with issues do not have an issue with Thunderbird, but usually a third party product like and antivirus or networking.

I will try and do this when I have time. However, the fact that the bug is completely and instantly fixed by rolling back to 102.15.1, with no other changes to the OS or other settings, suggests strongly to me it is in the Supernova changes from 102 to 115. It is a highly specific slowness, affecting only one part of TB, and not a general slow response.

Comment 21

[Wayne Mery (:wsmwk)]

Please update to the newest version, and do https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance

Comment 22

[Cliff_G]

OK, done that. Profile is at https://share.firefox.dev/42qQivu

That was a single move of a file from a large folder (178MB) to a small test folder. I tried multiple moves but the dump file got too big. I hope this helps. TB took about 1 minute+ to dispplay the correct message after the move.

This was on 115.7.0 and this version is still displaying the problem

Side note: for the instructions on using the profiler, there is now(?) no Stop Recording button, only a Capture recording.

Can you also advise where this debug data is stored if on my hard drive, so I can delete it. Thanks

Comment 23

[Cliff_G]

Apologies for the bold font above, I had not meant to shout. I think this was a side-effect of putting in a divider of hyphens before the side note

aaa

sdsdsa

Yes indeed

Comment 24

[Cliff_G]

Wayne, did that help?

I have found that the bug causes increasing delays over time even in the inbox when moving or deleting messages, probably cause by increasing fragmentation of the inbox as messages are processed over the days. However, the delay does seem to disappear if you compact the inbox.

I've just gone to 115.8.0 and the bug is still there, though the release notes don't suggest to me that anything relevant has changed.

Comment 25

[Wayne Mery (:wsmwk)]

It's all paint activity. Probably in the message list?

Comment 26

[Geoff Lankow (:darktrojan)]

This is just a hunch, but what happens if you hide the status bar? In the menu under View > Toolbars > Status Bar.

Comment 27

[Cliff_G]

(In reply to Geoff Lankow (:darktrojan) from comment #26)

This is just a hunch, but what happens if you hide the status bar? In the menu under View > Toolbars > Status Bar.

It is certainly much better behaved without the status bar displayed, and I'd say that's a suitable workaround rather than downgrading. I have had one or two freezes, but persisted with testing and mostly there's no delay in displaying the next message in focus when the status bar is not displayed. You can even select then move multiple messages and the next is displayed immediately - that's really slow with the status bar on. With the status bar displayed, immediately after the move it says "Moving x of x messages" (where x = no. of messages) then after ~1 second: "Loading message" until such time as it does load the message (many seconds, even minutes).

Great work. What was the hunch?

Incidentally, during a typical delay period (testing multi-move with status bar on), whilst some of the screen was inaccessible & didn't work (such as menu items) I was able to scroll down the folder pane to the same ([e-mail]) email account IMAP version, and see and open an email on the server with no delay. So it looks a littel like the problem is ring-fenced to the account doing the move/delete (which in this case is a POP, though whether that's important I don't know).

Comment 28

[Cliff_G]

@Wayne Mery (:wsmwk) how does bug 683651 relate? My bug is totally on the machine, in a POP account of already filed mail deep in the folder tree where I am doing tidying up.

Comment 29

[Geoff Lankow (:darktrojan)]

(In reply to Cliff_G from comment #27)

Great work. What was the hunch?

I noticed that the screenshots in your performance profile showed the progress bar in the "indeterminate" state (the coloured patch scrolls from one side to the other) and it coincided with the heavy graphics workload. We've had problems like this before, but for different reasons – we rebuilt that progress bar completely to avoid them. Looks like we still have problems.

Could you go to the Troubleshooting Information page (on the Help menu), copy the data into a text file, and attach the file to this bug? We'll get somebody from graphics to have a look at this.

Comment 30

[Cliff_G]

Attachment: Bug 1875103 troubleshooting text file.txt

as requested

Comment 31

[Cliff_G]

Workaround

(highlighting this from amongst a longish thread)

To avoid this problem in use, the workaround is to turn off the Status Bar at the bottom of the screen - View/Toolbars/untick Status Bar.

Comment 32

[Wayne Mery (:wsmwk)]

Does this reproduce with version 128?

Comment 33

[Cliff_G]

Wayne, I'll check on that but it may be a couple of weeks as unwell at present. C.

Comment 34

[Cliff_G]

@Wayne Mery (:wsmwk) Having now looked at this, I see 128 is not fully released yet, and that once upgraded I can't go back, so I shall have to defer testing this until 128 progresses to firm status. The status bar turn-off workaround is adequate for now. I've left the needinfo flag set

Comment 35

[Wayne Mery (:wsmwk)]

Cliff, 128 is now considered solid.