fune/toolkit/mozapps/handling
Gijs Kruitbosch 8002a3c48c Bug 1678255 - prompt for external protocol links whose loads were also triggered externally, instead of looping forever, r=pbz,nika
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.

In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).

So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.

Differential Revision: https://phabricator.services.mozilla.com/D103967
2021-02-22 19:00:10 +00:00
..
content Bug 1689480 - Changes to the appchooser/permission dialog checkboxes to accomodate for the added margin-block r=pbz 2021-02-12 17:05:28 +00:00
components.conf
ContentDispatchChooser.jsm Bug 1678255 - prompt for external protocol links whose loads were also triggered externally, instead of looping forever, r=pbz,nika 2021-02-22 19:00:10 +00:00
jar.mn Bug 1565574 - Added protocol handler permission dialog and updated app chooser dialog. r=Gijs,fluent-reviewers 2020-10-29 13:43:54 +00:00
moz.build Bug 1654103: Standardize on Black for Python code in mozilla-central. 2020-10-26 18:34:53 +00:00