1896297 - downloads.download api ignores content-disposition header

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[ntoan96]

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

Steps to reproduce:

I made a simple extension to download files from a server. In the background.js file, I use downloads.download api to download the file. The server should return a file with "content-disposition" header, value is "attachment; filename=<some name with white spaces>".

Actual results:

Firefox show the download window with "download" as filename. When I click save, the content of the file is as expected, but the filename is not.

Expected results:

Firefox should show the download window with "<some name with white spaces>" as file name.

By the way, the same extension works on both Chrome and Edge so I believe this is entirely firefox problem.

Comment 1

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

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

Comment 2

[:Gijs (he/him)]

Assuming this doesn't reproduce when not using the API, this sounds like a webextensions problem.

Comment 3

[Alex Cornestean]

Hello,

Would you be so kind as to attach an example extension exhibiting the behavior you reported?

Thank you !

Comment 4

[ntoan96]

Attachment: manget_firefox.zip

The extension file.

Comment 5

[ntoan96]

Hello, I just uloaded the extension to attachments. It is a small script to download manga chapters on mangadex and some other websites.

You can install it and then go to this page: https://mangadex.org/title/4141c5dc-c525-4df5-afd7-cc7d192a832f/blue-lock. Right click on any chapter, there should be a "Download chapter" entry in the context menu. Click it and you'll see it just pop up a download windows with "download" as the default name.

The extesion only sends a POST request to https://manget.fly.dev/download, with the json body
{
url: <chapter-url>
}

You can use postman or something to verify that the response has content-disposition with filename in it.

Comment 6

[:Gijs (he/him)]

Looks like this is from https://searchfox.org/mozilla-central/rev/0529464f0d2981347ef581f7521ace8b7af7f7ac/toolkit/components/extensions/parent/ext-downloads.js#842 ; that code doesn't wait for the request to start before asking for a filename, so it can't read the Content-Disposition header for a filename suggestion, either.

It should probably use a technique similar to "Save link as" in https://searchfox.org/mozilla-central/rev/0529464f0d2981347ef581f7521ace8b7af7f7ac/browser/base/content/nsContextMenu.js#1840-1842 , which will start the request, wait for the headers, and then ask for a location (with a timeout to start asking sooner if the http request takes too long to return headers, in which case it'd fall back to the current behaviour - that seems acceptable, otherwise the user clicks a thing and gets no feedback at all because the network is slow).

Hopefully we can refactor that code to make it a shared bit of downloads infra, instead of having it be specific to the context menu code there and the extensions code "rolling their own" to do the same thing.

Comment 7

[Alex Cornestean]

Hello and thank you for the additional resources !

I reproduced the issue on the latest Nightly (128.0a1/20240526212755), Beta (127.0b6/20240524102635) and Release (126.0/20240509170740) under Windows 10 and Ubuntu 22.04 LTS.

Performing the STR from Comment 5, shows that the downloaded file is named “download". Checking the network tab of the browser toolbox for the download request shows a POST request and the response header has content-disposition with filename in it. See the attached screenshot for more details.

Comment 8

[Alex Cornestean]

Attachment: 2024-05-27_10h14_56.png

Comment 9

[Rob Wu [:robwu]]

The current implementation fixes the filename before any network requests. To support the requested feature, the download internals should offer the ability to opt in to choosing a name later.