1870557 - Incremental display results in a blankish screen

Status: NEW

(Core :: Networking, defect, P2)

Description

[Bill Blake]

Steps to reproduce:

I wrote a server that creates an IRC-like display (chat area on top, input area on the bottom), using only CSS, an iframe, and chunked encoding--no javascript. It wasn't behaving correctly, so I reduced the code to a short test case (included as a file, written in perl). This test case sends an initial chunk to set up the screen followed by four chunks; those last four contain text to be displayed. There are no delays between sending the chunks. The HTTP connection is kept open after the five chunks are sent.

The User-Agent string sent by my browser is a fib, so I haven't included it. My browser is Firefox 116, running on FreeBSD 13.2. The browser and test code both run on the same machine.

Actual results:

Immediately on receiving the first chunk, the screen went from white to a slight blue color (not an expected color). And it stayed that way. On the bottom left, there was the expected "transferring data". The four chunks' text was never displayed.

Expected results:

The four chunks should have been displayed as four separate lines on the screen.

I can get this to work correctly by introducing a one second delay before any one of the four chunks. Once the display starts to show correctly, additional chunks display correctly regardless of the timing.

Killing the test program, thereby closing the connection, causes the expected display to appear.

I actually wrote the server about two years ago, and at that time the display worked correctly without any delays required. I then let the project go and just took it up again and found the issue. So there has been some intervening change.

Comment 1

[Bill Blake]

Attachment: perl program to show the failure

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Mayank Bansal]

Can you use Mozregression (https://mozilla.github.io/mozregression/) to find the range of changes that broke your application?

Comment 4

[Bill Blake]

(In reply to Mayank Bansal from comment #3)

Can you use Mozregression (https://mozilla.github.io/mozregression/) to find the range of changes that broke your application?

I have exactly no idea how to use that tool. But it looks system and data intensive, and I'm running on a tiny laptop with a small pipe. So I think it would be impracticable. But I did provide a test program so anyone who has perl installed on something sufficiently unix-like should be able to see what I saw.

Comment 5

[Manuel Bucher [:manuel]]

Regression range from mozregression: b538ca73..bd494168 (on linux)

7:34.02 INFO: Last good revision: b538ca7373143e97e0c5243dfaf6e941d9454d25 (2021-12-22)
7:34.02 INFO: First bad revision: bd494168b95a83344e778b5b4679b67101482118 (2021-12-23)
7:34.02 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b538ca7373143e97e0c5243dfaf6e941d9454d25&tochange=bd494168b95a83344e778b5b4679b67101482118

Comment 6

[Manuel Bucher [:manuel]]

The respective moz_logs are too big for bugzilla. File for future investigating are in a public google drive folder. I haven't taken a deeper look yet.

• good.moz_log
• bad.moz_log

Comment 7

[Valentin Gosu [:valentin] (he/him)]

This sounds like bug 1793342, but probably not the same issue.

Comment 8

[edgul]

@valentin, are you able to provide insight on the rank of this bug? Also if there are any meaningful actions we can take here?

Comment 9

[Valentin Gosu [:valentin] (he/him)]

I think we just need to investigate the testcase and attempt to fix it.
Unclear how important that is, or if it also affects H2 & H3, but it seems like a basic use case that should work.
Rank 0, or 1 would be reasonable.