1426789 - StreamFilter only fires 'onstart' for Content-Disposition: attachment

Status: RESOLVED DUPLICATE of bug 1787119

(WebExtensions :: Request Handling, defect, P3)

Description

[allanlw]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

In investigation of a bug report for my addon (gps-detect, which scans transparently scans downloaded images for GPS EXIF data) I noticed that webRequest.StreamFilter does not fire events correctly when the server serves "Content-Disposition: attachment"


I tested this with two copies of an image, serving the same headers with the only difference being a "Content-Disposition: attachment; filename=foo.jpg" response header. The file that was being served without the header had all the events trigger correctly, and the file with the Content-Disposition did not.


Actual results:

The browser.webRequest.onHeadersReceived event fires as expected upon navigation to the attachment URL.

The call to filter browser.webRequest.filterResponseData succeeds, and the 'onstart' event fires for it, but no further events fire on the filter. In the onstart event, the status field of the filter is set to 'transferringdata'.


Expected results:

Either the ondata and onstop events should be called as for other requests or some developer-visible error should be triggered.

If this is intended behavior then it should be documented.

Comment 1

[kernp25]

Maybe the StreamFilter should check, if there is a content-disposition attachment header, and then do not attach the listener?

Comment 2

[Rob Wu [:robwu]]

(keeping the needinfo in my queue)

If you want to help, please attach a test case: extension, and server (online or a local script, e.g. in Node.js or Python) so I don't have to create those examples myself.

Comment 3

[kernp25]

Attachment: background.zip

Comment 4

[kernp25]

Test link

Comment 5

[kernp25]

Maybe the StreamFilter should check, if there is a content-disposition attachment header, and then do not attach the listener?

Comment 6

[kernp25]

Attachment: dummy.pdf

Comment 7

[kernp25]

Attachment: background.zip

Comment 8

[kernp25]

Install background.zip and click on dummy.pdf

Comment 9

[kernp25]

Can you confirm that it only fires the onstart event?

Comment 10

[Shane Caraveo (:mixedpuppy)]

loos like rob took this this already, no need for both of us.

Comment 11

[Alex Cornestean]

Hello,

Using the attached extension and following the STR from Comment 8, I have managed to reproduce the issue on the latest Nightly (71.0a1/20191015213743), Beta (70.0/20191014163058) and Release (69.0.3/20191009172106) under Windows 10 Pro 64-bit and MacOS Catalina 10.15.

With the content-disposition attachment header, only the onstart event fires, while without the header all 3 events (onstart, ondata and onstop) are fired.

Comment 12

[Rob Wu [:robwu]]

Looks like filter.onstart is not even firing with the given test case. To rule out it being a PDF-specific issue, I modified the test extension and changed the URLs in manifest.json and background.js to "https://*.bmoattachments.org/attachment.cgi?id=*" and clicked on the zip file.

To check that the extension would otherwise be able to match the request (if not for it being a download), I forced content-type to text/plain; charset=utf-8 and content-disposition to inline. With that I was able to see start, data and stop.

When I add event.onerror, filter.error is "Invalid request ID". That makes this bug a duplicate of bug 1870522.

Comment 13

[Rob Wu [:robwu]]

FYI, when I run with a debug build and some extra environment variables to enable logging, I get the following output. I think that the StreamFilter gets lots along the way, but haven't taken a closer look about what's happening

MOZ_LOG=DocumentChannel:5,HelperAppService:3,URILoader:5,sync,timestamp web-ext run -f /path/to/gecko/objdir-debug/dist/NightlyDebug.app/Contents/MacOS/firefox -v -u https://bugzilla.mozilla.org/show_bug.cgi?id=1426789 --pref=devtools.console.stdout.content=true --pref=browser.dom.window.dump.enabled=true | grep -v 'node_modules'

2024-06-05 21:36:21.426328 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentLoadListener ResumeSuspendedChannel [this=156e70e80]
2024-06-05 21:36:21.426441 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentChannelParent dtor [this=14c5ef340]
2024-06-05 21:36:21.427362 UTC - [Parent 14388: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo dtor [this=156dcdd80]
2024-06-05 21:36:26.200022 UTC - [Child 14391: Main Thread]: V/DocumentChannel DocumentChannelChild ctor [this=10790de30, uri=https://bugzilla.mozilla.org/attachment.cgi?id=9099327]
2024-06-05 21:36:26.200036 UTC - [Child 14391: Main Thread]: D/URILoader nsURILoader::OpenURI for https://bugzilla.mozilla.org/attachment.cgi?id=9099327
2024-06-05 21:36:26.200040 UTC - [Child 14391: Main Thread]: D/URILoader nsURILoader::OpenChannel for https://bugzilla.mozilla.org/attachment.cgi?id=9099327
2024-06-05 21:36:26.200046 UTC - [Child 14391: Main Thread]: D/URILoader [0x1079f0b20] nsDocumentOpenInfo::Prepare
2024-06-05 21:36:26.233907 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentChannelParent Init [this=10903db20, uri=https://bugzilla.mozilla.org/attachment.cgi?id=9099327]
2024-06-05 21:36:26.233922 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentLoadListener [106c5a500] OpenDocument [uri=https://bugzilla.mozilla.org/attachment.cgi?id=9099327]
2024-06-05 21:36:26.235102 UTC - [Parent 14388: Main Thread]: D/URILoader [0x10d80a480] nsDocumentOpenInfo::Prepare
2024-06-05 21:36:27.702168 UTC - [Parent 14388: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo OnDocumentStartRequest [this=10d80a480]
2024-06-05 21:36:27.702172 UTC - [Parent 14388: Main Thread]: D/URILoader [0x10d80a480] nsDocumentOpenInfo::OnStartRequest
2024-06-05 21:36:27.702175 UTC - [Parent 14388: Main Thread]: D/URILoader   HTTP response status: 200
2024-06-05 21:36:27.702178 UTC - [Parent 14388: Main Thread]: D/URILoader [0x10d80a480] nsDocumentOpenInfo::DispatchContent for type ''
2024-06-05 21:36:27.702181 UTC - [Parent 14388: Main Thread]: D/URILoader   Got type from channel: 'application/x-zip-compressed'
2024-06-05 21:36:27.702188 UTC - [Parent 14388: Main Thread]: D/URILoader   forceExternalHandling: yes
2024-06-05 21:36:27.702193 UTC - [Parent 14388: Main Thread]: D/URILoader   Passing load off to helper app service
2024-06-05 21:36:27.702219 UTC - [Parent 14388: Main Thread]: I/HelperAppService Getting mimeinfo from type 'application/x-zip-compressed' ext ''
2024-06-05 21:36:27.708001 UTC - [Parent 14388: Main Thread]: I/HelperAppService Searched extras (by type), rv 0x80040111
2024-06-05 21:36:27.708444 UTC - [Parent 14388: Main Thread]: I/HelperAppService Type/Ext lookup found 0x11ba048b0
2024-06-05 21:36:27.708463 UTC - [Parent 14388: Main Thread]: D/URILoader   After dispatch, m_targetStreamListener: 0x135f7d5f0, rv: 0x00000000
2024-06-05 21:36:27.722137 UTC - [Parent 14388: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo targeted to non-default listener [this=10d80a480]
2024-06-05 21:36:27.722147 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentLoadListener DisconnectListener [this=106c5a500, aStatus=804b0004, aLoadGroupStatus=0, aContinueNavigating=0]
2024-06-05 21:36:27.722157 UTC - [Parent 14388: Main Thread]: V/DocumentChannel DocumentLoadListener Disconnect [this=106c5a500, aContinueNavigating=0]
2024-06-05 21:36:27.722679 UTC - [Child 14391: Main Thread]: D/URILoader [0x1079f0b20] nsDocumentOpenInfo::OnStartRequest
2024-06-05 21:36:27.722684 UTC - [Child 14391: Main Thread]: E/URILoader   Request failed, status: 0x804B0004
2024-06-05 21:36:27.722726 UTC - [Child 14391: Main Thread]: D/URILoader [0x1079f0b20] nsDocumentOpenInfo::OnStopRequest
[Parent 14388, Main Thread] WARNING: The dialog should nullify the dialog progress listener: file /path/to/gecko/uriloader/exthandler/nsExternalHelperAppService.cpp:2260
console.debug: "err_from_ext" (void 0) "Invalid request ID" ({get isTrusted() {
    [native code]
}})
2024-06-05 21:36:27.801306 UTC - [Parent 14388: Main Thread]: I/HelperAppService nsExternalAppHandler::OnStopRequest
  mCanceled=0, mTransfer=0x10d8808e0, aStatus=0x00000000
2024-06-05 21:36:27.801361 UTC - [Parent 14388: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo dtor [this=10d80a480]
  aSaver=0x138468d70, aStatus=0x00000000, mCanceled=0, mTransfer=0x10d8808e0

The console.debug call is from filter.onerror = e => console.debug("err_from_ext", event.error, filter.error, event);

Comment 14

[Rob Wu [:robwu]]

Attachment: streamfilter-bmo-log-error.zip

For future reference, this was the updated test extension that I used to execute the above test.

For convenience I used web-ext run to launch it, but you can also visit about:debugging, This Nightly and select the zip file in Load temporary add-on.

Comment 15

[Rob Wu [:robwu]]

FYI: further analysis was posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1787119#c6