[Description:]

On Mac, when attempting to open a file that doesn't have a default, if using the system Choose Application with "always use this application to open file links" a "file" type is added to the Applications.

[Environment:]

94.0.2
96
97.0b8
98.0a1 2022-01-26

Mac 11
(not reproducible) Windows 10
(not reproducible) Ubuntu 20

[Steps:]

1. New profile.
2. Load https://github.com/Road-hog123/British-Road-Detailing-Pack-2/tree/master/OMSI%202/Fonts
3. Right click on a .oft file and save as.
4. After save click to open in the download panel.
5. In the choose application mac window select a random app and check the "Always use this application to open file links" and press Open.
6. Open about:preferences and notice the new content type "file"

[Actual Result:]

Content type "file" is added with default open action:
"file":{"action":2,"handlers":[{"name":"TextEdit","path":"/System/Applications/TextEdit.app"}]}

[Expected Result:]

Not entirely sure.

[Note:]

This behavior is not something new introduced with the download improvements.

We shouldn't be showing the external protocol handler dialog here. I don't know why we do. Paul, do you have any cycles to investigate?

Looks like the this.launchFile in DownloadIntegration.jsm throws and we fall back to the external protocol service:
https://searchfox.org/mozilla-central/rev/8e1eb5cbd89a2455c34032d921f8de28261d016b/toolkit/components/downloads/DownloadIntegration.jsm#857,859,863

Looks like the bug is that even though this.launchFile throws, macOS will still show the unknown file dialog. Couldn't find a regression range for this one. Perhaps something changed on the macOS side?

The error message is quite generic:

Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.launch]

Probably fails somewhere in here: https://searchfox.org/mozilla-central/rev/8e1eb5cbd89a2455c34032d921f8de28261d016b/xpcom/io/nsLocalFileUnix.cpp#2119

(In reply to Paul Zühlcke [:pbz] from comment #2)

Looks like the this.launchFile in DownloadIntegration.jsm throws and we fall back to the external protocol service:
https://searchfox.org/mozilla-central/rev/8e1eb5cbd89a2455c34032d921f8de28261d016b/toolkit/components/downloads/DownloadIntegration.jsm#857,859,863

Looks like the bug is that even though this.launchFile throws, macOS will still show the unknown file dialog. Couldn't find a regression range for this one. Perhaps something changed on the macOS side?

The error message is quite generic:

Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.launch]

Markus/Stephen, is there any chance macOS gives us more information here that we could use to do something specific (ie by returning a more specific error result) for the case where attempting to launch the file shows the "unknown file type" macOS dialog?

(In reply to Paul Zühlcke [:pbz] from comment #2)

Looks like the this.launchFile in DownloadIntegration.jsm throws and we fall back to the external protocol service:
https://searchfox.org/mozilla-central/rev/8e1eb5cbd89a2455c34032d921f8de28261d016b/toolkit/components/downloads/DownloadIntegration.jsm#857,859,863

This seems to date back to bug 852482. I don't know under what circumstance that would possibly help/work. Marco, can you think of something? Or, long shot, Felipe or Paolo? Did delegating to an external file protocol handler ever do something useful? It seems right now one normally doesn't exist...

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

We shouldn't be showing the external protocol handler dialog here. I don't know why we do. Paul, do you have any cycles to investigate?

I'm not entirely sure I follow: If there is no default for a file type, what is supposed to happen?

(In reply to Stephen A Pohl [:spohl] from comment #6)

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

We shouldn't be showing the external protocol handler dialog here. I don't know why we do. Paul, do you have any cycles to investigate?

I'm not entirely sure I follow: If there is no default for a file type, what is supposed to happen?

Per comment #2 it appears we get the macOS default thing asking you what to do. That seems reasonable?

The issue is with then also trying to treat the file protocol (which Firefox speaks perfectly well itself if the goal is fetching data - it just means getting stuff using local OS-specific (potentially local, potentially network-based) disk access APIs) like some unknown external protocol like spotify or itunes or zoommtg or somesuch. That doesn't really make sense, and selecting a default app to handle those types of URLs also makes very little sense (it is unlikely there is another app that can meaningfully handle an arbitrary file URI differently from how the browser handles it).

Firefox 98 shipping soon, updating flags.

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

(In reply to Paul Zühlcke [:pbz] from comment #2)

Looks like the this.launchFile in DownloadIntegration.jsm throws and we fall back to the external protocol service:
https://searchfox.org/mozilla-central/rev/8e1eb5cbd89a2455c34032d921f8de28261d016b/toolkit/components/downloads/DownloadIntegration.jsm#857,859,863

This seems to date back to bug 852482. I don't know under what circumstance that would possibly help/work. Marco, can you think of something?

I don't know. Based on code archeology and reading the comments in that bug, it looks like this behavior was inherited from the old toolkit download manager component. I think it could be changed to a more sensible option.

Sorry for the delay. I'm not sure I understand the question. I think we're trying to differentiate three cases, is that correct?

• launchFile launches the file because macOS has an existing association and knows how to open the file.
• launchFile launches the file after the user picked an application in the macOS application dialog.
• launchFile does not launch the file because ...? Because the user cancelled the chooser dialog?

And today the second case throws even though the file is launched?

(In reply to Markus Stange [:mstange] from comment #10)

Sorry for the delay. I'm not sure I understand the question. I think we're trying to differentiate three cases, is that correct?

• launchFile launches the file because macOS has an existing association and knows how to open the file.
• launchFile launches the file after the user picked an application in the macOS application dialog.
• launchFile does not launch the file because ...? Because the user cancelled the chooser dialog?

And today the second case throws even though the file is launched?

launchFile launching the file in the second case fails as the user picks an application, ie the dialog comes up but the code returns failure before the dialog is closed, irrespective of user action. This is coming from inside nsIFile::Launch (called at this point), so presumably https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/xpcom/io/nsLocalFileUnix.cpp#2135-2140 returns an error code of sorts.

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

launchFile launching the file in the second case fails as the user picks an application, ie the dialog comes up but the code returns failure before the dialog is closed, irrespective of user action. This is coming from inside nsIFile::Launch (called at this point), so presumably https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/xpcom/io/nsLocalFileUnix.cpp#2135-2140 returns an error code of sorts.

I see, thanks. That uses -[NSWorkspace openURL:] which only has a boolean return type. But it seems there's a more modern API: -[NSWorkspace openURL:configuration:completionHandler:] (and its pre-10.15 but deprecated sibling -[NSWorkspace openURLs:withAppBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifiers:]) which has a ton more options and gives more information about what happened. We could probably switch to it.

What are the cases when we want this method to throw? It looks like Chrome's equivalent does not return any result.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:Gijs, since the bug has high priority and recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

(In reply to Markus Stange [:mstange] from comment #12)

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

launchFile launching the file in the second case fails as the user picks an application, ie the dialog comes up but the code returns failure before the dialog is closed, irrespective of user action. This is coming from inside nsIFile::Launch (called at this point), so presumably https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/xpcom/io/nsLocalFileUnix.cpp#2135-2140 returns an error code of sorts.

I see, thanks. That uses -[NSWorkspace openURL:] which only has a boolean return type. But it seems there's a more modern API: -[NSWorkspace openURL:configuration:completionHandler:] (and its pre-10.15 but deprecated sibling -[NSWorkspace openURLs:withAppBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifiers:]) which has a ton more options and gives more information about what happened. We could probably switch to it.

What are the cases when we want this method to throw? It looks like Chrome's equivalent does not return any result.

Gah, sorry, clearly I missed this. I think it should probably throw if opening failed completely, ie if the OS picker was cancelled by the user? Does the more modern API give any indication this has happened?

(handing off to spohl)