gecko-dev/uriloader
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
..
base Bug 1686616 - make StringBundle use Components instead of Services. r=kmag 2021-02-18 13:26:32 +00:00
docs
exthandler 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
prefetch Bug 1686616 - make PermissionManager use Components instead of Services. r=kmag 2021-02-18 13:26:31 +00:00
preload Bug 1519636 - Reformat recent changes to the Google coding style r=andi,necko-reviewers 2021-02-15 08:49:20 +00:00
moz.build Bug 1654103: Standardize on Black for Python code in mozilla-central. 2020-10-26 18:34:53 +00:00