Open Bug 1881964 Opened 1 year ago Updated 4 months ago

Port Bug 1754004 - Migrate IPCStream to use DataPipe

Categories

(Thunderbird :: Upstream Synchronization, defect)

Product:
Thunderbird
Component:
Upstream Synchronization
Type:
defect

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: infofrommozilla, Assigned: welpy-cw, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1881964 - Limit line length in NntpChannel for different stream listeners. r=mkmelin
48 bytes, text/x-phabricator-request
Details | Review

For NNTP articles with an overlong line, TB cuts it off after the first 64 KiB.

For testing purposes, I have posted an article in the misc.test group.

Message-ID: <urf37s$j5l0$1@solani.org>
Subject: Test article with long line 64kiB+
From: Alfred Peters < ### @###.de>
Newsgroups: misc.test
Date: Sun, 25 Feb 2024 10:53:10 +0100

The 4th line of the article is 65546 bytes (incl. <CRLF>) long and ends with:
64_KiB_are_reached_after_the_angle_bracket--->XXXXXXXX<CRLF>

In the display, everything after the angle bracket is cut off. This is followed by the 5th line without a line break.

Yes, such an article violates the "Line Length Limits" from RFC5322 and therefore doesn't normally appear in newsgroups.

However, someone should at least check whether other parts of the program are also affected.

Nika Layzell has already written a few words about the cause of the fault in Bug 1843752 comment #18.

If necessary, I can quote the comment here.

(In reply to Alfred Peters [:infofrommozilla] from comment #1)

Nika Layzell has already written a few words about the cause of the fault in Bug 1843752 comment #18.

Flags: needinfo?(mkmelin+mozilla)
See Also: → 1917447

With daily, I tried posting 70K of data on one line, and the posted message is fully read.
Alfred, can you confirm?

Or can you point me to a server + message that shows problematic behavior?

(In reply to Magnus Melin [:mkmelin] from comment #3)

With daily, I tried posting 70K of data on one line, and the posted message is fully read.

I don't think so. 😉
That shouldn't and isn't actually possible with TB. TB automatically switches to Base64 (with format=flowed) or Quoted-Printable (without format=flowed) for lines longer than ~998 characters.

This automatically avoids such overlong lines in the RAW article.

Alfred, can you confirm?

In fact, I can confirm that the bug has been fixed in the current Daily. The line from article <news:urf37s$j5l0$1@solani.org> is displayed completely.
Whereas the bug in 134.0b4 is still visible.

Can you narrow down in which bug this was fixed?

Which news server has that article?

(In reply to Alfred Peters [:infofrommozilla] from comment #5)

In fact, I can confirm that the bug has been fixed in the current Daily. The line from article <news:urf37s$j5l0$1@solani.org> is displayed completely.

That is wrong. The bug is still there. Only the offline mode must not be activated for the group.

(In reply to Magnus Melin [:mkmelin] from comment #6)

Which news server has that article?

The article <news:urf37s$j5l0$1@solani.org> has already expired on many news servers.

I have re-posted it: <vlb4if$1pvqm$1@solani.org>

This should now be available on all servers in the "misc.test" group.

FWIW, accessing the article directly via news:vlb4if$1pvqm$1@solani.org doesn't work correctly either, only

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStreamListenerTee.onDataAvailable] NntpChannel.sys.mjs:318

is displayed in the error console. In ESR 128 with "Open messages in: A new message window" set however, the article is shown in a new message window after the main Thunderbird window has been closed (by Ctrl+W), but the fourth and fifth lines are missing. This does not happen in Daily, where just

JavaScript error: resource:///modules/MailUtils.sys.mjs, line 506: NS_ERROR_NOT_AVAILABLE:

appears in the system console.

I can load and display the article from different servers. (local, news.individual.de, news.eternal-september.org, news.solani.org and others)
Tested with TB128.5.2esr, TB134.0B4, daily and local debug build.

I haven't tested every single combination, but nowhere did this error message arise.

How did you get to the article?
My STR:

  • Set up the server.
  • Subscribe to the “misc.test” group.
  • Update group (500 articles are enough)
  • Search for subject: "Test article with long line 64kiB+" and display the article.

I use the Classic View with the Preview Pane switched on.
But View this Article in new Tab or Window from there also works.

Assignee: nobody → h.w.forms
Status: NEW → ASSIGNED

(In reply to Alfred Peters [:infofrommozilla] from comment #11)

How did you get to the article?

By just clicking on the link. Alternatively, you can execute thunderbird news:vlb4if\$1pvqm\$1@solani.org. When a 'news:' URL is opened directly, the article is saved to disk as a temporary file before it is displayed. In this case, the NS_ERROR_FAILURE mentioned above originates here, since an nsMsgSaveAsListener uses a buffer of only 16k.

My STR:

  • Set up the server.
  • Subscribe to the “misc.test” group.
  • Update group (500 articles are enough)
  • Search for subject: "Test article with long line 64kiB+" and display the article.

Yes, I did that as well. While there is no error message this time, the overlong line is cut off after 64k, missing the CRLF.

The patch addresses both issues.

(In reply to Hartmut Welpmann [:welpy-cw] from comment #13)

The patch addresses both issues.

Not really.
It allows the article to be displayed in the case of the bug you described in (comment #9). However, it then only displays the first 16k characters.

The described effect of the missing characters does not actually change.

The actual idea behind this bug was to completely move away from the static buffer and towards the dynamic buffer.

(In reply to Alfred Peters [:infofrommozilla] from comment #14)

(In reply to Hartmut Welpmann [:welpy-cw] from comment #13)

The patch addresses both issues.

Not really.
It allows the article to be displayed in the case of the bug you described in (comment #9). However, it then only displays the first 16k characters.

The described effect of the missing characters does not actually change.

You mentioned RFC 5322 Line Length Limits in comment #0. It states "Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF." Personally, I think it's okay to truncate lines that clearly violate the RFC, if the message is otherwise displayed correctly. The patch is fairly simple, and any performance impact or regression is highly unlikely. But your (and other people's) mileage may vary, let's wait for Magnus' opinion.

The actual idea behind this bug was to completely move away from the static buffer and towards the dynamic buffer.

It wasn't clear to me that this was the intent of the bug.

(In reply to Alfred Peters [:infofrommozilla] from comment #0)

Yes, such an article violates the "Line Length Limits" from RFC5322 and therefore doesn't normally appear in newsgroups.

Besides, you can still get such a broken article in its entirety if you download it for offline use.

However, someone should at least check whether other parts of the program are also affected.

Been there, done that, found two places :)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: