114.0b3

Deleting a message now can cause a scroll of the message list, such that the newly selected message is placed at the bottom of the pane. Happens about 3/4 of the time.

Also, perhaps unrelated, folder switch now sometimes scrolls message list to the top of the list.

Another symptom, deleting last message in a folder scrolls message list to the top.

It would be good to find the cause of the regression.
I have not tested nightly.

If I delete the last message in a folder, it scrolls to the top and then back to the bottom instantly, causing a refresh.

I'm guessing that's what's happening here.

This doesn't happen nearly as often when deleting messages further up the list, but I can reproduce that too with enough trials.

This is on Nightly.

Sean, if this isn't related to the message list performance work feel free to unassign or redirect.

There's also another issue, that might be related and a symptom of the same problem.
STR:

• Select an open thread or many messages in the middle of the list.
• Delete or archive them (any action that removes them from the list will do).
• The selection moves to the next message correctly, but the message list scrolls down, making the currently selected message reach the bottom of the visible viewport.

This seems to happen a bit inconsistently.

I'm sure this is a bit tricky, but we should try to keep the selection in the original position if the user is interacting in the middle of the list.

Not dataloss, but delete activity is super common for the average user and so this bad placement will happen many times per day.
I think we will want this fixed before the beta appeal next week.

A change I made while attempting to standardize scroll calculations caused the scroll position to be lost when the tree is invalidated, such as during a deletion. This meant that when we responded to the new selection, we would have to scroll the item back into view.

(In reply to Sean Burke [:leftmostcat] from comment #6)

This meant that when we responded to the new selection, we would have to scroll the item back into view.

Makes sense. Thanks for checking it. Will test daily this weekend after it lands, and it's an easy decision to then take it to Monday's beta.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/88344e3f7c7d
Don't reset scroll position when tree table is invalidated. r=aleca

Thank again. I can confirm this works on nightly.

Comment on attachment 9335051 [details]
Bug 1833845 - Don't reset scroll position when tree table is invalidated. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Thunderbird 114.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/2fe93d32fc8a