1866553 - Message list scrolls up to random spot/top when switching folders, despite last message being selected

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect, P2)

Description

[Wayne Mery (:wsmwk)]

Created as a clone of Bug #1862167, but I don't know that 1862167 is related in my issue - my case no new messages have been received, plus mine always scrolls to the top whereas 1862167 "seems to prefer to set the scroll to some middle position in the message list".

Highly reproducible.

Steps with 120.0b6:

1. All Folders view (not unified folders)
2. View > Sort by > date & ascending & Threaded
3. In Inbox, the LAST message thread MUST have more than one message
4. Expand that last message thread and click the second message in that thread, i.e. NOT the top message
5. click in another folder
6. click Inbox - Note: the message list is still positioned (scrolled to) the last message
7. open quick filter - don't type anything in it.
8. click another folder
9. click Inbox

Result: Message list scrolls to top of list. Note items #2,3,4,7 are essential - change any of those steps and the issue does not reproduce. It is as if Thunderbird thinks that sort DESCENDING is in effect when selected message is something other than the top/root message that last thread (step #4).

Unlike many other scrolling bug reports, this does not involve any message deletions or drags. I randomly hit on these steps, so I have no idea when it started. I didn't test 115.

fails with mailnews.scroll_to_new_message both true and false, which confirms my issue is unrelated to new messages.

Comment 1

[Wayne Mery (:wsmwk)]

https://mzl.la/3GdwjGb is the current list of v115+ open and fixed scroll bug reports

Comment 2

[Hartmut Welpmann [:welpy-cw]]

I couldn't reproduce this for a long time, only after resizing the message pane to its lower limit it now sometimes happens to to scroll up on its own, but in my case instantly (no smooth scrolling) and to different random positions.

Apparently a change I made to avoid exactly this behavior in the cards view, which seemed to solve the problem at the time (see bug 1854865) and was therefore included in bug 1807063, now has the opposite effect.

I don't know why this sometimes doesn't work (anymore), but I will provide a patch which did not show the unwanted scrolling in my test yet.

Comment 3

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1866553 - Disable scroll anchoring for threadTree. r=darktrojan

Comment 5

[Hartmut Welpmann [:welpy-cw]]

Wayne, could you please test if you can still reproduce after setting layout.css.scroll-anchoring.enabled to false?

Comment 7

[Wayne Mery (:wsmwk)]

For some reason I am currently not able to reproduce. Even after restarting.

It turns out I do have a userChrome.css

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

/* Folder Pane font */
#folderTree > treechildren {
  font-size: 10pt !important;
  font-family: Verdana !important;
  color: #000062 !important;
}

/*  Threads Pane font */
.tree-rows {
    font-size: 15pt !important;
    font-family: Verdana !important;
    color: #000062 !important;

#.new-messages > .container > .name {
#  color: Black !important;
#}

.new-messages > .container > .unread-count {
  background-color: Gray !important;
}

Comment 11

[[:AlanK]]

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

For some reason I am currently not able to reproduce. Even after restarting.

It turns out I do have a userChrome.css

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

/* Folder Pane font */
#folderTree > treechildren {
  font-size: 10pt !important;
  font-family: Verdana !important;
  color: #000062 !important;
}

/*  Threads Pane font */
.tree-rows {
    font-size: 15pt !important;
    font-family: Verdana !important;
    color: #000062 !important;

#.new-messages > .container > .name {
#  color: Black !important;
#}

.new-messages > .container > .unread-count {
  background-color: Gray !important;
}

the #'s in .new-messages lines above I don't think they comment out the code. /* & */ do, AFAIK.

Comment 12

[mozillabugs]

(In reply to Hartmut Welpmann [:welpy-cw] from comment #5)

Wayne, could you please test if you can still reproduce after setting layout.css.scroll-anchoring.enabled to false?

I began seeing a very similar bug years ago, and it is still present in 115.5.0, but changing the setting you described fixes it.

The bug I saw was manifested on unified mailboxes sorted with the newest messages at the bottom. I could always repro it thusly:

1. Select inbox folder.
2. Select a message (need not be a thread member) near the bottom.
3. Select sent folder.
4. Select inbox folder again.
5. Observe that inbox is scrolled to some earlier message.

Comment 13

[fred]

I agree with Comment 12, which describes what I saw. Note that in my case it was all too easy to reproduce... I do have smooth scrolling enabled, though I don't think that impacts the message list (that's "cards", right?). My view is always newest at the bottom, and I suppress the message pane in favor of always reading messages in their own windows. Also, I do not use threading, and only use POP (I wish you'd fix IMAP behavior, like in 1797971, or my underlying forum question ...questions/1425912, but that's off thread), so no unified mailboxes.

One more interesting observation: My 115.5 test machine had a lot (thousands) of unread messages. With layout.css-scroll-anchoring.enabled true (in 115.5 it seems okay if left false), it did not misbehave often, but when I marked all messages as read, it misbehaved regularly. I saw the problem on my main mail machine where I maintain my mailboxes as all read (once I read them); that may actually influence the behavior.

Comment 15

[Orplid]

Now in 115.5.1 sort order is inverted in sent folders while it is correct in inbox folders (card view, Windows 64)

Comment 16

[Doug Kerr]

Still not working properly in my TB 115.5.1 (64 bit 0n Win 7 Pro SP1). I have not yet fully characterized the anomaly, but broadly it is the same as before.

Comment 17

[Hartmut Welpmann [:welpy-cw]]

There was no explicit change in this regard between 115.4.3 and 115.5.1. Could you also please test if setting layout.css.scroll-anchoring.enabled to false makes a difference?

Comment 18

[Doug Kerr]

I have no entry for that parameter in my config file, but I will add what you cite and let you know what that does.

I assume the default must be TRUE.

Comment 19

[Doug Kerr]

I have added layout.css.scroll-anchoring.enabled=FALSE to my config file, closed and reopened TB. There is no major change in the reported behavior.

Comment 20

[Hartmut Welpmann [:welpy-cw]]

Well, the mentioned setting should be accessible by default via Config Editor in Thunderbird's settings. In the config editor, just type in anchoring.e and click on the toggle button on the right. Please remove the setting from your config file, as I don't know if it may interfere with the other one.

Comment 21

[Doug Kerr]

Yes, I know how to access that, but I had not worked a lot with that editor, so I was not to0 fluent at first, and I may have missed the existing setting. Perhaps the setting did exist and I just changed its value. I am sure there are not now two lines with the same identifier. But I'll check. Thanks.

Comment 22

[Herve]

A little information:
1/ I had carried out this manipulation (point 3) when it started to bug, but it didn't change anything.
2/ Version 115.5.1 largely corrects the problem for me, I have folders that work well and others whose position remains random...
3/ On the folders (inbox) which are malfunctioning I carried out [I have done?] (properties-repair) on the "defective" folders and it seems that everything is working correctly.
To be continued...
Thanks.

Comment 23

[Doug Kerr]

Using 115.5.1 here. Following what Herve said, on the two folders I most often use I did Properties:Repair. One result was that each now showed a large fraction of the messages as unread (there were none not marked read when I started this maneuver). I did Select All (Ctrl-A) and then R to mark everything read (since it was).

Now I find that, if I:

• Select a message on one Inbox folder, then scroll the folder list to a different position (so the selected message is no longer visible).
• Switch to another Inbox folder.
• Switch back to the first Inbox folder

Then the first folder will be positioned so the selected message is viable in it.

So far it seems that the generally leads to a functioning that is very satisfactory.

Thnaks, Herve.

Comment 24

[Doug Kerr]

Well, it seems I spoke too glowingly too soon. But in fact it does seem as though if I had a folder scrolled so the latest message is showing, if I go to another folder and then return to the first, it is still in that position.

I now have to see what happens when there are new messages (I have the sort to be by date/time, ascending).

Comment 25

[Arbie]

Thunderbird 115.5.1 (64-bit) on Windows 10 Pro x64

The "scrolling out of view on return to inbox" problem still exists, the same as I have described a couple of times, so details are in those. Not complaining - just reporting.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9b405512422c
Disable scroll anchoring for threadTree. r=darktrojan

Comment 27

[Wayne Mery (:wsmwk)]

Comment on attachment 9365431 [details]
Bug 1866553 - Disable scroll anchoring for threadTree. r=darktrojan

[Triage Comment]
Approved for beta

Comment 28

[Rob Lemley [:rjl]]

Thunderbird 121.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/032bce227b66

Comment 29

[Wayne Mery (:wsmwk)]

Comment on attachment 9365431 [details]
Bug 1866553 - Disable scroll anchoring for threadTree. r=darktrojan

[Triage Comment]
Approved for esr115

Comment 30

[Rob Lemley [:rjl]]

Thunderbird 115.5.2:
https://hg.mozilla.org/releases/comm-esr115/rev/f02c8f01be08

Comment 31

[Matt]

I have;
Name Thunderbird
Version 115.5.2
Build ID 20231208140222

I open Folders and the location in the folder appears to be somewhat random. Like it is trying to remember where it was last time or something. So either there are still more but in here or there is something else at work.

I did look in prefs.js and I have the mailnews.scroll_to_new_message false. I will reset it to default and see if that makes a difference. But I fail to see what a preference about expanding unread threads has to do with a random location in a message list.

Comment 32

[Matt]

Attachment: image.png

Changed the preference, now from the change, I assume, threads with unread mail are not expanded.
and there is a selected email at the bottom of the image.

So I guess I need to know how to get threads with unread mail only to expand and opening the list of emails at the top, or bottom depending on the sort order. I am sure there are folks that want to resume just where they left off which appears to be what is happening, I am not one of them.

Comment 33

[Hartmut Welpmann [:welpy-cw]]

Matt, in your screenshot, it looks like messages are already selected. When switching back to a folder, they are scrolled into view.

mailnews.scroll_to_new_message is only for newly received messages, as indicated by the little yellow star. They will be scrolled into view if there are no selections yet. This setting does not affect other unread messages.

Some things you could try if scrolling still seems erratic:

• Repair the folder (via its properties)
• Check if something is different in troubleshoot mode
• Try setting layout.css.scroll-anchoring.enabled to false (this setting is already applied locally to the thread pane, but there has been one report where it needed to be disabled globally)

Comment 34

[Matt]

I have had to go to the extreme since I got supernova of actually deleting MSF files. None of the usual compact or repair options could restore the list when changing from unread to read and vise versa with the toolbar.

But I had just opened that folder when I took the image, and that was already selected. That is my point here. I can't get the thing to forget what was happening the last time the folder was opened. or pretending it remembers, as I really don't know.

Could this be related to the relatively new Firefox action of scrolling a web page to the last location if you open it again? Handy on a phone if you accidentally click the back, but otherwise an annoyance.

Comment 35

[Hartmut Welpmann [:welpy-cw]]

(In reply to Matt from comment #34)

But I had just opened that folder when I took the image, and that was already selected. That is my point here. I can't get the thing to forget what was happening the last time the folder was opened. or pretending it remembers, as I really don't know.

This was already the default behavior prior to Supernova, but the possibility to disable remembering the previous selections has been removed. See bug 1847487 comment 4 for an explanation.