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

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[Alfred Peters [:infofrommozilla]]

Attachment: tb_rawUTF8.png

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.

Comment 1

[Alfred Peters [:infofrommozilla]]

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

Comment 2

[Alfred Peters [:infofrommozilla]]

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

Comment 3

[Alfred Peters [:infofrommozilla]]

Attachment: The Callstack of the first rise.

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

Comment 4

[Alfred Peters [:infofrommozilla]]

Attachment: The Callstack of the second rise.

It's nearly the same.

Comment 5

[Ben Campbell]

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).

Comment 6

[Alfred Peters [:infofrommozilla]]

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.