1943972 - Save as dialog does not appear until first byte of the response body is received

Status: UNCONFIRMED

(Core :: DOM: Navigation, enhancement)

Description

[Corentin Schreiber [:cschreib]]

Attachment: test_http.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

I am developing a web server, from which users can download files. These files take a few seconds to generate, and cannot be generated ahead-of-time; only when a user requests them. The server responds to such requests by first sending the HTTP response headers (without "Content-Length"), which can be written immediately, then generating the file, and sending the generated file as the response body. I have attached a minimal reproducing server application that behaves like this; this is a C++ application using cpp-httplib, compile it as "g++ test_http.cpp -o test_http" then run it.

I have a Firefox (v132) window open. Firefox is configured to always ask where to save files. I input the server's URL then press enter.

Actual results:

The "Save As..." dialog waits for the file to be generated on the server before appearing. Using Wireshark, I could check that Firefox had received (and acknowledged) receipt of the response header, and just waited for the response body to be sent before showing the "Save As..." dialog. Through experimentation, I discovered that Firefox appears to wait until at least 1 byte of data from the file is sent (in the response body), before the "Save As..." dialog appears.

Expected results:

I expected Firefox to display the "Save as..." dialog as soon as the response headers were received, so that generating the file and downloading it could happen in the background while the user picks a save location. Indeed, the headers are all that is needed (they contain the suggested file name, content type, etc.); there should be no need to wait for a single byte from the body.

Chromium behaves as I expect; the "Save as..." dialog appears instantly, does not wait for the body to be sent.

Comment 1

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

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

Comment 2

[Corentin Schreiber [:cschreib]]

I forgot to mention that the server URL to trigger the download is http://127.0.0.1:8080/hi

Comment 3

[edgul]

It's not totally clear to me what the desired behaviour should be here.
It's also not obvious that the problem is with Necko. Moving to Downloads panel for input.

Comment 4

[:Gijs (he/him)]

The save as dialog comes up from OnStartRequest inside nsExternalAppHandler, here (with some more indirection).

We can't show it before we receive headers (as they determine mimetype, filename, etc.), but off-hand I don't think we don't actually depend on the bytes in the content. But also, I'm not aware of another nsIChannel callback that happens any earlier than OnStartRequest, and I don't know at what point in the loading process docshell/browsingcontext code decides to hand this to the external helper app service.

I don't know whether/how onStartRequest depends on there being non-0 bytes of content, other than headers, at the network level, or if we depend on that in the docshell code when trying to determine if we can display content inline, especially for content that may come without adequate mimetype information. I also don't know what the relevant specs say about this (ie at what point the UA is supposed to evaluate this).

Hopefully the docshell and/or network people can help.