1732132 - "Always use this application to open" checkbox is not being honored for non-web links passed to Firefox by Lotus Notes

Status: ASSIGNED

(Firefox :: File Handling, defect, P3)

Description

[Chris Heath]

Attachment: firefox-always-use-this-bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

click link with custom protocol

Actual results:

firefox prompts to choose the application to open with but the checkbox to always use that app is not honored and every time a link with that custom protocol is clicked the prompt to choose the application is presented again and again

Expected results:

should only prompt the first time

Comment 1

[:Gijs (he/him)]

Thanks for filing this. I have some follow-up questions.

To clarify, you're clicking a link on a webpage in Firefox? And that link directly points to an ah:... URL (not a redirect or something that opens another app?), which on your system (using Windows 10 - are you also seeing this on other machines and/or other OSes?) is handled by AppHandler, and you've ticked the "always use this application to open ah links", but Firefox always prompts?

Do you have a testcase example we can access? If not, is it possible the link is in a sandboxed iframe or similar? Can you attach the handlers.json file of the profile where this happens (or extract the ah-relevant bit and post it in a comment)?

Comment 2

[Chris Heath]

Usually it is from our email application (which has Firefox set as it's default browser), but the same thing happens if it is a link on a webpage within Firefox already.
We only have Windows 10 here.
The checkbox for "always use this application" used to work until recently and now it always prompts.
If we change the system default browser (or the email default browser) to another browser there is a similar prompt, but the checkbox to remember only happens the first time.
I will attach the handlers.json file (looks correct to me).
The link is not in a sandboxed iframe or similar.
I do not think that I can provide a test case as the apphandler.exe file is hosted internally and will load/install various apps to handle the various links from internal network locations.
While responding though I did just get that idea to test with a new Firefox profile... I will report back.

Comment 3

[Chris Heath]

Attachment: handlers.json

Comment 4

[Chris Heath]

So a fresh profile does not produce the issue...
where should I troubleshoot next?

Comment 5

[:Gijs (he/him)]

Apologies for the delay here; I was away for a while and I've been swamped catching up with everything. Hopefully things should move more quickly now.

(In reply to Chris Heath from comment #2)

I will attach the handlers.json file (looks correct to me).

The handlers.json file has ask: true for the ah protocol. I think this is why we're asking for confirmation.

If you remove that property from the JSON file, while Firefox is not running, does it start working?

(Of course, even if it does, we'll need to figure out why we're not storing that information if you tick the checkbox in the dialog, but let's confirm that's the issue first.)

Comment 6

[Chris Heath]

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

If you remove that property from the JSON file, while Firefox is not running, does it start working?

Made the change, but no difference.
"ah":{"action":4} is what's currently in there... I think the ask set to true was done when I was messing around in the settings trying to get the setting to take...
So apparently that handlers.json setting is not being honored... any other ideas?

Comment 7

[:Gijs (he/him)]

(In reply to Chris Heath from comment #2)

Usually it is from our email application (which has Firefox set as it's default browser), but the same thing happens if it is a link on a webpage within Firefox already.

Actually, re-reading, I'm sorry but I'm confused - per Windows, what is the default handler for the ah protocol? That is, Firefox is set up to send you to the system default handler, and in the dialog it would appear that "AppHandler" is the default. But you also write that your e-mail app also sends these links to Firefox - can you clarify that part?

I would expect that if the email client sends ah links to Firefox directly, we will always prompt, irrespective of what is configured. This is to avoid infinite loops where Firefox automatically invokes some other program, and the external program passes the same link back to Firefox, etc. etc. (bug 1496380, bug 1678255, etc.).

If the email client sends http or https links that redirect to ah links, things should work (on Firefox 92 and later, after bug 1717314).

(In reply to Chris Heath from comment #4)

So a fresh profile does not produce the issue...
where should I troubleshoot next?

In addition to the other questions above I've just been made aware of a similar bug - bug 1727984. Does your main profile where things break have a setup where it clears cookies or other data on shutdown, perhaps? I'm still not sure how that would be related, but I guess it's something to check...

The other thing you could do is attach the about:support data from the profile where this is broken, and we can try and see if there's something obvious in there...

Comment 8

[:Gijs (he/him)]

(Actually, it appears the issue in 1727984 might be that per-site permissions are getting lost, whereas AFAICT the issue here is not about the per-site permission, but about what app to use (the dialog shown in the screenshot in comment 0))

Comment 9

[Chris Heath]

1. to clarify the email situation
   we use Lotus Notes
   it has a setting for the default browser that it will pass all web links to
   (and that is set to firefox)
   the links are not redirections... they are direct links to ah://whatever

2. i do not have any clearing of cookies or other data enabled

3. you are correct that this is not a per-site permission issue

4. about:support file attached

Comment 10

[Chris Heath]

Attachment: ffx-about-support.txt

Comment 11

[:Gijs (he/him)]

(In reply to Chris Heath from comment #9)

1. to clarify the email situation
   we use Lotus Notes
   it has a setting for the default browser that it will pass all web links to
   (and that is set to firefox)
   the links are not redirections... they are direct links to ah://whatever

OK, so this (opening directly from Lotus Notes) will always show the dialog, as a result of bug 1678255, to avoid infinite loops (cf description of that bug, bug 1678249, bug 1667468, etc. etc. - unfortunately this was a real issue, see also its ancient friends bug 215554 and bug 167320 which are for file opening rather than link opening). You can work around by opening about:config, and creating a boolean pref network.protocol-handler.prompt-from-external and setting it to false.

This doesn't explain the webpage case, but I would be interested to know if, after setting that pref and if necessary ticking the "always do this" box one more time before accepting the dialog, the issue continues reproducing for web pages linking to these ah URLs.

Alternatively, does Lotus Notes not have the ability to look up the OS default handler for a given protocol and/or pass the link to the OS so that it can pick the default app, the way other applications do? If so that's... unfortunate.

1. about:support file attached

Thanks, I don't see anything in there that could explain this off-hand. Hopefully my other explanation ends up working out for you.

Comment 12

[Chris Heath]

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

You can work around by opening about:config, and creating a boolean pref network.protocol-handler.prompt-from-external and setting it to false.
That worked!
both for opening link in a webpage and for opening from email
Thanks!

Comment 13

[:Gijs (he/him)]

OK, thanks for confirming that was the issue, Chris, that's helpful.

Paul, Nika, care to give a second opinion on what we should do here? Some options I could see:

1. do nothing (ie "wontfix"/worksforme this bug, and consider the about:config pref sufficient workaround)
2. expose an enterprise policy item for the pref
3. add the "recent URLs passed" cache thingy back into the external protocol handler, so we avoid infinite loops but allow other external URLs.
4. some other option. :-)

Thoughts?

Comment 14

[Nika Layzell [:nika] (ni? for response)]

Love this situation where whatever fix we do breaks someone's workflow :-/

I suppose we could look into re-adding the recently-externally-routed URI cache to automatically detect this case, but I don't love it. Not sure of a better option though.

Comment 15

[Mike Kaply [:mkaply]]

Do we know what other browsers do in this situation?

And that pref is already settable via policy.

Comment 16

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #15)

Do we know what other browsers do in this situation?

I don't, off-hand, and I can't easily do some testing because until next week I only have access to macOS, and if I do the following:

1. open Chrome
   2 on the commandline, run: open -a /Applications/Google\ Chrome.app/ 'mailto:[e-mail]'

then in response it closes the open window that the browser already had, and does nothing else. (!?)
I suggest that whatever we do, we don't do that!

I expect that on macOS the "right" way of passing a URL will involve apple events or w/e and I don't know how to set that up easily. On Windows and Linux I'd expect just commandline invocations to work for checking how other browsers behave, and that combined with associating them as the default handler for the protocol to simulate the problem that bug 1678255 and bug 1496380 were designed to address, might help. I don't know if other browsers mitigate those at all, and if so, how or whether they've then run into a similar bug to this one.

Comment 17

[Paul Zühlcke [:pbz]]

I agree with Nika here, adding the cache back, seems best. I don't like that users who use the pref opt-in to the infinite loop risk.
What's the downside of using this cache? Does it come with overhead or lead to inconsistent / confusing behavior?

I've tried to build a mail handler loop with Chromium on Ubuntu. I've set Chromium as the default e-mail app, but no web handler for e-mail in Chromium itself. Running chromium-browser "mailto:[e-mail]" in the command line opens a new Chromium window with just the newtab page.
Same behavior for Google Chrome on Windows 10.

Comment 18

[Marco Castelluccio [:marco]]

Set release status flags based on info from the regressing bug 1678255

Comment 19

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

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 20

[:Gijs (he/him)]

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

I agree with Nika here, adding the cache back, seems best. I don't like that users who use the pref opt-in to the infinite loop risk.
What's the downside of using this cache? Does it come with overhead or lead to inconsistent / confusing behavior?

I think the main thing is added complexity that we didn't think had much purpose. In terms of consistency, the initial implementation had a 10s timeout, which could potentially be confusing if you clicked the same link twice within that time limit, the first one would open and the second one would prompt... but that still seems better than the alternative?

I've tried to build a mail handler loop with Chromium on Ubuntu. I've set Chromium as the default e-mail app, but no web handler for e-mail in Chromium itself. Running chromium-browser "mailto:[e-mail]" in the command line opens a new Chromium window with just the newtab page.
Same behavior for Google Chrome on Windows 10.

Weeeeird. Does it work normally if you pass "normal" http/https links?

Comment 21

[Paul Zühlcke [:pbz]]

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

I've tried to build a mail handler loop with Chromium on Ubuntu. I've set Chromium as the default e-mail app, but no web handler for e-mail in Chromium itself. Running chromium-browser "mailto:[e-mail]" in the command line opens a new Chromium window with just the newtab page.
Same behavior for Google Chrome on Windows 10.

Weeeeird. Does it work normally if you pass "normal" http/https links?

Yes. The problem might be that I don't have the extended loop here. I'd need another application to be my default mailto handler and have that call Chrome directly.

Comment 22

[Bhim Wheeler]

Attachment: same problem

Thanks from napinporthcal1979.