[RFE] Return true when the system provides handler for specific scheme

[xhorak]

We have a support for specific url scheme, like: magnet:, tg:, etc. see: https://en.wikipedia.org/wiki/List_of_URI_schemes in the system. The problem is that the application have no clue if the scheme is supported by the system.

For the Firefox it means that we expect that every scheme is supported by the system (as a workaround) and we use gtk_show_uri to pass that to the system. But imagine URL like localhost:1234, normally under non-flatpak environment the Firefox first ask system if it has handler for the localhost scheme and if not, it proceed to the opening the page as http, but since we declare that system actually has handler for localhost: scheme the page is never opened in the Firefox.

[matthiasclasen]

So the question here is if firefox should try to use the portal for schemes that it otherwise supports by itself?

Or is the question if firefox should never use the portal, even if it does not support the scheme itself?

[xhorak]

So the question here is if firefox should try to use the portal for schemes that it otherwise supports by itself?
It "supports" everything. There's always fallback to the search page, try whatever:something for example.

Or is the question if firefox should never use the portal, even if it does not support the scheme itself?
Not sure if I get the question, but it could be already answered by the previous reply.

[matthiasclasen]

The request is just not very clear to me.

"Ask if localhost:1234 is supported and if not "open as http:" - this does not sound like url handling to me at all - localhost: is really not a protocol that some application could speak,
and the only thing that it has in common with uris is the colon in the middle.

The things that the OpenURI portal is meant to handle are:

• http://www.cnn.com - what everybody thinks of as links
• file:///home/xhorak/resume.pdf - local files, that you would otherwise click on in the file browser

Anything else, like exotic schemes that people like to invent, local socket names, etc, really
don't fit into this very well, and if firefox has an idea how to handle such things, it is probably
better if it just goes ahead and handles them itself.

[xhorak]

The localhost is an extreme example for that but it falls into the same category like other schemes. The non-flatpak Firefox just query system for the handler by g_app_info_get_default_for_uri_scheme and g_app_info_get_all_for_type (if that's not forbidden by preferences) and then it shows the default and other candidates apps which can open the scheme. If the system handler is not found, it tries to open the url itself. I guess that's what users are expecting and expect the same in the flatpak since it works till now.

In flatpak we've tried to be overoptimistic by expecting that all schemes are supported by the flatpak portal, showing the "Use the system handler" (as we do for the file mimetypes) and then we've forwarded the opening of the url to the portal. This basically has been working but obviously not for the unsupported schemes.

So having a portal to which we can send a SystemDoYouHaveAppForThisScheme('scheme') and receive true/false would be really helpful there. Otherwise there won't be a support passing these urls to the system handlers.

[violetmage]

+1

recent firefox flatpak update breaks any "x-scheme-handler" - see https://bugzilla.mozilla.org/show_bug.cgi?id=1688966
knowing if scheme exists makes fixing much simpler

[violetmage]

@matthiasclasen

more simply, @xhorak is wanting xdg-open to fail if the system does not have any handler

[matthiasclasen]

So having a portal to which we can send a SystemDoYouHaveAppForThisScheme('scheme') and receive true/false would be really helpful there. Otherwise there won't be a support passing these urls to the system handlers.

If I was in security, I would say that is an information leak that helps the potential attacker.

Turning things around, for every uri that firefox can support internally, firefox could just tell the mime system that it supports this scheme / mime-type, and then firefox would show up as one of the apps in the app chooser that is presented when you call the OpenURI portal. So if the user wants firefox to handle the url, it can just pick it in the dialog.

There might be some argument for recognizing the case where the app that made the OpenURI call gets picked to handle the uri, and return some 'handle it yourself' value.

[jokeyrhyme]

The information leak / fingerprinting angle here reminds me of this discussion: flatpak/flatpak#4311

[xhorak]

So having a portal to which we can send a SystemDoYouHaveAppForThisScheme('scheme') and receive true/false would be really helpful there. Otherwise there won't be a support passing these urls to the system handlers.

If I was in security, I would say that is an information leak that helps the potential attacker.

Like the app is trying to query as much as possible of the uri scheme handlers to create fingerprint? Possible, but there can be more reliable ways to get that info, thanks @jokeyrhyme for the link.

Turning things around, for every uri that firefox can support internally, firefox could just tell the mime system that it supports this scheme / mime-type, and then firefox would show up as one of the apps in the app chooser that is presented when you call the OpenURI portal. So if the user wants firefox to handle the url, it can just pick it in the dialog.

This is unfortunatelly not possible, if user type something like site:example.com my search term, the OS is queried about site uri handler and since there's no uri handler for site the query is passed to the default search engine. Since there is a lot of these search prefixes (see https://www.gtricks.com/google/prefix-tricks-query-options-search/ for example) and they vary among search engines we can't delegate Firefox as a valid uri handlers for these search prefixes.

There might be some argument for recognizing the case where the app that made the OpenURI call gets picked to handle the uri, and return some 'handle it yourself' value.

• That would led to popup from the browser if user wants to use system application to open that uri
• The portal then reply with 'handle it yourself value, firefox can then try to open the page.
  This seems to be confusing for me.

Also I'm afraid that what the @violetmage suggests, that:

more simply, @xhorak is wanting xdg-open to fail if the system does not have any handler

won't help us there, because for security reasons the Firefox first ask user if he really wants to open the uri in the system application. It does not show the dialog for unsupported uri schemes, it tries to open it or use it as search query. We simply don't want to show the uri dialog for unsupported system uri schemes under flatpak.