New messages require manual scroll to see

Since a version or two ago (6.308 running now), when I “pull down” to fetch new messages, they dont scroll/animate into view.

The messages window stays on the same view, witht the previous most-recent message at the top. I.e., it acts like there are no new messages, even though it downloaded several.

Then it requires scrolling down in the messages listing to see the new messages.

I saw a new feature listed talking about ‘animating new message’ something or other, and i’m not sure if that’s the release that broke new messages scrolling into view, but maybe.

Anyone else seeing this?

I have auto-sync off, I poll for messages manually by pulling down.

Yes, I can confirm this issue/behavior for the last two or three versions.

1 Like

what sort setting do you have set for that inbox? except for “arrival [timestamp]” and probably “read/unread” i wouldn’t expect newly received messages to necessarily sort to the top of the inbox list. the “date” sort order will generally sort newly received messages to the top, but it’s subject to the vagaries of sending client time settings.

The issue is that it changed behavior, not that it isn’t sorting. It sorts fine, but it used to show the new messages (sorted in descending date order) as they were retrieved. But now it shows none of the new messages until you pull down the list.

like Creeble said. I sorted by arrival and since the last versions the newly arrived mails are not displayed directly. I have to manually scroll to the top of the list to see it.

This might be a stupid question, but isn’t that exactly the expected behaviour as defined in the material design / material you guidelines?

Whenever an active sorted list is updated in the view, the view position should not change. This is set to be the default behaviour if you don’t give the list any extra parameters.

Other apps (e.g. OwnCloud, Nextcloud, …) using sorted lists which might be subjected to content updates during active view also don’t auto-scroll…

The only exception I see to this behaviour would be the end of the list. If items are removed within the actively visible part of the list, the end of the list is pushed up. Thus, the list would “scroll” to fill-up the view to cover an entire screen again.

No, this is none of either expected behavior, previous behavior, nor the behavior of any other email client I have ever used.

Refreshing messages, when sorted in (descending) date order, should show the new messages, and the top-most message should be the newest. The current behavior requires scrolling to see the content being refreshed; extra user action that may not even have meaning if there are no new messages (and there is no other indication that there are new messages).

Gmail, for example, displays new messages after refresh.

I assume this is a bug related to the improvement mentioned in a recent release ‘animate messages…’ which actually does nothing at all when refreshing messages.

I fully agree. It is extremely difficult for me to explain my 92 year old father that he needs to pull down the list to see the latest messages, it is already difficult enough to convince him to open his tablet to be able to check his email. When you touch the new mail notification it should immediately show the new messages.

Btw. my experience is based on 6.308, I don’t know what version my father is using because his tablet is 700Km away from me (and starting teamviewer quick support is not the easiest for him), would prefer this problem to be solved before his installation is updated.

Yes this behavior started 6.307
Totally annoying bug.

I confirm this annoying bug.

(Syncing - need to scrolling up)

It’s not technically a bug since the code is behaving the way it was designed to work. However, it’s clearly undesired behavior when using pull to refresh.

I’ve replaced the default layout manager with a custom version that keeps the list scrolled to the top when inserting new items at the start of the list. The change will be included in the next beta version, K-9 Mail 6.309.

Exactly what I wrote… Intended behaviour.

Thus, the “bug reports” should be considered feature requests, which @cketti has addressed with the modification he described.

Thanks for the fix / reversion to previous behavior! Look forward to testing it.

They would have been feature requests if the previous behavior hadn’t changed or the fix had been actuallly called out as a bug fix in the release.