1899786 - Synchronous XMLHttpRequest prevents XML documents from being parsed/loaded when OMT decompression is enabled

Status: NEW

(Core :: Networking, defect)

Description

[Matthew Kogan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

Install RSSPreview (https://addons.mozilla.org/en-US/firefox/addon/rsspreview/) and NoScript (https://addons.mozilla.org/en-US/firefox/addon/noscript/) in Firefox 126.0 or newer, open an RSS feed (e.g. https://feeds.bbci.co.uk/news/world/rss.xml), hit Reload.

Actual results:

Either none of or only the first few of the articles are visible.

Expected results:

All of the articles should be visible.

This worked fine until updating to Firefox 126.0.
I've also reported it to the extension developers:
https://github.com/aureliendavid/rsspreview/issues/85
https://github.com/hackademix/noscript/issues/356

Comment 1

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

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

Comment 2

[Rob Wu [:robwu]]

Could you run mozregression to see if this is really caused by a change in Firefox, and not merely a coincidence?

https://mozilla.github.io/mozregression/

Comment 3

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (128.0a1/20240603160728), Beta (127.0/20240603152359) and Release (126.0.1/20240526221752) under Windows 10 x64 and Ubuntu 22.04 LTS.

The issue occurs as described in Comment 0.

Mozregression results:

2024-06-04T09:31:41.184000: DEBUG : Found commit message:
Bug 1356686: Put OMT decompression behind a pref r=necko-reviewers,valentin

Differential Revision: https://phabricator.services.mozilla.com/D204957

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a87db3b698e19b65bc001936fc7a8b80239a25dd&tochange=f5ac2d368c7d44f585bea0397dedcd879e2b8ab4

Comment 4

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

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

Comment 5

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

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

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

jesup or valentin, since you worked on the regressing bug, can you add any information or suggest an owner for this? Thanks!

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

OMT decompression can change the order of events and timing. Since data being received is not processed on MT, other data can jump 'ahead' of it in the MT event queues, other incoming data that arrives after the compressed data my get processed first, etc.

A profile or an rr/pernosco trace may help in tracking this down, but likely it's a problem in the extension. Happy to answer questions and provide debugging hints

Comment 8

[Matthew Kogan]

Here's a profile from the latest Nightly build: https://share.firefox.dev/4bV20SZ
I used the "Networking" settings - hope that was the right thing to do.

Comment 9

[Donal Meehan [:dmeehan]]

Could you take a look at the profile from Comment 8
Does it point to anything that can be fixed in time for Fx129?

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

A profile really doesn't tell me too much. What I would need is logs (via about:logging) with OMT decompression off, and with it on, loading the same page. I could at least look at what's different; however I'm not sure it's going to tell me much, as having decompression be asynchronous is totally valid from a web standards point of view. It can change the ordering of events; it could change the chunking size of data being delivered, etc, but none of that should matter to the web. Extensions are another matter; perhaps they could have a bug where they care. And in this case, it only fails if you combine those two specific extensions apparently; they work on their own.

Comment 11

[Matthew Kogan]

Attachment: omt_on.zip

Comment 12

[Matthew Kogan]

Attachment: omt_off.zip

Comment 13

[Matthew Kogan]

Logs attached as requested.

Comment 14

[Rob Wu [:robwu]]

I'll take a look to see if there is an issue specific to extensions.

Comment 15

[Rob Wu [:robwu]]

RSSPreview is not causing the issue, but just helpful in visualizing the impact.

The problem is caused by NoScript - it sends a sync XHR request (that it will handle) very early (at document-element-inserted), while the document is still parsing/loading. With OMT, it seems that the remainder of the document gets lost.

I can reproduce the issue without any extensions at all, and I will attach a test case shortly.

Comment 16

[Rob Wu [:robwu]]

Attachment: sync-xhr-at-document-start-web-only.zip

STR:

1. Download the zip file, and extract it. It contains server.mjs and data.xml.
   • server.mjs is a server that serves data.xml (with and without gzip compression), and also offers an API endpoint ("respondslow") that responds to network requests with a 2 second delay.
   • data.xml is a copy of https://feeds.bbci.co.uk/news/world/rss.xml, with a <script> at the start that sends a sync XHR to "respondslow".
2. Start the server, node server.mjs
3. Visit http://localhost:8080/data.xml?raw to see how it should look like.
4. Visit http://localhost:8080/data.xml

Expected:

• Step 3: There is a 2 second delay (from the sync XHR) and then a bunch of text is shown.
• Step 4: same as step 3.

Actual:

• Step 3: as expected.
• Step 4: 2 second delay as expected, but then the document is blank.

Comment 17

[Rob Wu [:robwu]]

Here is a profile captured with the STR: https://share.firefox.dev/45NoeEg

"localhost (1/2)" is the data.xml?raw request for reference (without compression).

"localhost (2/2)" is the data.xml request (the one with gzip that triggers the bug with OMT enabled)

Comment 18

[Rob Wu [:robwu]]

Adjusting title to make it more specific now that I have reduced the issue.

jesup - could you take a look? See comments 15, 16 17.