1778453 - After upgrade to 102, messages display html code

Status: RESOLVED DUPLICATE of bug 1777738

(MailNews Core :: Database, defect, P1)

Description

[wfroml]

Steps to reproduce:

just look at my mail

Actual results:

many messages are displaying html code, specifically after upgrading to v 102.0.1
also old messages which displayed correctly in previous versions.
On laptop with win10/thunderbird v98 everything displays correctly

Expected results:

a readable text, not html code

Comment 1

[Thomas D. (:thomas8)]

Have seen similar reports, reminiscent e.g. of bug 1778037.

• wfroml, using POP or IMAP?
• did you try right-click folder -> Properties -> Repair folder?

Comment 2

[wfroml]

(In reply to Thomas D. (:thomas8) from comment #1)

Have seen similar reports, reminiscent e.g. of bug 1778037.

• wfroml, using POP or IMAP?
• did you try right-click folder -> Properties -> Repair folder?

All accounts IMAP
Repair folder has no effect
Reproducible: same problem on pc WIN10 and laptop WIN11, both with same mail accounts from 3 different providers
Re-installed Thunderbird v 91.11.0 with profile from backup and all mails display again as intended

Comment 3

[Dan Pernokis]

More to the point is Bug 1778241 (CF process is erratic...).

My experience so far is that compacting -- whether automatic or manual -- can cause a misalignment of one or more messages, such that screen info displayed in Message X is really for Message X+1
This is usually seen near the top (if sorted by date) because that's where most deletes happen, and deletes in turn trigger the compacts.
So to fix this, one runs REPAIR FOLDER, and that may lead to correction of the headers but also leaves at least one "empty" message (blank line in the Display Window) whose content is all text -- sometimes plain text words, sometimes html codes, etc, but often starting mid-message. And yes, I've had a previously known & otherwise good message suddenly turn to mush.

I've seen several of these cases so far, but can't say 100% for sure that it's the compact or the repair which is at fault. I strongly suspect that the compact is relying on a few bad pointers. (But why are they bad?) Perhaps repair should be run before compact -- difficult to do if compact is set for automatic -- so at least theoretically the pointers are known to be correct, and compact can do its thing. On the other hand, if repair is flaky, then all bets are off -- it could mess something up either way.

Comment 4

[wfroml]

(In reply to Thomas D. (:thomas8) from comment #1)

Have seen similar reports, reminiscent e.g. of bug 1778037.

• wfroml, using POP or IMAP?
• did you try right-click folder -> Properties -> Repair folder?

(In reply to Dan Pernokis from comment #3)

More to the point is Bug 1778241 (CF process is erratic...).

My experience so far is that compacting -- whether automatic or manual -- can cause a misalignment of one or more messages, such that screen info displayed in Message X is really for Message X+1
This is usually seen near the top (if sorted by date) because that's where most deletes happen, and deletes in turn trigger the compacts.
So to fix this, one runs REPAIR FOLDER, and that may lead to correction of the headers but also leaves at least one "empty" message (blank line in the Display Window) whose content is all text -- sometimes plain text words, sometimes html codes, etc, but often starting mid-message. And yes, I've had a previously known & otherwise good message suddenly turn to mush.

I've seen several of these cases so far, but can't say 100% for sure that it's the compact or the repair which is at fault. I strongly suspect that the compact is relying on a few bad pointers. (But why are they bad?) Perhaps repair should be run before compact -- difficult to do if compact is set for automatic -- so at least theoretically the pointers are known to be correct, and compact can do its thing. On the other hand, if repair is flaky, then all bets are off -- it could mess something up either way.
(In reply to Dan Pernokis from comment #3)
More to the point is Bug 1778241 (CF process is erratic...).

My experience so far is that compacting -- whether automatic or manual -- can cause a misalignment of one or more messages, such that screen info displayed in Message X is really for Message X+1
This is usually seen near the top (if sorted by date) because that's where most deletes happen, and deletes in turn trigger the compacts.
So to fix this, one runs REPAIR FOLDER, and that may lead to correction of the headers but also leaves at least one "empty" message (blank line in the Display Window) whose content is all text -- sometimes plain text words, sometimes html codes, etc, but often starting mid-message. And yes, I've had a previously known & otherwise good message suddenly turn to mush.

I've seen several of these cases so far, but can't say 100% for sure that it's the compact or the repair which is at fault. I strongly suspect that the compact is relying on a few bad pointers. (But why are they bad?) Perhaps repair should be run before compact -- difficult to do if compact is set for automatic -- so at least theoretically the pointers are known to be correct, and compact can do its thing. On the other hand, if repair is flaky, then all bets are off -- it could mess something up either way.

I also observed the screen display showing message x+1 instead of x, but I assumed it was my provider messing up. I also observed Thunderbird insisting on"compacting needed" far more than usual. So all these problems may indeed be related.

Comment 5

[Dan Pernokis]

Last night I went to a target/destination folder (holding messages from a specific online subscription) and deleted scores of duplicates. Then I did a REPAIR FOLDER first, followed by the inevitable manual CF. Perfect -- no misalignments, no scrogging of data or missing headers. The first many entries looked fine afterward.

So that convinces me the CF trips up to cause the misalignment of headers(?) -- or certainly the message bodies being seen -- because the folder was already broken prior to the CF. Then REPAIR afterward does the best it can to at least realign everything and give a proper display, understanding there will be one or two mangled losses at the top.

Question now is: What did a massive series of DELETEs (single, multiple, contiguous groups of records, etc) do to the structure of the folder in the first place??? And this brings us back to Bug 1778248 -- the not-so-benign problem of DELETEs sometimes erasing the Display Window, implicating the deletion process as the inital cause. (Notice CF was always done first -- automatic or manual -- followed by the REPAIR.)

Comment 6

[djk]

I have the same issue of random messages displaying as the source text and not matching the subject line and not matching the correct message body. Trying to compress or repair the folder does not resolve the issue. Deleting the .msf file and subfolders and forcing them to be rebuilt from the IMAP server resolves the issue.
Windows 11 Pro, TB 102.0.1 (64-bit)

Comment 7

[wfroml]

update, now on 102.0.2
I haven't experienced messages displaying source code for 3 days now, so definitely something has improved.
However: I retained 1 message in my inbox which originally showed html code. The html has disappeared but it still presents problems: takes minutes to load, then the message slowly appears (lots of graphics) but Thunderbird doesn't respond any longer. Windows task manager shows 8% cpu and no less than 5200MB memory use.
Strange: I installed TB 91, which displays that message correctly, so I can forward it to myself and this identical forwarded message then displays correctly and swiftly in TB 102 (task manager: 0.1 % CPU, 270 MB memory)! So perhaps v102.0.1 corrupted the original message and 102.0.2 behaves better???

Comment 8

[Dan Pernokis]

The html has disappeared but it still presents problems: takes minutes to load, then the message slowly appears (lots of graphics) but Thunderbird doesn't respond any longer. Windows task manager shows 8% cpu and no less than 5200MB memory use.

The display seems to grab random text, including html code, from midway through the message according to how things are misaligned and mispointed. My guess is this time TB is again grabbing something random -- from this message or from elsewhere -- and then doing the best it can to render a display, unfortunately failing miserably on this one. I don't think the fixes in 102.0.2 addressed this, so I'd say coincidence of timing.

But the comparison of TB 91 to 102 might be telling us something too -- that maybe the pointers aren't so messed up, but maybe 102's reading of them (or understanding of them) is. Whether a pointer is actually wrong or misread -- or if when read it is not interpreted properly -- amounts to the same thing as far as the processing goes: a faulty display and perhaps (further) damage to the files.