1667468 - [Linux] Infinite tab loop when network.ftp.enabled=false and Firefox is set as handler app for FTP

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P3)

Description

[u123541]

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

Steps to reproduce:

Using 82.0a1, I clicked an FTP link. When asked to use Firefox or Choose another program, I selected Firefox.

Actual results:

FF started opening new tabs non-stop until I Quit. No other way to stop it. On restart, I was upgraded to 83.0a1 and as soon as FF starts, it resumes opening tabs ad infinitum... I am using FF on another local userid (Linux ) to report this -- trying to find how to edit which tabs are to be ignored/deleted. Once I can restart on my main userid, I'll update with the link...

Expected results:

Open ONE tab.

Comment 1

[u123541]

ARGH... I could really use a clue on how to get at the window/tab selector where I can select which windows/tabs are to be opened; or was this feature removed? At the moment, FF starts and resumes opening FTP tabs. I thought closing that window would resolve the issue; BUT FF simply continues opening FTP tabs on the now current top window...

Comment 2

[u123541]

Disconnected from network and FF still opens tabs in a loop...

Comment 3

[Negritas Sergiu, Desktop QA]

Hello I have tried to reproduce the issue with the STR provided in the description on Windows 10 with VirtualMachine Ubuntu 20.04 with firefox Nightly 83.0a1(2020-09-25).
Could you please answer the following questions in order to investigate it further?

1. Does this issue happen with a new profile? Here is a link on how to create a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Are you using add-ons? If so could you please list them?
3. Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
4. Can you provide the FTP link that has created this issue?

Comment 4

[u123541]

This is the link that came up over and over....
ftp://wakeftp.co.wake.nc.us/gis/Webdownloads/ARCHIVED_DATA
HOWEVER, just now tried ftp://home/pfortin/Downloads and tabs started opening; so the target is immaterial. In fact, I see that entering simply ftp:/ or ftp:// or ftp:/// takes me to my search engine (duckduckgo); but ftp:///home starts opening tabs.
This first occurred on 82.0a1; but on restart it was updated to 83.0a1

Originally, each time I started FF, tabs kept opening without any input from me. Eventually, I tried Ctrl+W as fast as I could, and was able to overtake the openings. Just tried the link again on my main browser instance (83.0a1 (2020-09-25) (64-bit)) and tabs started opening.
On a mostly virgin instance, after enabling ftp, the ftp directory appears as expected. Looking deeper into the two instances:
Test: network.ftp.enabled had to be made true before ftp:// wold work. No loop.
Main: network.ftp.enabled is false; yet ftp always worked... I've been using Nightly for years.
All other mentions of "ftp" are defaulted in both instances.
Main addons:
AdBlock,
Adblock Plus - free ad blocker
Dessenter Extension
Download YouTube Videos as MP4
Easy Youtube Video Downloader Express
Emoji Keyboard - Emojis For Firefox
Firefox Multi-Account Containers
No-Script Suite Lite
Tab Tree
User Agent Switcher
User-Agent Switcher
Video Downloader professional
Test addons: none

Unlike when this first triggered, I can get out of the loop easily with multiple Ctrl+W, so it's easy for me to test.
Is there a way to provide just the non-default about:config entries for you? Anything else I can provide?

Comment 5

[Negritas Sergiu, Desktop QA]

Hello!
Thank you for your response. Unfortunately I'm still unable to reproduce the issue. I will assign this issue to a component so one of our developers could look more into it. If it's not the right component please feel free to change it to an appropriate one.

Comment 7

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

I see setting Firefox as the default ftp handler doesn't work on Windows - which is good.
We need to make sure we can't do that on Linux & OSX as well.

Comment 8

[Kershaw Chang [:kershaw]]

I guess we might need to add some hacky check in HandlerService.js to avoid setting firefox as ftp handler when network.ftp.enabled is false.
Gijs, what do you think?

Comment 9

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Attachment: Bug 1667468 - Don't register browser as ftp handler when ftp is disabled

Comment 10

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

I think the attached code might help a little. I haven't tested the OSX part. Feel free to commandeer the patch.

Comment 11

[:Gijs (he/him)]

The code from bug 1496380 should be stopping this on macOS and Windows. Has someone tested mac? I can't reproduce on macOS myself (I get an external protocol handler prompt; even if I pick nightly and ask it not to ask me again, it keeps asking, which is the expected behaviour), at least... I don't know if comment 7 implies that this indeed also working correctly on Windows - Valentin ?

For Linux, adding the required API to detect this in the general case is bug 1599713, which has been too low-prio for me to investigate and work on. It should be pretty straightforward for someone familiar with GIO and other Linux APIs to handle default applications.

Comment 12

[:Gijs (he/him)]

Also, AFAICT, we already do not set Firefox as default for FTP on macOS... I had to get swiftdefaultapps to do so manually.

Comment 13

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

I don't have a Mac to test on but I assumed it might be the case considering we only fixed the ftp registration for windows (bug 1629636).
If it's not a problem that's great!

Comment 14

[Kershaw Chang [:kershaw]]

I can reproduce this on macOS by adding "ftp":{"action":4} manually in the handlers.json.

Comment 15

[:Gijs (he/him)]

(In reply to Kershaw Chang [:kershaw] from comment #14)

I can reproduce this on macOS by adding "ftp":{"action":4} manually in the handlers.json.

I don't need to set this manually, I can set it by ticking the checkbox in the prompt, but I still get prompted about opening the URL.

Can you test a clean profile? Anything else that might impact this? How are you testing - I'm putting the link (e.g. ftp://ftp.mozilla.org/) in the address bar and hitting enter.

Comment 16

[:Gijs (he/him)]

Perhaps more concretely, what does running Cc["@mozilla.org/uriloader/external-protocol-service;1"].getService(Ci.nsIExternalProtocolService).isCurrentAppOSDefaultForProtocol("ftp") in the browser console return (and can you debug in the compiled code what the mismatch is about?)

Comment 17

[Kershaw Chang [:kershaw]]

I can also reproduce this by simply ticking the checkbox in the prompt.

The result of isCurrentAppOSDefaultForProtocol("ftp") is false and the mismatch is:

selfURL
file:///Users/changkershaw/work/gecko/objdir/dist/NightlyDebug.app/

handlerBundleURL
file:///Applications/Firefox.app/

Note that I can make isCurrentAppOSDefaultForProtocol("ftp") return true by using swiftdefaultapps to change ftphandler to NightlyDebug.app, but the prompt still shows and ask me if I want to use NightlyDebug to open the ftp link. I think we should always ask users to choose an external app, not to choose between external app and NightlyDebug.

Comment 18

[:Gijs (he/him)]

(In reply to Kershaw Chang [:kershaw] from comment #17)

I can also reproduce this by simply ticking the checkbox in the prompt.

The result of isCurrentAppOSDefaultForProtocol("ftp") is false and the mismatch is:

selfURL
file:///Users/changkershaw/work/gecko/objdir/dist/NightlyDebug.app/

handlerBundleURL
file:///Applications/Firefox.app/

OK, so what's happening here is that you don't use the profile manager by default and so Firefox starts up with the new URI, and hands the URI back to nightly-debug? If you make nightly-debug the default for ftp URIs, the problem doesn't happen?

We explicitly decided not to deal with that case in bug 1496380 (cf. https://phabricator.services.mozilla.com/D48742#inline-300614 ). The understanding there seems to be that Firefox.app shouldn't be delegating to NightlyDebug.app if they're not using the same profile. If that's still happening, that feels like it should be a separate bug to this one, ideally with more details - as the real issue there would be profile selection.

Note that I can make isCurrentAppOSDefaultForProtocol("ftp") return true by using swiftdefaultapps to change ftphandler to NightlyDebug.app, but the prompt still shows and ask me if I want to use NightlyDebug to open the ftp link. I think we should always ask users to choose an external app, not to choose between external app and NightlyDebug.

You can file a separate bug about improving this flow, but it's not straightforward and probably not a priority for now. IIRC we only have infra to get the system default from the OS -- not "all the apps that told the OS they can handle these URIs". So we list the OS default, plus items that the user has manually added as helper apps. So in terms of straightforward fixes, we could hide an item referring to the current app, so that only the "choose an app" row shows up. That still doesn't sound great, it feels like really we should be telling the user in some way "hey, you configured your OS to open whatever: links with Firefox but we don't know how to open those links". Anyway, fodder for a separate bug.

Anyway, it sounds like we've established that this is basically a result of bug 1599713. If someone has the knowledge of linux default checks to address that, that'd be great - it basically boils down to an OS-specific implementation of the isCurrentAppOSDefaultForProtocol XPCOM method.

Comment 19

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #18)

We explicitly decided not to deal with that case in bug 1496380 (cf. https://phabricator.services.mozilla.com/D48742#inline-300614 ). The understanding there seems to be that Firefox.app shouldn't be delegating to NightlyDebug.app if they're not using the same profile. If that's still happening, that feels like it should be a separate bug to this one, ideally with more details - as the real issue there would be profile selection.

Needinfo for this part. :-)

Comment 20

[Kershaw Chang [:kershaw]]

If I tested this correctly, I think we have a separate bug you said.
In my test, I used SwiftDefaultApp to set default app for ftp to NightlyDebug.app and open a ftp link with Firefox Nightly.app.
It turned out that the tab is opened on NightlyDebug.app, not Firefox Nightly.app.

Comment 21

[:Gijs (he/him)]

(In reply to Kershaw Chang [:kershaw] from comment #20)

If I tested this correctly, I think we have a separate bug you said.
In my test, I used SwiftDefaultApp to set default app for ftp to NightlyDebug.app and open a ftp link with Firefox Nightly.app.
It turned out that the tab is opened on NightlyDebug.app, not Firefox Nightly.app.

OK, can you file one please? :-)

Comment 22

[Kershaw Chang [:kershaw]]

(In reply to :Gijs (he/him) from comment #21)

(In reply to Kershaw Chang [:kershaw] from comment #20)

If I tested this correctly, I think we have a separate bug you said.
In my test, I used SwiftDefaultApp to set default app for ftp to NightlyDebug.app and open a ftp link with Firefox Nightly.app.
It turned out that the tab is opened on NightlyDebug.app, not Firefox Nightly.app.

OK, can you file one please? :-)

Bug 1678313 filed.

Comment 23

[u123541]

Closing.
Leaving Mozilla products due to https://blog.mozilla.org/blog/2021/01/08/we-need-more-than-deplatforming/

Comment 24

[:Gijs (he/him)]

This is fixed by bug 1678255 on Firefox 88.