1870557 - Incremental display results in a blankish screen

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

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]]

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]]

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]]

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.

Comment 10

[Kershaw Chang [:kershaw]]

I can reproduce this locally with the attached test case, and I confirm that the regression range in comment #5 is correct. I compared HTTP logs from a known-good and a known-bad build; both show Necko delivering 1275 bytes to the consumer, so this is unlikely to be a networking bug.

[Parent 84983: Main Thread]: D/nsHttp nsHttpChannel::OnDataAvailable [this=175849900 request=143859030 offset=0 count=1275]
[Parent 84983: Main Thread]: D/nsHttp sending progress and status notification [this=175849900 status=4b0006 progress=1275/-1]

Given the regression range, a likely regressor is Bug 1745142, which could affect how the data is parsed and the page is rendered.

Comment 11

[BugBot [:suhaib / :marco]]

:hsivonen, since you are the author of the regressor, bug 1745142, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 12

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

It's expected that a chat like this that doesn't declare the character encoding would show a blank page if it stalls the network stream before it has produced 1024 bytes of output.

This is by design, since the alternatives would make the encoding determination dependent on the wall clock, network packet boundaries, or similar (as in Chrome).

Chats like this can avoid the problem by declaring the character encoding.

Comment 13

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

Declaring the encoding on the HTTP layer works.

Declaring it in meta does not. I'll need to debug to see why that is, which is why I'm leaving this open.

Comment 14

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1745142

Comment 15

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

Attachment: Bug 1870557 - Ensure tree ops are flushed if network stalls right after encoding decision.

Comment 16

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

One-line fix, but I still need to figure out the best way for writing a test for this.

Comment 17

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

After checking on the web-platform channel, it seems that our test harness isn't equipped to test the painting of a top-level load that does not finish and that does not contain script, so let's land this without a test.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/192d5c8070a7
https://hg.mozilla.org/integration/autoland/rev/f0ceaf10485a
Ensure tree ops are flushed if network stalls right after encoding decision. r=edgar

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dcdaa803184b
https://hg.mozilla.org/integration/autoland/rev/c097eaf4ae69
Revert "Bug 1870557 - Ensure tree ops are flushed if network stalls right after encoding decision. r=edgar" for causing mochitests-plain failures in test_lookup_completion_telemetry.html.

Comment 20

[Serban Stanca [:SerbanS]]

Reverted this because it was causing mochitests-plain failures in test_lookup_completion_telemetry.html.

• Revert link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | toolkit/components/url-classifier/tests/mochitest/test_lookup_completion_telemetry.html | Lookup hit should be 1 for malware - got 2, expected 1

Comment 21

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

test_lookup_completion_telemetry.html passes for me locally. I suspect that there exists a possible timing that counts the preload of the malware script and the actual load of the malware script as distinct.

Comment 22

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=153913

Comment 23

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-24)]

The test itself is very recent from bug 1975198.

tihuang, does the guess from comment 21 look plausible?

Comment 24

[Tim Huang[:timhuang]]

It could be the case. We could disable preload for the test to see if the issue is resolved.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/32a6aab72901
https://hg.mozilla.org/integration/autoland/rev/a479e019c0c2
Ensure tree ops are flushed if network stalls right after encoding decision. r=edgar

Comment 26

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/a479e019c0c2