Open Bug 1953811 Opened 2 months ago Updated 18 days ago

UI delays at all times, even when just entering text with Gnome + Wayland

Categories

(Thunderbird :: Message Reader UI, defect)

Product:
Thunderbird
Component:
Message Reader UI
Version:
Thunderbird 128
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: nick.theboatman, Unassigned)

Details

(Keywords: perf)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Steps to reproduce:

This is reopening bug 1867219 (which should never have been closed because the issue has been getting worse, not "fixed").
Using Ubunty 24.04 with LXQT 2.0.0.
Summary from last time - the UI runs very slowly; when changing the width of a pane the UI hangs for 35 seconds; since Christmas 2024 (whichever TB version that was) the UI has slowed in general (as in 5-10 seconds to do anything; opening a sub-directory mailbox seems to take forever); secondly the inbox (in particular) stops displaying messages - 450-odd there. They come back after shutting TB and restarting it.

I noticed this:
A A trouble bubble popped up saying "cant access mailbox blah (10-deep), check disk space and permissions". Plenty of disk space; mailbox file is 600, msf file is 664, group is me - so no issue there, meaning that the trouble bubble is defective in its diagnostic, but moving on.

What I noticed was that simultaneously the mailbox content ceased to display (32 messages) BUT

B the UI now sped up to a vaguely usable speed... just that no mailbox contents were displaying.

As (possibly) a separate issue at the top of the year I create new mailboxes for the subject traffic for that year. I do this with a script generating an empty mailbox file and a dummy msf file, and possibly the directory structure with directories called sbd - at least to access the bottom of the trees. For some reason the mailbox files were being created with a single cr at the beginning. Mails coming in were getting filtered to the right mailbox and included ok. But they would not display. The mailbox that bought this to light had 20 messages in it but these were not showing (empty mailbox). Bit of a problem - I missed several meetings as a result.
Repairing the mailbox had mo effect. I found that by removing the leading cr the mailbox then showed all of its contents. Also I noticed that the UI sped up again - almost as if the attempt to reindex the mailbox crashed some thread.
This may be a completely different issue of course - or not...
I haven't bothered getting Wireshark out yet but I also suspect that there is traffic on the uplink (one of the mail accounts is IMAP and there is several GB of mail on the server).

Meanwhile and in the grand scheme of things this has been getting so bad I have been considering porting out to something else. The problem is there is nothing else....

Ideas?

Actual results:

Poor UI speed; mailboxes showing as empty when they are not

Expected results:

Descent UI speed; show the mailbox properly

Firstly, thanks for filing a bug report.

(In reply to Nick Brown from comment #0)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
This is reopening bug 1867219 (which should never have been closed because the issue has been getting worse, not "fixed").

An educational side note - bug 1867219 was not closed because there was a thought that all problems in that realm where gone - take note it was closed "incomplete", not fixed nor worksforme. It was closed because a) the reporter was no longer responding making it impossible to verify their current status and test fixes, and b) all (or the majority) of users in that bug report either reported success or their symptoms where covered in other bug reports (ref. bug 1875103 comment 38, unfortunately such a bug query was not mentioned in bug 1867219).

More generally, bugs which stagnate (i.e. unlikely to have a path forward) tend to get closed as incomplete, which I know can be upsetting to users. But in cases like this, moving to other still open bug reports which have good data or engaged users, or new bug reports with new data and vigor, have far better odds of making progress. For example Bug 1860094 - Pane resizing is slow for a second or so before display update - which shipped last week in 128.8.0esr.

Are you using 128.8.0?

Ideas?

If your problem is not gone in 128.8.0, then as cited in bug 1867219 please do https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance.

Slightly better bug query for this issue https://mzl.la/3DGtTCj

Flags: needinfo?(nick.theboatman)
Keywords: perf
Summary: UI delays at all times, even when just entering text with Gnome + Wayland #2 → UI delays at all times, even when just entering text with Gnome + Wayland

Thanks Wayne - apologies I don't keep on top of the bug reports here...just reporting when I find something that is an issue.

On it !
N

Flags: needinfo?(nick.theboatman)

Updates:

  1. TB version is 128.8.1esr (64-bit) running on Kubuntu 14.04 and KDE (when I posted this thread I was on Ubuntu with LXQT: now new machine, new OS, see below)

  2. I haven't done any profiling yet - I did reboot TB in debug mode (thus switching off plugins etc) but this didn't change anything. So diagnostics a little "contextual" if you know what I mean.

  3. Now on a new machine (as above) that is faster (4 cores rather than 2) but also uses a NVMe disk rather than a spinning disk - which seems to have accentuated some problems.

  4. The "resize columns" and "resize panes" function is now seamless - no delay whatsoever.

  5. The "message panel going blank" problem (so inbox has 455 messages in it; I have maybe 50 filters operating; regularly I get an error bubble stating "can't access mailbox blah (10-deep), check disk space and permissions" which then blanks the message pane pparently without recovery apart from closing TB and restarting). I spotted that if I put a "z" into the "quick filter" field (so that it is forced to scan the messages for a "z" - it redraws and all the messages come back. All of them (I cant believe that every message has a "z" in it...)

Anyway this is looking remarkably like a redraw problem after an error message bubble comes up. Or, put another way, the error message bubble causes a blanking of the message pane which then does not get redrawn. Putting the "z" in forces a redraw. A work around at any rate.

Meanwhile the column resizing issue was drawing me towards some issue with Wayland but that might equally have been an LXQT problem (ie upstream of TB itself). Quite frankly I found LXQT to be so flaky that I dumped it and went to KDE, boatiness or otherwise.

Onwards and upwards...

Further update.
AGH !!
The app has been updating overnight and now returns 128.9.1esr (64-bit)
The redraw bug work-around now doesn't work around any more, rendering TB pretty much unusable. I haven't been able to spot a different work-around yet.

Any updates on the bug-fix? This is posted as "unclassified" and "not allocated".

Thanks

You can also try v137. Available at least from https://thunderbird.net

I'll have a go ;)

Work-around #2: the bug relates to the message summary only (as in the list of messages in the mailbox, not the preview in the preview pane; I had the bizarre vista of a message displayed in the preview pane but the summary list [above it] was empty).

Work-around #2: click on one of the filter buttons (eg "Attachment" and back off again) and the pane redraws. Job done (for now).

You need to log in before you can comment on or make changes to this bug.