I cannot repeat that. How to do it?
I tried association on Windows 7 and Windows 10 when Gmail is associated to mailto into Firefox and all works fine.

additional info how to associate https://bugzilla.mozilla.org/show_bug.cgi?id=675428#c32

Why was the patchset backed out over this? It seems to me like there's a pretty simple fix for this loop: if Firefox is opened externally with a mailto: link (as it would be when shelling out to the system), and it's set to use the system default mailto: handler, then you can be pretty sure that something like this is happening (I can't think of any practical scenario where Firefox would be called as a URL handler to open a different program), and open the app-chooser dialog for "Always ask" instead.

And if it's such a big deal that Firefox should be able to open mailto: links externally and then hand them off to another app, for some reason (eg. scripting), you can add a config flag that says "yes, I actually want Firefox to open another program when invoked as a URL handler".

And even then, you could still put this test in as an infinite-loop blocker, so that Firefox checks before opening the system default for an external invocation to fail with an error if it is also that default handler (which, to be clear, could happen with any other protocol a user could set Firefox to open, like irc: when they meant to ).

(The last sentence in parentheses there is incomplete: it was going to end with IRC web clients the user might have associated Firefox as the default IRC client with an intent to open. I was going to say "Mibbit", but then I realized that would probably be telling how long it's been since I actually interacted IRC myself.)

(In reply to Stuart P. Bentley from comment #21)

Why was the patchset backed out over this?

Because making this problem worse was not acceptable.

It seems to me like there's a pretty simple fix for this loop: if Firefox is opened externally with a mailto: link (as it would be when shelling out to the system), and it's set to use the system default mailto: handler, then you can be pretty sure that something like this is happening (I can't think of any practical scenario where Firefox would be called as a URL handler to open a different program), and open the app-chooser dialog for "Always ask" instead.

This is a "why don't you just" comment. Please don't do that. If you think this is easy to fix, we'd welcome patches on bug 167320. From what I recall, there is no trivial way to know that we're the default mailto handler, and the non-trivial way (ie asking whatever OS we're on) may be janky. The problem is also wider than just mailto: and may need different solutions for files vs. protocols, and checking if "it" is set as the default handler is also not trivial if there are multiple copies of Firefox installed, or some other forwarding solution (firefox->firefox-bin, or other scripts or generic handler apps, esp. on Linux ("default-xxxx-handler/client") and Windows (shell32 etc.)) is in use. That's not to say it's not possible to fix it - far from it - but it's not trivial, and apparently, so far, nobody has had both the time and expertise to do so.

Noting the workaround is:

• Enter about:preferences into the address bar.
• Check the action defined for mailto.
• If it's blank, set it to the mail handler you want to use.

(In reply to Liz Henry (:lizzard) from comment #26)

Noting the workaround is:

• Enter about:preferences into the address bar.
• Check the action defined for mailto.
• If it's blank, set it to the mail handler you want to use.

FWIW there is almost zero chance that a user would find this workaround. See bug 675428 comment 34 for why this is still a problem for users. :-(

I know, it's a long shot, I'm just not sure how to help move this along to fix the issue. I can see from the steadily incoming duplicates it's a problem.

Do you think a release note (as a known issue) would propagate a bit further, linking to a SUMO article? I can also try to escalate among engineering managers.

I'm going to pass this issue on to the 71 release owner for now though because I have to focus on what's possible for 70 release right now.

I have some ideas here from having looked at some of the app handling code - it intersects with bug 1586148 anyway. Still unlikely I can get you a patch for 70 though...

(In reply to Liz Henry (:lizzard) from comment #29)

I know, it's a long shot, I'm just not sure how to help move this along to fix the issue. I can see from the steadily incoming duplicates it's a problem.

Do you think a release note (as a known issue) would propagate a bit further, linking to a SUMO article? I can also try to escalate among engineering managers.

Just to clarify further what's happened here, this bug only affects users on pre-release channels who have installed a Firefox Nightly/Beta/DevEdition build while bug 675428 was in the tree. That patch was eventually backed out but its effects in the Windows registry would be persisted if the Firefox installer had executed when that patch was in the tree... It shouldn't affect any users on the release channel. I can't imagine the number of affected users to be super high.

It's hard for me to imagine how effective a release note or a SUMO article would be unless it comes up high in a Google search result for the problem symptoms, which is a bit hard to imagine. In bug 675428 we're discussing doing more work to remove the remnants of what the installer may have left in the Windows registry as a mitigation for this...

This is an initial implementation of this idea that works on mac. Assuming
this looks OK, I'll add windows and unix implementations of
IsCurrentAppOSDefaultForProtocol - I do not think we need them in the child
process implementation or on Android.

Effectively, this makes nsIHandlerInfo::LaunchWithURI() fall back to asking if
the handler info points to the OS default and that's us, or if it points to
a helper app and that's us. The latter is fairly easy to check, but the former,
more common case, is actually annoying - there don't seem to be APIs on the
external helper app service or the handler service that provide any information
about the app that's currently the default. So despite my belief that these
interfaces have too many methods that all do very similar things, and what we
need is fewer interfaces with fewer methods, I added another one...

On the upside, if we implement this, I believe we can simplify some of our
shell service implementations to delegate to this method, ie by passing
http/https as the scheme argument for "is the default this app" - and indeed,
I will be borrowing the unix/windows implementations from there if the
approach looks OK.

For this mac implementation, I'm comparing bundle identifiers but I've kept
the external protocol service's extant way of asking for a scheme/protocol's
default bundle. It's subtly different from the mac shell service, and both
use a deprecated function (LSGetApplicationForURL), which we could fix while
we're here if we care (though apparently we still support 10.9 so we'll need
to runtime-check in a way that satisfies the compiler warnings, or something).

Another way of fixing these issues would be to complain about things when we
receive these URIs from external parties and our own config says that we will
just hand them to someone else. I decided not to do so because we end up with
at least one of the following problems:

• if we implement in BrowserContentHandler, that won't help for
  PWAs/Thunderbird
• if we try to implement in the external protocol handler, we'd need to start
  passing load flag information through to lots of checks.
• it wouldn't stop the recursion until we've already done one round of
  it for links that are in webpages, which seems suboptimal (ie, if you
  clicked a mailto: link on a webpage it'd go to the OS with that mailto link
  and only realize something's awry when we've gone back through the OS to us,
  rather than straightaway).

If we wanted to, we could add a fix like that in belt-and-suspenders fashion.

Why was this marked as blocking 71? Nothing has changed for the 71 release, and the patch here is tricky (ie I'm not sure whether the approach is something Dave agrees with) and still needs windows and linux work. It's unlikely it can be done in 4 days and there's no real reason to rush it, and even if we take this patch I wouldn't want to uplift it.

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Sorry, this is a misclick (I probably mouse scrolled the page with the select box still having the focus) I actually meant to untrack it! thanks for catching

Depends on D48742

This is still happening in 71.0b6 (64-bit) on Windows 10.

Depends on D50917

We have shipped our last beta for 71 and this is a P3, so this is wontfix for 71.

https://hg.mozilla.org/mozilla-central/rev/f0094c9184c4
https://hg.mozilla.org/mozilla-central/rev/59c515d9559e
https://hg.mozilla.org/mozilla-central/rev/77b8a1ea2cc8

It should be fixed in Firefox 68 ESR too, many users affected in our company (and I suppose in many others) :-(

(In reply to Dimas from comment #46)

It should be fixed in Firefox 68 ESR too, many users affected in our company (and I suppose in many others) :-(

How do they get into this state? By default on 68 esr, we shouldn't be registering with Windows as a mailto handler when installed, AIUI. Is this something your company does as part of configuration or something?

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

(In reply to Dimas from comment #46)

It should be fixed in Firefox 68 ESR too, many users affected in our company (and I suppose in many others) :-(

How do they get into this state? By default on 68 esr, we shouldn't be registering with Windows as a mailto handler when installed, AIUI. Is this something your company does as part of configuration or something?

Recently we migrated from 52 ESR to 68 ESR and from then on I hadn't tested it again, and now I can't reproduce it. Is the first time that we uninstall previous version before install the new one, so maybe is because of that, I don't know. I thought we'd be dragging the problem along, and it looks like it's solved. In any case, sorry about that, I'm glad the bug is solved.

Verified with 72.0b12, no more endless loops.