Thanks for a bug report. It's really odd. I updated my F29 to the latest bits and tested it here, also by changing Inbox content from another machine, but it didn't trigger any such behaviour as you see. This is with View->Group by Threads enabled, but even when I disable it and add/remove/modify messages in the folder it doesn't change the selected message here.

Yes, I have threads enabled, not sure how best to debug it because it's random and really weird!

I can confirm this problem - after upgrading from Fedora 28 to 29, Evolution started doing this same thing to me. Any hints on how we can get useful debug info?

I tried disabling "Group By Threads" and it seems to stop the problem (though I'd really prefer to be able to group by threads ☺)

I'd need some more details. There's truly a reason why it's doing so. Every detail matters. Thus:
a) have enabled Group By Threads
b) any filter enabled, like searching for anything in the folder? Menu
   Search->Clear should be sensitive when there's any extra filtering enabled
c) what triggers the message removal from the view?
d) is there a search folder selected, instead of having selected a real folder?

From Peter's description it looks like there's a filter to show only unread messages enabled, then when one such is selected it is auto-marked as read after the interval as set in Preferences, which causes it to be removed from the view, because it's not marked as unread anymore (thus it doesn't satisfy the filtering criteria). This is wrong for the selected message.

Is it anything like that?

For me this happens when I have no filters. I also don't use search folders. I usually use Group by Thread so I see it there.

It also happens if I have the actual message open in a separate window, it will update the contents of the window to the next email.

I don't see any general trigger here like HTML vs Text mail.

The message that it moves to next also seems quite random, it doesn't seem to move to the next message (or unread) message, or the next message in the next group. There's no apparent pattern/trigger that I can ascertain.

(In reply to Milan Crha from comment #5)
> I'd need some more details. There's truly a reason why it's doing so. Every
> detail matters. Thus:

> a) have enabled Group By Threads

Yes.

> b) any filter enabled, like searching for anything in the folder? Menu
>    Search->Clear should be sensitive when there's any extra filtering enabled

No.

> c) what triggers the message removal from the view?

I don't know. I read my mail via the preview pane, and if I switch to read a new message (I usually use the ctrl+] keybinding, but it also happens if I use the mouse to click to another message) it will show the new message briefly (I'd say 1-2 seconds) and then switch to another message (seemingly at random, as Peter says).

> d) is there a search folder selected, instead of having selected a real
> folder?

I don't use these.

> Is it anything like that?

I have not identified a cause, but I can say that it happens quite often when I have threading enabled. I've been reading mail today with threading turned off and I have not observed the problem in that mode.

I've pretty much the same settings here. No filters, Group By Threads, reading message by message. I do not recall seeing any such behaviour recently (neither longer, that would surely annoy me).

As there are no extra filters involved, it means the message it was moving away from is still visible in the message list, right?

I'll create a test package(s) for further debugging. Maybe it'll help to figure out why it moved to a different message.

Also seeing this after upgrading to F29:
- happens with group-by-thread, short test *without*  group-by-threads does not manifest the jumping
- no filtering when it happens
- I don't use search folders
- regardless of the message being selected by mouse or keyboard, it still jumps
- looks like some messages are "cursed" an Evolution will always jump away from them, regardless how many times they are selected, other messages are fine

As it's like "to random message", could you add the UID column into the message list (right-click above headers in the message list, pick Add column, then drag&drop the UID from the new window beside other columns), maybe the next selected is the next per UID, but not the next in the view, due to treading and sorting options.

Here [1] are the test builds, which add some debugging output printed on stdout. Click the architecture you've installed, then download respective packages and install/update them. After that just run evolution from terminal and the output will be there. Make sure you install/update also debuginfo and debugsource packages for both, thus the backtraces it'll print will be usable. The only really private information the debugging output will show are folder names; I do not expect the UIDs being anything private, those are just sequence numbers in case of IMAP.

I do not know whether it'll show the reason, but let's have it as the first step. 

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=30705444
    https://koji.fedoraproject.org/koji/taskinfo?taskID=30705486

(In reply to Milan Crha from comment #8)
> As there are no extra filters involved, it means the message it was moving
> away from is still visible in the message list, right?

Yes, the message it moves away from is still present in the message list, and I can go back to it but that will often result in it jumping away again.

Here [1] is a bit extended debugging on the evolution-data-server side for IMAP accounts. I'd like to ask to run evolution with:

   $ CAMEL_DEBUG=imapx:io,imapx:command evolution &>log.txt

and reproduce the issue. Look for a similar line with message_list_folder_changed, when the 'removed' is high, might be close to the end of the log. I'm interested in the IMAPx data being sent/received, except of anything private in it. Ideally have enabled only one IMAP account, to avoid data overlap in the log.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=30904246

Also, I forgot to ask, what do you have enabled in the Receiving Options of the affected account, please? In particularly, is Quick Resync enabled?

(In reply to Milan Crha from comment #13)
> Also, I forgot to ask, what do you have enabled in the Receiving Options of
> the affected account, please? In particularly, is Quick Resync enabled?

Hi Milan!

I haven't had time to use the debug build yet (sorry, just tooooooooooo much going on lately), but I can answer this question easily: I do have Quick Resync enabled. I can try without it to see if that makes a difference.

After disabling Quick Resync, I do not seem to experience this issue any more. It may be too early to declare that, because I did sometimes go a little time without experiencing it before, but I'll comment back if it happens again with this disabled.

(In reply to Randy Barlow from comment #15)
> After disabling Quick Resync, I do not seem to experience this issue any
> more.

Thanks for a quick test. I received a log in private from one user experiencing the same issue and it was also with the Quick Resync enabled. The log mentioned lines like this:
>  [imapx:A] flags changed for unknown uid 1989489
from which I believe the IMAPx hides some messages to the user, even they are on the server. The IMAPx tried to re-sync, which generates a folder-changed notification with all messages in the folder claimed to be removed, which is a reason why the UI moves to the next message - it thinks the currently selected had been removed.

I'll investigate further in this way. Current workaround is to disable Quick Resync.

I still didn't manage to reproduce this. If I got it right, then you see this mostly in the Inbox, and there's also enabled 'Listen for server change notification', right? There are some differences between the Inbox and non-Inbox when it comes to server notifications.

I made some changes to evolution-data-server, which can help, though not necessarily. I cannot verify it, it can be I do some things wrong. I'd appreciate if you could install this [1] new test build and run evolution as described in comment #12. The interesting part of the log starts in time when the affected folder is selected. If there are any message headers or such included in the log, then it's not important, it can be replaced with 'XXXXXX' or similar (not censored, but really replaced).

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=30922513

I've been able to reproduce something close to this. Couple notes from the journey:
a) some notifications were emitted on a wrong folder
b) when a folder is selected and a message to be viewed is downloaded,
   the QResync can notify about VANISHED messages with a note "(EARLIER)".
   The IMAPx code used the list of UIDs (which could be hundreds of thousands)
   to notify others about their removal, even if they were not part of the
   folder any more
c) as the UIDs can be repeated between folders, the combination of a) and b)
   caused the message list think the message is gone, thus it selected
   the next available message, which can be basically anything.
d) while I've been in it, I made some partial optimizations in the untagged
   vanished callback to not allocate 4MB of memory and then immediately discard
   it with no use. (4MB for 1M UIDs received).

I'm committing this with a reference to the upstream bug [1].

Created commit [2] in eds master (3.31.3+)
Created commit [3] in eds gnome-3-30 (3.30.3+)

[1] https://bugzilla.gnome.org/show_bug.cgi?id=719328
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/4f5658d59
[3] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/2faf7fc19