Message list scrolls up to random spot/top when switching folders, despite last message being selected
Categories
(Thunderbird :: Folder and Message Lists, defect, P2)
Tracking
(thunderbird_esr115? fixed, thunderbird121? fixed)
People
(Reporter: wsmwk, Assigned: welpy-cw)
References
(Regression)
Details
(Keywords: regression, reproducible)
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta+
wsmwk
:
approval-comm-esr115+
|
Details | Review |
50.58 KB,
image/png
|
Details |
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:
- All Folders view (not unified folders)
- View > Sort by > date & ascending & Threaded
- In Inbox, the LAST message thread MUST have more than one message
- Expand that last message thread and click the second message in that thread, i.e. NOT the top message
- click in another folder
- click Inbox - Note: the message list is still positioned (scrolled to) the last message
- open quick filter - don't type anything in it.
- click another folder
- 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.
Reporter | ||
Comment 1•10 months ago
|
||
https://mzl.la/3GdwjGb is the current list of v115+ open and fixed scroll bug reports
Assignee | ||
Comment 2•10 months ago
|
||
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.
Assignee | ||
Comment 3•10 months ago
|
||
Updated•10 months ago
|
Assignee | ||
Updated•10 months ago
|
Updated•10 months ago
|
Assignee | ||
Comment 5•10 months ago
|
||
Wayne, could you please test if you can still reproduce after setting layout.css.scroll-anchoring.enabled
to false
?
Reporter | ||
Comment 7•10 months ago
|
||
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;
}
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Updated•10 months ago
|
Comment 11•10 months ago
|
||
(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•10 months ago
|
||
(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
tofalse
?
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:
- Select
inbox
folder. - Select a message (need not be a thread member) near the bottom.
- Select
sent
folder. - Select
inbox
folder again. - Observe that
inbox
is scrolled to some earlier message.
Comment 13•10 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
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.
Assignee | ||
Comment 17•9 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
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.
Assignee | ||
Comment 20•9 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
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).
Assignee | ||
Updated•9 months ago
|
Comment 25•9 months ago
|
||
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•9 months ago
|
||
Pushed by benc@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/9b405512422c
Disable scroll anchoring for threadTree. r=darktrojan
Assignee | ||
Updated•9 months ago
|
Reporter | ||
Comment 27•9 months ago
|
||
Comment on attachment 9365431 [details]
Bug 1866553 - Disable scroll anchoring for threadTree. r=darktrojan
[Triage Comment]
Approved for beta
Comment 28•9 months ago
|
||
bugherder uplift |
Thunderbird 121.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/032bce227b66
Reporter | ||
Comment 29•9 months ago
|
||
Comment on attachment 9365431 [details]
Bug 1866553 - Disable scroll anchoring for threadTree. r=darktrojan
[Triage Comment]
Approved for esr115
Comment 30•9 months ago
|
||
bugherder uplift |
Thunderbird 115.5.2:
https://hg.mozilla.org/releases/comm-esr115/rev/f02c8f01be08
Assignee | ||
Updated•9 months ago
|
Comment 31•9 months ago
|
||
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•9 months ago
|
||
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.
Assignee | ||
Comment 33•9 months ago
|
||
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
tofalse
(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•8 months ago
|
||
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.
Assignee | ||
Comment 35•8 months ago
|
||
(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.
Description
•