Open Bug 1844628 Opened 1 years ago Updated 5 days ago

opening multiple tabs affects marking a message read/unread with a key - takes 1-5 seconds

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
Thunderbird 115
Type:
defect

Tracking

(thunderbird_esr128 affected)

Status:
UNCONFIRMED
Tracking Flags:
Tracking Status
thunderbird_esr128 --- affected

People

(Reporter: gary, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dupeme, perf, regression, Whiteboard: [has performance profile])

Attachments

(1 file)

Screenshot 2023-08-08 at 5.16.15 AM.png
156.88 KB, image/png
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

After upgrading to 115 from 112 (on macOS 13.4.1), the UI overall feels much more sluggish. E.g. marking a message read/unread with a key takes 1-2 seconds to respond.

Expected results:

Same response as 112.

with 115.0.1 ?

Flags: needinfo?(gary)

115.0.1 is no better.

Flags: needinfo?(gary)

Please create a performance profile and post it here. Make the collection time very short so that you capture just the marking activity.
https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance

Component: Untriaged → Folder and Message Lists
Flags: needinfo?(gary)
Keywords: perf

What personal data is captured in these logs? What is the best method to redact?

Flags: needinfo?(gary)

Please read the article. Your question is aswered there.

I downloaded the file, and glanced at it. It definitely has a significant amount of personal information in it, e.g. names of all my email accounts, servers used, etc.

Does the Upload function strip this? If not, "The profile does NOT contain personally identifiable nor private information unless you explicitly opt in to sharing such additional information." is not accurate. Where does one opt in or our of sharing?

(In reply to Gary Hooper from comment #6)

I downloaded the file, and glanced at it. It definitely has a significant amount of personal information in it, e.g. names of all my email accounts, servers used, etc.

Sure, the download does have PII. It hasn't stripped anything because it is on your computer. But ...

Does the Upload function strip this? If not, "The profile does NOT contain personally identifiable nor private information unless you explicitly opt in to sharing such additional information." is not accurate. Where does one opt in or our out of sharing?

Exactly as stated in this screen shot.

By default none of those boxes is checked on, so no PII is uploaded.

The fact that Download and Upload change the data is at best a very odd UI. Frankly, I do not trust it.

Did you really update from beta 112? Or was it release 102?

(In reply to Gary Hooper from comment #8)

The fact that Download and Upload change the data is at best a very odd UI. Frankly, I do not trust it.

I don't understand your comment. The point is they are supposed to be different:

  • the download includes all your PII which you can then give the profile to a single trusted developer and not have it posted in public -or-
  • the upload process send a smaller, reduced set of data which *explicitly does not include any PII - and even after it is uploaded, only those who have the link can see the data you chose to upload

Over 300 bug reports have such profile URLs posted this year alone -

If you are unable to provide a profile then your only recourse is to go through https://wiki.mozilla.org/Thunderbird:Testing:Memory_Usage_Problems or hope someone reports a similar issue.

Severity: -- → S4
Flags: needinfo?(gary)

One of the key performance bugs bug 1851871 which should be fixed next week in 115.3.0.
Please post your results here next week.

Whiteboard: [closeme 2023-09-25]
Whiteboard: [closeme 2023-09-25] → [closeme 2023-09-30]

Flags: needinfo?(gary@hooper.org)

Gary, please, have you updated and if so, is the bug reproducible?

115.3.1 is still very sluggish compared to 102.15.1. Simply toggling between read and unread takes seconds, regardless of the message selected.

It is so sluggish that I have reverted back to 102.15.1.

Flags: needinfo?(gary)
Whiteboard: [closeme 2023-09-30] → [closeme 2023-10-21][needs profile]

Some further information. (I have multiple email accounts configured, and multiple tabs open in a single window.)

If I have a single window with a single tab, marking messages read/unread is responsive. If I open a second tab in the same window, speed is a little slower. As I open successive tabs, the speed decreases. After 5-6 tabs, responsiveness of marking read/unread is interfering with normal usage.

Should be easy to reproduce.

This will likely be either bug 1855758 (fixed on daily, ETA 115.4.1) or bug 1856929 (not yet fixed)

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1855758
Resolution: --- → DUPLICATE
Summary: sluggish response in main pane after upgrading to 115 from 112 → marking a message read/unread with a key takes 1-2 after upgrading to 115 from 112

It remains unfixed in 115.4.1.

This problem remains unfixed in 115.5.0.

Status: RESOLVED → UNCONFIRMED
No longer duplicate of bug: 1855758
Resolution: DUPLICATE → ---
Whiteboard: [closeme 2023-10-21][needs profile] → [needs profile]

Still a problem in 115.5.2.

Summary: marking a message read/unread with a key takes 1-2 after upgrading to 115 from 112 → marking a message read/unread with a key takes 1-5 seconds after upgrading to 115 from 112
Summary: marking a message read/unread with a key takes 1-5 seconds after upgrading to 115 from 112 → marking a message read/unread with a key takes 1-5 seconds after upgrading to 115 from 102

(In reply to Gary Hooper from comment #13)

Some further information. (I have multiple email accounts configured, and multiple tabs open in a single window.)

If I have a single window with a single tab, marking messages read/unread is responsive. If I open a second tab in the same window, speed is a little slower. As I open successive tabs, the speed decreases. After 5-6 tabs, responsiveness of marking read/unread is interfering with normal usage.

Should be easy to reproduce.

Unfortunately no, I am not able to reproduce. If no one else can reproduce, and with no performance profile, this likely will not make progress.

Blocks: sn-msglist
Keywords: regression, stalled
Summary: marking a message read/unread with a key takes 1-5 seconds after upgrading to 115 from 102 → opening multiple tabs affects marking a message read/unread with a key - takes 1-5 seconds after upgrading to 115 from 102

You can download a profile where I selected a message, marked it unread, arrowed up, marked this message unread, and then marked both of these messages read again.

Please let me know whether this includes the required info.

I will add that even with 115.5.2, Thunderbird overall feels very sluggish compared to the final 102 iteration: slower to open, slower to load messages, slower to change tabs, etc.

Thanks for the profile. https://share.firefox.dev/47ft1NC has lots of reflow.

If this still reproduces with current version 115.6, are you able to try daily build from https://download.mozilla.org/?product=thunderbird-nightly-latest-SSL&os=osx&lang=en-US and try it with a new profile.

Flags: needinfo?(gary)
Keywords: stalled
Summary: opening multiple tabs affects marking a message read/unread with a key - takes 1-5 seconds after upgrading to 115 from 102 → opening multiple tabs affects marking a message read/unread with a key - takes 1-5 seconds
Whiteboard: [needs profile] → [has performance profile]
See Also: → 1851102

This is still a problem in 115.8.0.

Flags: needinfo?(gary)

This is still a problem in 115.10.0. It's taking 4 seconds to mark a message read/unread, versus instantaneously in 102.15.1.

This is likely fixed in 128, which ships in July. The only way to get it sooner is https://www.thunderbird.net/en-US/download/beta/

Keywords: dupeme

Hi Wayne. Is there another bug fix that you think is impacting this? (I don't see it linked.) Why is it "likely fixed in 128"?

Still broken in 128.0 esr.

Still broken in 128.2.3esr.

Still broken in 128.3.1esr. I have 10 tabs open, and it's taking 4-5 seconds to mark a message as read/unread.

Is anyone going to look into this?

(In reply to Gary Hooper from comment #24)

Hi Wayne. Is there another bug fix that you think is impacting this? (I don't see it linked.) Why is it "likely fixed in 128"?

Because we had some fixes in this area.
Please post a new performance profile.

status-thunderbird_esr128: --- → affected
Flags: needinfo?(gary)

This remains a problem in 128.4.0.

It is trivial to reproduce. Open Thunderbird, with a single tab displaying your Inbox. My Inbox has 128 messages in it, more than one pageful. Pick a message. With the M key, mark the same message read/unread repeatedly. Make a mental note of the speed.

Now, open the same Inbox folder in a new tab. Repeat 6 times, such that 7 tabs are open, each containing the same list of messages. In the first tab, go back to the original message. With the M key, mark the message read/unread repeatedly. Notice the significant delay?

I tried re-creating my profile from scratch in 128, but this made no difference.

Flags: needinfo?(gary)

I just tried to reproduce this on Windows, Mac, and Linux with the steps you listed and there was no delay in marking messages as read or unread.

It's readily reproduced for me, on MacBook Pro Intel (final) and iMac Intel (final), macOS 14.6.1. Performance report is here.

Hello,

I have tried the STR from the description using TB 115.16.3(20241118222652) and 115.11.0(20240513132046) on Mac Sonoma 14.7 .1 and did not manage to reproduce it.
I have also tried on 128.4.3esr( 20241108210256) and 128.5.0esr(20241125170630) without success.

I have tried with 1 tab open and 7 tab opened and the responsiveness is the same, TB behaves exactly the same with one tab or 7 tabs opened, emails are being marked as read/unread and did not notice any slowness (worth mentioning I have 3 accounts configured)

Is this behaviour still reproducible on 128.5.0esr? Can you give us more details on how many accounts you have configured, type of the accounts(IMAP,POP) were there any messages that were downloading at the moment when you noticed the slowness.

I am seeing the same slowness problem with 128.5.1esr on macOS Sequoia 15.1.1. It is occurring on two different machines with similar configurations, MacBook Pro Intel and iMac Intel.

I have 4 IMAP accounts configured, one to gmail and three others using the same privately hosted server. With 8 tab opens, I am seeing a delay of 2-3 seconds; with 1 tab open, it's sub 1 second, but slower than simply moving the cursor to highlight the next message. It gets slower with more IMAP accounts configured/more tabs open.

The speed issue is the same whether sync'ing or not.

What is the size of your prefs.js file?

Flags: needinfo?(gary)

In one case, 19KB. In a second case, with more email accounts and tabs, 201KB. This speed problem is virtually identical between the two. Both work wonderfully in 102.15.1.

I also tried starting from scratch with a new profile. As soon as I added a couple of accounts and some tabs, the problem started.

Flags: needinfo?(gary)

(In reply to Gary Hooper from comment #31)

It's readily reproduced for me, on MacBook Pro Intel (final) and iMac Intel (final), macOS 14.6.1. Performance report is here.

Thanks for the profile.
Lots of activity at nsBlockReflowContext::ReflowBlock via Reflow about:3pane

Flags: needinfo?(geoff)

I have a few ideas as to possible causes of the reflow. Not sure why it seems to be so much worse for some people than others.

Bug 1933104 has a reasonable chance of improving things here – it's now in our latest beta, could you try it out Gary?

Flags: needinfo?(geoff)

There is no improvement with 134.0b3.

That's unfortunate, I was hoping that would work!

Okay, how about this test build I made today? It's 128.5.1 with a minor modification. I haven't yet thought through all of the possible consequences of the modification yet, but it'd be nice to know if I'm on the right track.

Hi Geoff, this made no difference at all. (Overall, the app actually feels sluggier than the beta.)

Huh. Could you make another performance profile with the test build? Perhaps instead of eliminating the slow code I just delayed it.

A new profile is here. I selected a message, then M and M to mark as read/unread, and then used the arrow key to select and repeat for two other messages.

Somebody just pointed out your profile shows the message list with every second row a different colour. That's not there by default, how did you do it? If it's some add-on or theme or custom CSS I would really like to eliminate it as a possible cause of this bad performance.

This "zebra striping" was present out of the box through 102.x without any sort of customization.

Having said that, removing this custom userChrome.css makes no difference to the stated problem.

There is no improvement with 128.5.2esr.

(In reply to Gary Hooper from comment #42)

A new profile is here. I selected a message, then M and M to mark as read/unread, and then used the arrow key to select and repeat for two other messages.

Serious jank in that profile - picking just a subset

Flags: needinfo?(geoff)

I can see the jank, but I don't know what's causing it, or why it only seems to be happening to this user.

Flags: needinfo?(geoff)

The delay increases with the number of open tabs. Perhaps the problem occurs for others as well, but is less noticeable/objectionable if only one or two tabs are open.

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

Attachment

General

Creator:
Created:
Updated:
Size: