Open Bug 1937306 Opened 8 months ago Updated 8 months ago

browser.downloads.download downloads a file without an extension

Categories

(WebExtensions :: General, defect, P3)

defect

Tracking

(firefox133 affected, firefox134 affected, firefox135 affected)

Tracking Status
firefox133 --- affected
firefox134 --- affected
firefox135 --- affected

People

(Reporter: kernp25, Unassigned)

References

Details

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

Steps to reproduce:

chrome.downloads.download({ url: "https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch" });

Actual results:

In Firefox the file will be Using_Fetch. In Google Chrome the file will be Using_Fetch.htm.

Can you set the bug to NEW?

Maybe you know what must be changed in the code?

Flags: needinfo?(rob)

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.

Component: Untriaged → File Handling
Product: WebExtensions → Firefox

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 135.0a1(2024-12-17) and 133.0.3 on Ubuntu 22.04 and macOS 15.2
Could you please answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
  3. Do you have any addons installed? If yes could you please list them?
  4. Could you please provide more detailed steps on how to reproduce the issue?
Flags: needinfo?(kernp25)

FWIW Marco tried and can reproduce the issue, but we feel the initial investigation should happen on the webextension side.

Component: File Handling → General
Flags: needinfo?(kernp25)
Product: Firefox → WebExtensions

Hello,

I reproduced the issue on the latest Nightly (135.0a1/20241222211804), Beta (134.0b10/20241213091550) and Release (133.0.3/20241209150345) under Windows 10 and Ubuntu 24.04 LTS.

Having Download Manager (S3) (https://addons.mozilla.org/en-US/firefox/addon/s3download-statusbar/) installed, running chrome.downloads.download({ url: "https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch" }); or browser.downloads.download({ url: "https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch" }); in the add-on console will download a Using_Fetch file with no file extension, as described in Comment 0.

Status: UNCONFIRMED → NEW
Ever confirmed: true

When the filename property is not passed to downloads.download(), it is up to the browser to propose a filename. Firefox's current implementation for extensions is to generate the name based on the URL. Its implementation is at https://searchfox.org/mozilla-central/rev/21710237a214fdb72d0799c297da4fb9b60ccff9/toolkit/components/extensions/parent/ext-downloads.js#832-833,837

This differs from when a download is initiated on the web, where the suggested file name is also dependent on what the server suggests. To implement that, we would have to refactor the implementation of the downloads API, to determine the final filename shortly after the response is received. Doing so is also a prerequisite for bug 1254327 and bug 1896297.

One difficulty in implementing that is that we currently want the final file name before the Save As dialog is shown. If we were to wait for the server response, there can be a longer delay before the Save As dialog is shown, which may be undesirable.

Flags: needinfo?(rob)
See Also: → 1254327, 1896297
Severity: -- → S4
Priority: -- → P3

(In reply to Rob Wu [:robwu] from comment #6)

One difficulty in implementing that is that we currently want the final file name before the Save As dialog is shown. If we were to wait for the server response, there can be a longer delay before the Save As dialog is shown, which may be undesirable.

FWIW the way Firefox solves this for "save link as" (which has essentially the same problem) is to have a pref-based 4s timeout to get the header results back (pref is browser.download.saveLinkAsFilenameTimeout). No, I'm not joking:

https://searchfox.org/mozilla-central/rev/b6718bf263ae780289da471f0ea35797a09e2f05/browser/base/content/nsContextMenu.sys.mjs#1867-1868,2009-2014,2056-2059

You need to log in before you can comment on or make changes to this bug.