1917465 - Incorrect scrolling position in local folder at startup

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[tssajo]

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

Steps to reproduce:

I open Thunderbird.

Actual results:

The inbox message list has the focus, but the newest message displayed is somewhere in the middle of the total list of messages in the inbox.

Expected results:

The newest message displayed should be the one with the newest timestamp. This is the behavior I saw before ~115.10.x.

---

This bug is still present in Thunderbird 128.2.0esr as of September 8th, 2024

I run Thunderbird 128.2.0esr on Windows 10
(I fully updated Windows 10 on September 8th, 2024)

Comment 1

[Hartmut Welpmann [:welpy-cw]]

When this was fixed for ESR 115 in bug 1827042, it was implemented this way:

This scrolls the view to the most relevant end of the tree if no selections are to be
restored, no new message has been scrolled to just before, and no user scrolling has been
detected before all messages have been loaded.

So maybe some scrolling was detected for some reason?

Comment 2

[tssajo]

Well, the problem only occurs when I launch Thunderbird. I don't scroll at all.
Thunderbird just starts and the Inbox is shown, but the scroll position is wrong. Then if I click on any other folder (e.g. Drafts) and then click on Inbox then the scroll position is perfect. In other words, I just need to click-away and then come back to the original folder and then the scroll position is perfect.
Also, it is not just happening with the Inbox. No. If I was viewing e.g. the Sent folder when I closed down Thunderbird. Then when I start Thunderbird again, it will show the Sent folder on startup as it correctly remembers the last folder viewed. But the scroll position is wrong there then, too. Just right after the startup, and only then.

Comment 3

[Wayne Mery (:wsmwk)]

tssajo, are you still seeing this?

Comment 4

[tssajo]

Yes, I see it every time I launch Thunderbird. For months now. It is extremely annoying. I will create a video demoing the issue and post the link here, shortly. So you all can see it.
Thanks!

Comment 5

[tssajo]

Here is the demo:

https://www.youtube.com/watch?v=FpGEBqVUJWk

I know, this is NOT the latest version of Thunderbird. In fact it is Betterbird 115.18.0-bb36 in the video.
However, this is exact same issue is present in Thunderbird 128.5 too!

Note: I won't leave this video up on Youtube for long. Only for a few days, so you guys can see what the actual issue is. Then I'll delete this video.
Thanks!

Comment 6

[Hartmut Welpmann [:welpy-cw]]

I was able to reproduce this for local folders in Thunderbird ESR 115, 128, etc.

When the last selected folder is restored at startup, messages in a local folder are loaded immediately (earlier than messages in an IMAP folder would be). When the view then scrolls to the bottom of the thread pane, it has to calculate the vertical size of the pane. For some reason, however, it gets exactly the same size as if the message pane were collapsed, whereas the pane splitter should already be expanded at this point, as debugging has shown.

A quick fix would be to delay scrolling for a tick by changing this line to setTimeout(() => window.threadPane.scrollToLatestRowIfNoSelection());, but I'm not so sure that's the best solution. Maybe Alex or Geoff have more insight.

Comment 7

[Alessandro Castellani [:aleca]]

Thanks for investigating this and finding where the inconsistency happens.

I don't fully understand that whole stack, as I'm not really sure why we call window.threadPane.scrollToLatestRowIfNoSelection() only there but not for any other condition, or after we dispatch the "allMessagesLoaded" event.

My suggestion would be to check the stack trace of the thread loading and maybe find a better place for that method?

I don't know if this is a symptom of a more system issue, in which case Geoff might have better insights.

Comment 8

[tssajo]

Thanks for commenting and therefore keeping this bug ticket active!
But when will this get fixed?
I reported this bug over 4 months ago.
I "experience" this issue every day for about half a year now. Note: I didn't report it right away hoping that someone else would also notice this regression and that the issue will be fixed soon. That didn't happen for a month or two so then I decided to report it, that was over 4 months ago.
It would be nice if this could get fixed in the next release! Thanks!

Comment 9

[Geoff Lankow (:darktrojan)]

Thanks for investigating Hartmut. You've saved me a bunch of time trying things that are irrelevant.

Sorry it has taken a while tssajo, we are a very small team and don't have time to jump on every issue straight away, and we have been flat-out working on more serious issues.

It's happening because the resize observer watching for changes in the message list height is triggered after everything else happens (as that's how a ResizeObserver works). So the message list is using a stale cached value for its height (we cache it to avoid causing expensive layout calculation in other circumstances).

I see two potential ways around this:

• Force an update the cached value at the point where the message pane becomes visible.
• Delay the selection of the initial folder until after everything else (including the resize observer triggering) happens. (That is, insert await new Promise(resolve => setTimeout(resolve)); here.) I prefer this option.

Comment 10

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1917465 - Delay initial folder selection until resize observers have fired. r=#thunderbird-reviewers

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ef737872808c
Delay initial folder selection until resize observers have fired. r=mkmelin

Comment 12

[Geoff Lankow (:darktrojan)]

Comment on attachment 9459046 [details]
Bug 1917465 - Delay initial folder selection until resize observers have fired. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: the message list scrolls to the wrong place on start-up
Testing completed (on c-c, etc.): landed over a week ago
Risk to taking this patch (and alternatives if risky): low

Comment 13

[Corey Bryant]

Comment on attachment 9459046 [details]
Bug 1917465 - Delay initial folder selection until resize observers have fired. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Comment 14

[Daniel Darnell [:dandarnell]]

Thunderbird 135.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/ebb7505d474f