Closed Bug 1666146 Opened 4 years ago Closed 3 years ago

8-bit chars of news messages are displayed in RAW UTF-8 chars rather then properly decoded

Categories

(Thunderbird :: Message Reader UI, defect)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: infofrommozilla, Unassigned)

References

Details

Attachments

(3 files)

Attached image tb_rawUTF8.png (deleted) —

Randomly after fetching new messages from a newsgroup server, the new articles are displayed with RAW UTF-8 chars (ä -> ä etc.)

The encoding of these articles is correct and if I revisit the same massage a second time, it is displayed correct (see atachement).

This behavior is also independent of the charset of the message. When it happens, both UTF-8 and ISO-8859-1 articles are displayed in RAW UTF-8.

This behavior has been occurring since Bug 1661955 was fixed.
Before that, under similar circumstances, I had an empty window. See bug 540288 especially bug 540288 Comment 48

If you know the cause, it's quite simple to reproduce... <SIC!>

STR:

  • Of course you need an newsgroup with 8-bit articles.
  • For this group, the offline store must be switched off and old data must be deleted to ensure that it is not used.
  • Now find an article with 8-bit chars and remember it (Immediately after starting of TB he should display fine).
  • Select a different article.
  • Clear the cache of TB (menu -> Tools -> Clear Recent History => [x] Cache => [Clear Now]).
  • Wait at least 170 seconds¹⁾.
  • Reselect the remembered 8-bit article.
    => The view of it is now broken.

¹) https://dxr.mozilla.org/comm-central/source/comm/mailnews/news/src/nsNntpIncomingServer.cpp#485

Attached file The Callstack of the first rise. (deleted) —

Just before the broken article is shown, this assertion is raised twice(!):

  MOZ_ASSERT(!m_targetStreamListener,
             "Why do we already have a target stream listener?");

https://dxr.mozilla.org/comm-central/source/uriloader/base/nsURILoader.cpp#382

Attachment #9178103 - Attachment mime type: application/octet-stream → text/plain
Attached file The Callstack of the second rise. (deleted) —

It's nearly the same.

Attachment #9178104 - Attachment mime type: application/octet-stream → text/plain

Thanks Alfred. This certainly looks related to Bug 1661955. At a first guess I'd say the pathway taken for the first access was broken, but the pathway taken for the subsequent (cached) access is correct.
(there's at least one other pathway that could be taken too, if a request needs to be queued up to use a connection, but I don't think that'll be in play in this case).

This is fixed by bug 1718119, although i don't think it's a duplicate. Therefore I close it as WORKSFORME.

I cannot say at this time whether the assertion of comment 3 still occur.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: