Open Bug 1860094 Opened 1 year ago Updated 11 days ago

Pane resizing is slow for a second or so before display update

Categories

(Thunderbird :: Folder and Message Lists, defect)

Thunderbird 115
Unspecified
Linux
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: lancelot, Unassigned, NeedInfo)

References

Details

(Keywords: perf:responsiveness, regression, regressionwindow-wanted, Whiteboard: [needs performance profile])

Attachments

(5 files)

Steps to reproduce:

On Debian Linux/XFCE, resize a pane by clicking on the horizontal pane border between either the message list (above) and one message (below) or by clicking on the vertical pane border delimiting folders (left) and messages (right).

Actual results:

Thunderbird display freezes for a second or so before display update.

Expected results:

Smooth resizing, as before (actually, this issue happened a few months ago, with a former version; also note that window resizing works fine, only pane resizing malfunctions).

FYI, I just noticed that the issue only happens in the email tab, not in the calendar tab whose panes resize smoothly.

Does the problem reproduce after Help > Troubleshoot mode?

Flags: needinfo?(lancelot)

Unfortunately yes, I already tried.

Flags: needinfo?(lancelot)
OS: Unspecified → Linux

Please install Thunderbird from https://www.thunderbird.net/en-US/ and please create a performance profile https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance. Thanks

Flags: needinfo?(lancelot)

I suspect this is going to be the message list refreshing

Component: Mail Window Front End → Folder and Message Lists
Summary: Pane resizing is slow / freezes temporarily → Pane resizing is slow for a second or so before display update
Whiteboard: [closeme 2024-01-15]

debian folk,

Can you comment please - do you see the behavior of comment 0. "resize a pane by clicking on the horizontal pane border between either the message list (above) and one message (below) or by clicking on the vertical pane border delimiting folders (left) and messages (right)."

Yes / No ?

Flags: needinfo?(lancelot)
Whiteboard: [closeme 2024-01-15] → [closeme 2024-02-15]
See Also: → 1867219

A little update by the way:

  • I still observe the lag with version 115.6.0 on Debian + XFCE (X11, no Wayland).
  • I also notice that I can move smoothly the horizontal pane border between a message (above) and an attachment (below). This one works fine.

What message threading and sort setting are you using? Including, is group by sort enabled?

Most of the time, messages are sorted by date without message threading.

I rarely resize panes. I have tried on Debian 12 bookworm, KDE, X11, a folder with 100 messages. My observation is small delay that I may expect from events debounce (if thunderbird UI use it).

I have experienced issues with Firefox not updating its windows (e.g. switching to another tab) or popups for a few seconds. It happens in LXC containers with bind-mounted X11 sockets directory and /dev/dri. I have not figured out yet what may cause such delays.

Whiteboard: [closeme 2024-02-15]

The probem is still there (115.8.0).

I tried to disable display Total message count and Show folder size, on the left pane but it does not make any difference
(I don't know if this is relevant, but I have 20+ accounts on the left pane).

To comment on max who mentioned one folder with 100 messages: in my case, the lag happens even if
I have 5 messages in the account.

Hi Lancelot, I wasn't able to reproduce the issue. I have a Debian 12 VM with XFCE. From thunderbird.net, I downloaded the 115.8.0 tarball and ran that thunderbird executable. Attached you can see a short screen capture of thunderbird resizing window and there's no real lag I see.

@heather, thank you for trying to reproduce the issue. As @lancelot wrote “horizontal pane border”, I believe they use a different view. Also, you only have one message in the inbox. I’d suggest to populate it with at least a thousand test messages or so.

Comment on attachment 9389240 [details]
Screenshot_2024-03-04_22-58-16b.jpg

Thanks Heather. Indeed, as Paul noticed, I am using a different display.

Sorry, in the initial description, he said both...
" or by clicking on the vertical pane border delimiting folders (left) and messages (right)."

I tested the horizontal view too and still did not see the issue.

This is with x11.

@lancelot, I wonder if you watch your system's resources, are they spiking when you're trying to resize and you see the lag? When you say you're using a different display, do you mean a secondary monitor?
(In reply to Paul Menzel from comment #13)

@heather, thank you for trying to reproduce the issue. As @lancelot wrote “horizontal pane border”, I believe they use a different view. Also, you only have one message in the inbox. I’d suggest to populate it with at least a thousand test messages or so.

I can try with more messages but a thousand seems excessive since he said "in my case, the lag happens even if
I have 5 messages in the account."

@heather, as a matter of fact, you are right, it indeed also affects the vertical pane border.

Even after loading a second email account (that has 800 emails), and using the classic view with the horizontal line, I do not see a lag. I can't post a video of it since it's a real email account. So perhaps this has something to do with the number of accounts? I don't have 20+ accounts to test with. lancelot, do you see the issue if you run thunderbird with just one or two accounts?

I wrote "different display" to explain that a message actually appears below the list of message, not as in the video you posted. I am not using another screen.

Regarding resources, Thunderbird uses about 1.15Gb RAM (3,6% of 32Gb) and I do not see it spiking, nor the CPU (but the lag only happens for 1 second).

I created a Thunderbird account from scratch for another user and I do not see any lag there: the number of accounts may matter.

Right, I've tested the classic view (the second video I uploaded) as well. I continued to test the classic view (where the message is below the table of messages) when I added a second account.

This might be related to the fixes that we're introducing in bug 1883550.
It would be interesting to see if this problem goes away after that patch lands on Daily.

See Also: → 1883550

(In reply to Alessandro Castellani [:aleca] from comment #22)

This might be related to the fixes that we're introducing in bug 1883550.
It would be interesting to see if this problem goes away after that patch lands on Daily.

How can I test that?

Attached image column_resizing.jpg

Note that the lag also occurs whenever I resize any column withing the message list.
This happens even when there are only four messages in the list.

Depends on: 1883550
See Also: 1883550

Hi, I just wanted to add, that this is not just a linux issue. We are experiencing the same problem since the supernova update.
Resizing a panel or column always freezes the UI for about two seconds.

Forgot to mention that we are using Windows 10.

Are you still able to reproduce with 115.11?

Flags: needinfo?(lancelot)

(In reply to Alessandro Castellani [:aleca] from comment #27)

Are you still able to reproduce with 115.11?

I will tell you as soon as 115.11 is available on Debian.

Flags: needinfo?(lancelot)

(In reply to Alessandro Castellani [:aleca] from comment #27)

Are you still able to reproduce with 115.11?

Unfortunately, 115.11 doesn't seem to change anything :(

Please check version 128 late(r) this week and report results. Thanks.

Flags: needinfo?(lancelot)

lancelot, did you have good results?

Whiteboard: [needs performance profile]

(In reply to Wayne Mery (:wsmwk) from comment #31)

lancelot, did you have good results?

I am currently using 115.14.0 and the lag is still there.

Flags: needinfo?(lancelot)

The lag is also there with Debian sid/unstable with gnome-shell 47~beta-1 and thunderbird 1:128.1.0esr-1.

Can youget a performance profile on version 128?

Flags: needinfo?(pmenzel+bugzilla.mozilla.org)
Flags: needinfo?(lancelot)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: