1700976 - When passing Firefox a URI from an external program / commandline / the OS that is supposed to be handled by an extension, "Choose application to open the <scheme> link" dialog always prompts

Status: VERIFIED FIXED

(WebExtensions :: Untriaged, defect, P3)

Description

[Roy Wellington]

Attachment: prompt.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.192 Safari/537.36

Steps to reproduce:

I use this extension: https://addons.mozilla.org/en-US/firefox/addon/open-url-in-container/

If I run:

/Applications/Firefox\ Developer\ Edition.app/Contents/MacOS/firefox 'ext+container:name=Work&url=https://example.com'

I get prompted with the dialog seen in "prompt.png": "Choose an application to open the ext+container link."

I select "Open URL in a container" (the extension that handles these) and check "Always use this application to open ext+container links", and hit "Open Link"

If I then go to about:preferences, this shows up under "Applicatons". ext+container is set to "Use Open URL in a container".

If I re-run the command to open one of those links, however:

/Applications/Firefox\ Developer\ Edition.app/Contents/MacOS/firefox 'ext+container:name=Work&url=https://example.com'

I am prompted again.

(This appears to have happened after the most recent update, so I think this issue is new in FF 88.)

Actual results:

I get prompted each and every time I direct Firefox to one of these links.

Expected results:

Since I'm selecting "Always use this application to open ext+container links", I expect that preference to be remembered & obeyed.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I’ve attempted to reproduce the issue on the latest Nightly (89.0a1/20210328213901) and Beta (88.0b4/20210328185936) under Windows 10 x64 and Ubuntu 16.04 LTS, however without success.

To test the add-on, I’ve created a .html document which contains the following line <a href="ext+container:name=MyContainer&url=https://mozilla.org">Mozilla.Org in MyContainer</a> which will use the add-on to open https://mozilla.org in a container called MyContainer.
After loading the .html doc in the browser, I click the link and the prompt appears as expected.
I then select the “Always use this application to open ext+container links” and open the link.
Any subsequent access to the link in the .html will no longer make the prompt appear, as the setting to always open the ext+container links was properly saved.

In about:preferences, under "Applicatons", ext+container is set to "Use Open URL in a container" and it stays that way.

Comment 3

[Shane Caraveo (:mixedpuppy)]

Alex, this is reproducible when starting firefox from the command line, and may be a regression in 88, can you give that a spin?

Comment 4

[Roy Wellington]

Hi Alex,

Like Shane mentions, I think that from the command line matters here, for whatever reason. My actual use case is opening the link via the CLI (essentially; it's actually a helper program I have that does it, but it does so by executing the above command, IIRC).

But yes, if I create a test file like you describe, it only prompts "once". There were actually two prompts; a smaller one for whether the file itself was allowed to use such URLs and then the larger one from my original report. But subsequent uses of the same file didn't prompt again, for either prompt, if I check the relevant checkboxes. If I rename the file, then the first, smaller prompt re-prompts, presumably due to it being saved on a per-file basis. (The prompt says, "Allow this file …?", after all.)

But the way that it works for files does give me a theory about this. The authorization for files, at least, seems to be stored on a per-file basis. I am wondering, then, if the authorization for applications is stored on a per-application basis, and either not getting stored, or the previous authorizations somehow appear to be from a different "app" than before?

Does anyone know where the per-file authorization is stored? (Whatever gets stored if I check the box in the smaller prompt for files?) Since, again, this seems to be on a per-file basis, this doesn't seem to correspond to what is shown in about:preferences under "Applications". (It sort of feels like something that would be under the Privacy & Security tab, but I see nothing relevant there.)

Comment 5

[Shane Caraveo (:mixedpuppy)]

Hi Roy, FWIW I think this is a timing issue. extensions are not started until after a bunch of other browser startup happens. The commandline is probably just happening too early. But you said this worked before, so I'm interested in a regression window. If you're interested in trying to produce one, you can use mozregression to help. https://mozilla.github.io/mozregression/

Comment 6

[Alex Cornestean]

Hello Shane !

I tried my luck at finding the regression but failed due to me not being too familiar with using CLI to launch builds while also using mozregression (which I launch from CLI).

I do not know how to re-launch the build that mozregression downloads and installs with the 'ext+container:name=Work&url=https://example.com' argument so I can reproduce the exact steps.

So sorry I cannot be more helpful regarding this matter.

If you can give me some instructions on how to do this, I will gladly give it another try. Thank you !

Comment 7

[Shane Caraveo (:mixedpuppy)]

Rob was going to look at how to make the cli work for this regression.

Comment 8

[Rob Wu [:robwu]]

A shell script can be used to run the bisection. The feature is documented at https://mozilla.github.io/mozregression/documentation/automatic-bisection.html

Run it:

mozregression -g [good build] -b [bad build] -c './bisect.sh {binary}'`

If your internet is slow and you'd like to run the bisection over and over again, include --persist /tmp/dirwithfxbuilds so that downloaded builds are persisted after mozregression exits.

bisect.sh:

#!/bin/bash
firefoxbin="$1"
# Directory containing the installed extension.
templateprofdir="/tmp/templateprofdir"
tmpprofdir="/tmp/targetprofdir"

# Remove existing profile directory to start with the base template.
rm -rf "$tmpprofdir"
cp -ra "$templateprofdir" "$tmpprofdir"

# Start Firefox once, to run any migration code to rule out side effects
"$firefoxbin" --no-remote -profile "$tmpprofdir"

# Run again to try and verify
"$firefoxbin" --no-remote -profile "$tmpprofdir" 'ext+container:name=Work&url=https://example.com'

Comment 9

[Shane Caraveo (:mixedpuppy)]

note, this happened in 88 (87 is not affected). so using merge dates we want to check:

mozregression -g 2021-02-22 -b 2021-03-22 --persist /tmp/dirwithfxbuilds --profile-persistence reuse -a 'ext+container:name=Work&url=https://example.com'

On the very first run, install the addon, quit, and enter "retry". From there mozregression works fine.

My run resulted in https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d3bbd25f75bfb1feb6daf177ad72c0b24d7fd9e2&tochange=a77ce089e179a14ed31dac23978d38c4b856fbaf

Which points to a very obviously related Bug 1678255.

Comment 10

[:Gijs (he/him)]

Roy: For an immediate local workaround for you, create the pref network.protocol-handler.prompt-from-external as a boolean in about:config and set it to false.

Shane/Rob: in terms of an actual fix, perhaps the code at https://searchfox.org/mozilla-central/rev/62135a96327f42fd1ccf8a04feb62be04b102195/toolkit/mozapps/handling/ContentDispatchChooser.jsm#266 should special-case extension schemes and/or cases where an extension is a handler app (are those just nsIWebHandlerApp with a moz-extension URI or something? This is assuming that the extension URIs would not normally launch something outside of Firefox that then re-sends the same URI to Firefox or something like that (which is what this code is trying to deal with). It would be useful to have a test for this - there is an extant test, uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_external.js , where we could add a case for extensions. Unfortunately I both don't really have time to chase this and don't know enough about extension setup in our tests (and specifically, its URL handling functionality) to know how to do that.

Comment 11

[Shane Caraveo (:mixedpuppy)]

This is assuming that the extension URIs would not normally launch something outside of Firefox that then re-sends the same URI to Firefox

I'd say that it's possible to create a system that does that, if you're using runtime native messaging, but I think that would be an edge case. It is a nsIWebHandlerApp, but the url can point to a website or an extension page.

handler creation: https://searchfox.org/mozilla-central/rev/d9f6cded535d202a9ade4a530e653e659bcb5bbd/toolkit/components/extensions/parent/ext-protocolHandlers.js#40

Our tests are at https://searchfox.org/mozilla-central/source/toolkit/components/extensions/test/mochitest/test_ext_protocolHandlers.html

Comment 13

[:Gijs (he/him)]

Attachment: Bug 1700976 - do not prompt for externally-opened web- or extension-handled 'external' protocols, r?zombie

Comment 14

[Rob Wu [:robwu]]

Thanks for picking this up!

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d07d11e4795d
do not prompt for externally-opened web- or extension-handled 'external' protocols, r=zombie

Comment 16

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/d07d11e4795d

Comment 17

[Alex Cornestean]

Hello,

Verified the fix on the latest Nightly (90.0a1/20210524215832) under Windows 10 x64.

Using https://addons.mozilla.org/en-US/firefox/addon/open-url-in-container/ and launching Firefox from CLI with the corresponding arguments will not display the prompt, confirming the fix.