Open Bug 1707302 Opened 3 years ago Updated 1 year ago

Failure to choose an application to open ftp link


(Core :: Networking: FTP, defect, P3)

Firefox 88





(Reporter: klaatu, Unassigned)



(Whiteboard: [necko-triaged])


(1 file)

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

Steps to reproduce:

After an update to Firefox 88.0, when I navigate to an ftp:// link, I'm asked to choose an application for opening the link.

When I choose "Firefox", a new tab opens and I'm prompted again to choose.

This is an infinite loop.

Actual results:

Choosing "Firefox" to open an FTP link opens a new tab to the same URL, and a new prompt to choose an application. This never gets resolved (up to 30 tabs; I stopped trying after that.)

If I choose "Chromium" or "Chrome", the FTP link opens correctly in the Chromium or Chrome browsers, as expected.

Expected results:

The ftp link should have opened in my Firefox browser, as it used to before updating to 88.0.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

It's because Firefox does not support FTP any more AFAIK. See

Component: Widget: Gtk → Networking: FTP

Could you tell us what distro you're using?

Flags: needinfo?(klaatu)
See Also: → 1678255, 1667468

I can confirm that this happens on RHEL 8 and Slackware 14.2 and Debian 10, but in every case I just download a build from:

I do this because all three of those tend to be very conservative in when they update Firefox, so I get the latest myself.

Flags: needinfo?(klaatu)

So, the easy fix for this is to remove Firefox from the FTP protocol handler.
Open the file at ~/.config/mimeapps.list and ~/.local/share/applications/mimeinfo.cache remove the lines containing FTP.
This problem is here because we've previously called but after disabling FTP we never called g_app_info_remove_supports_type

Blocks: kill-ftp

It seems calling g_app_info_remove_supports_type for x-scheme-handler/ftp only adds it to a [Removed Associations] section in mimeapps.list

The call to g_app_info_get_all_for_type which we use in the chooseApp dialog will still show it if it's in the default app list.

Sounds like a P3 to me, maybe even lower - please feel free to change my verdict if you disagree with it :)

Severity: -- → S3
Priority: -- → P3
Whiteboard: [necko-triaged]

Can you check with the latest Nightly or Beta?
This might have been fixed by bug 1599713.

Flags: needinfo?(klaatu)
See Also: → 1599713

Confirmed, the infinite loop doesn't happen any more.

Flags: needinfo?(klaatu)

(Tested with Firefox 102)

I'm using Firefox 102.0, and am still seeing a loop similar to that described.

Environment: Ubuntu 21.10 with LXQt and FileZilla installed.

Step: Follow an FTP link to text or image data.

Expected result: fetches data and displays it. Failing that there is an explanatory message telling me what is wrong and how I can see the data.

Actual result: Pop-up window 'Choose an application to open the ftp link' with Firefox as the only choice. Choosing 'FIrefox' and clicking 'Open Link' gives a white screen with the address in the tab but no feedback. Choosing 'Choose other application' and selecting /usr/bin/firefox opens a fresh tab which is also plain white without information. This then results in multiple blank tabs. FileZilla is not listed as an option. Selecting /usr/bin/filezilla seems to pass the command-line parameter OK (although Filezilla connects to the server after a warning but does not navigate to the correct directory or download the required file the way a browser would).

Comment: Possibly the fix has not yet made it into Firefox for Ubuntu 102.0. The explanation on the blog linked above for FIrefox deprecating anonymous FTP cites 'security' without explaining why FTP is any less secure than HTTP. My main concern is that much scientific data is still only available via FTP. Of course there are still ftp command-line clients that are unaffected by any security issue I am aware of. Removing basic web-browser functionality would seems to be a major regression. The blog has comments citing 'Also, a part of the FTP code is very old, unsafe and hard to maintain and we found a lot of security bugs in it in the past.' (unsafe in memory allocation or how?) Another commenter describes that as 'They dont make browsers for techies any more, they are for norms.' whatever that means. Techies may find another way of browsing FTP, but it's very frustrating when working and just expecting software to work or at least give a helpful error message.

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