1870522 - filterResponseData fail on web requests that results with a download

Status: RESOLVED DUPLICATE of bug 1787119

(WebExtensions :: Request Handling, defect)

Description

[ice_qub3+mozbugzilla]

Steps to reproduce:

Browser: Firefox developer edition version 121.0b9 (64-bit)
Channel: aurora
Operating system: Windows 11 (version 23H2)

1. I created a dummy web extension
2. loaded it from files
3. navigated to https://fastest.fish/test-files
4. downloaded a file

reproduction code:
https://github.com/IceQub3/firefox-filterResponseData-bug

Most of the reproduction code is taken from an example that is available on MDN.
This bug also reproduces with other downloads like Chrome download and Firefox Installer download

Actual results:

While all web request have been intercepted by filterResponseData successfully, specifically web requests of file downloads fail.
Where onerror event is emitted and webRequest.StreamFilter.error is "Invalid request ID"

Expected results:

Download web request should be intercepted successfully by the extension
according to documentation.

Comment 1

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

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

Comment 2

[ice_qub3+mozbugzilla]

I can also reproduce this bug on Firefox 120.0.1 (64-bit)

Comment 3

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (123.0a1/20231218171757), Beta (122.0b1/20231218153201) and Release (121.0/20231211174248) under Windows 10 x64 and Ubuntu 22.04 LTS.

I loaded the extension via about:debugging and then accessed https://fastest.fish/test-files. When the file starts downloading, an onBeforeRequest is logged to console which has webRequest.StreamFilter.error showing as "Invalid request ID". Immediately after an onerror is also logged to console.

For more details, see the attached screenshot.

Comment 4

[Alex Cornestean]

Attachment: 2023-12-19_10h24_31.png

Comment 5

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

The severity field is not set for this bug.
:rpl, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

Redirecting to Rob, he was already looking into this.

Comment 8

[Rob Wu [:robwu]]

I took a look at the issue in another bug, and posted some logging at https://bugzilla.mozilla.org/show_bug.cgi?id=1426789#c12

From the debug build logs, in https://bugzilla.mozilla.org/show_bug.cgi?id=1426789#c13, I see that the immediate trigger for disconnecting is ParentProcessDocumentOpenInfo::OnDocumentStartRequest. That calls ParentProcessDocumentOpenInfo ::DisconnectChildListeners, which in its turn calls DocumentLoadListener::DisconnectListeners, which has the following comment:

  // TODO: If we retargeted the stream to a non-default handler (e.g. to trigger
  // a download), we currently never attach a stream filter. Should we attach a
  // stream filter in those situations as well?
  mStreamFilterRequests.Clear();

I suppose that the answer here would be "Yes", but I don't know how to do that.

Nika - do you have any suggestions on what to do here?

Comment 9

[Rob Wu [:robwu]]

I'm going to mark this as a duplicate of bug 1787119 because that was filed earlier and had a regression range narrowed down to one day of pushes.

I'll copy the above comment to the other bug and add a needinfo.