1820012 - Message preview pane (message body or message summary) not in sync with selected message in message

Status: RESOLVED WORKSFORME

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

Description

[Wayne Mery (:wsmwk)]

I've lost track of whether this was with 111.0b2 or daily. There may already be a bug for this, but IMO the behavior has gotten worse.

Navigating through the message list, frequently the message being displayed did not match the message selected in the message list. Or the message preview was entirely blank.

Has anyone else seen this?

Comment 1

[Wayne Mery (:wsmwk)]

Further testing done on nightly - notes below. Reproduction might require mail.operate_on_msgs_in_collapsed_threads=true (I have true on nightly but false on beta). I haven't retested enough to comment further about beta.

Pretty consistently, the message summary for a thread of multiple messages (when the thread is collapsed) and/or message body displayed does not match to the selected message in the list. But the header of the message being displayed DOES m, for example subject in header matches subject in message list. Screen shot coming up.

Also, if I click on the LAST message in the message list, error console has
ncaught (in promise)
Exception { name: "NS_ERROR_ILLEGAL_VALUE", message: "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgMessageService.DisplayMessage]", result: 2147942487, filename: "chrome://messenger/content/aboutMessage.js", lineNumber: 177, columnNumber: 0, data: null, stack: "displayMessage@chrome://messenger/content/aboutMessage.js:177:18\ndisplayMessage@chrome://messenger/content/about3Pane.js:2989:32\n_onSelect@chrome://messenger/content/about3Pane.js:2238:23\nhandleEvent@chrome://messenger/content/about3Pane.js:2184:14\nonSelectionChanged@chrome://messenger/content/tree-view.mjs:991:10\n_selectSingle@chrome://messenger/content/tree-view.mjs:826:12\nhandleEvent@chrome://messenger/content/tree-view.mjs:271:16\n", location: XPCWrappedNative_NoHelper }

I haven't been using daily consistently, so I have no idea how long this has been happening.

In the little testing I did on beta - it is slightly weirder, because with mail.operate_on_msgs_in_collapsed_threads=true the message summary doesn't always show, it shows the body of one message instead.

Comment 2

[Geoff Lankow (:darktrojan)]

Bug 1819795?

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Geoff Lankow (:darktrojan) from comment #2)

Bug 1819795?

possibly. Can you make a try build with that - then I can give you immediate feedback tonight.

Comment 4

[Magnus Melin [:mkmelin]]

It's a fairly common problem yes. (I'm not sure it changed much.)

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Geoff Lankow (:darktrojan) from comment #2)

Bug 1819795?

Will check nightly build, with the above fix.

This issue may have been caused, or been made worse, by offline mode

Comment 6

[Wayne Mery (:wsmwk)]

Probaly just made worse by offline mode

Comment 7

[Calum Mackay]

I've been seeing this all the time since switching to SN last week; I never use offline mode.

113.0a1 (2023-03-17) (64-bit); MacOS Ventura 13.2.1

Comment 8

[Alessandro Castellani [:aleca]]

Still able to reproduce?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Alessandro Castellani [:aleca] from comment #8)

Still able to reproduce?

Yes. Rarely. Haven't been able to define it.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Calum Mackay from comment #7)

I've been seeing this all the time since switching to SN last week; I never use offline mode.

Calum are you still seeing this?

Comment 11

[Calum Mackay]

I've not seen the "wrong message" issue for some time, i.e. where the currently-selected message in the message list doesn't match the displayed message. Not seen that for a while.

But I do still see "blank message" with the current Daily; that seems to be linked to losing the IMAP connection: the only way to get it working is to switch to another folder, then back, and I see from the Status bar that TB re-opens the IMAP connection. It's not just a slow load, as it never recovers on its own. But this may be unrelated to what's reported here.

Comment 12

[Alessandro Castellani [:aleca]]

Thanks Calum for confirming.
Regarding your additional report, could you please open a dedicated bug with an STR so we can investigate that other issue?

Comment 13

[Calum Mackay]

(In reply to Alessandro Castellani [:aleca] from comment #12)

Thanks Calum for confirming.
Regarding your additional report, could you please open a dedicated bug with an STR so we can investigate that other issue?

thanks Alessandro.

see new bug 1843190