8-bit chars of news messages are displayed in RAW UTF-8 chars rather then properly decoded
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(Not tracked)
People
(Reporter: infofrommozilla, Unassigned)
References
Details
Attachments
(3 files)
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.
Reporter | ||
Comment 1•4 years ago
|
||
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
Reporter | ||
Comment 2•4 years ago
|
||
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
Reporter | ||
Comment 3•4 years ago
|
||
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
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
It's nearly the same.
Reporter | ||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
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).
Reporter | ||
Comment 6•3 years ago
|
||
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.
Description
•