1496380 - Firefox opens multiple tabs if set as default mail client

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P3)

Description

[Cristian Fogel [:cfogel]]

Attachment: mailTO_spamTabs.gif

[Affected versions]:
-63.0b11 DevED(also affected), 64.0a1, 49.0.2

[Affected platforms]:
- win 10x64, macOS 10.9, Ubuntu 16.04LTS

[Steps to reproduce]:
1. set the Firefox browser as default client for mail;
2. trigger any mail-to action;
ex: 
    - click on any triangle near any user_name;
    - click on the MAIL option
3. accept any confirmation message if displayed;

[Expected result]:
- the Firefox browser is open with the mail_to action 

[Actual result]:
- a new tab is open until the browser is stopped;

[Regression range]:
- managed to reproduce with 49.0.2;
- if needed can go further with checking if/for regression;

[Additional notes]:
- attached screen recording with the issue

Comment 1

[Hal Wine [:hwine] use NI!]

When bug 675428 ships, many more users will be able to configure Firefox to handle email, so the impact of this bug will be much greater. (That said, I do not experience this problem when Firefox handles gmail on win10, Fx Nightly.)

Comment 2

[Cristian Fogel [:cfogel]]

You could try setting Firefox as the default browser as well; reproduced on 3 different Win10s before posting this bug.

Comment 3

[:Gijs (he/him)]

This was a well-known and very old issue. I don't understand why we fixed bug 675428 without addressing it. See bug 167320 and its gazillion dupes.

(In reply to Hal Wine [:hwine] (use NI) from comment #1)
> When bug 675428 ships, many more users will be able to configure Firefox to
> handle email, so the impact of this bug will be much greater. (That said, I
> do not experience this problem when Firefox handles gmail on win10, Fx
> Nightly.)

What if it's set to "use system default"?

Comment 4

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #3)
> What if it's set to "use system default"?

And, to be clear, I think this is the default setting...

If we're shipping this as the default configuration in 63 we need to fix this for 63, or back out bug 675428.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

Bug 675428 was backed out from beta so no need to track for 63 anymore.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

From bug 675428 it looks like this is a wontfix for 62, let's call it "disabled" for 63 from the backout.  It isn't clear to me if 64 is or isn't affected at this point since the work was backed out from 64 but then re-landed.

Comment 7

[Cristian Fogel [:cfogel]]

Can reproduce the issue using the steps in c0 on 64.0a1 (2018-10-15) as well.

Comment 8

[Hal Wine [:hwine] use NI!]

(In reply to :Gijs (he/him) from comment #4)
> (In reply to :Gijs (he/him) from comment #3)
> > What if it's set to "use system default"?
> 
> And, to be clear, I think this is the default setting...
> 
> If we're shipping this as the default configuration in 63 we need to fix
> this for 63, or back out bug 675428.

We have a lot of confusion here. This bug is NOT related to bug 675428.
 - This bug is reported on multiple platforms, bug 675428 is windows only. (Check the diff)
 - Bug 675428 does not impact any handling of mailto links _within_ Firefox -- it only enables a user to configure Firefox to handle mailto links from _other_ applications (like a mailto link in MS Word or Slack application).


Note: you may need to customize these SUMO articles for windows, if you aren't viewing from a windows browser.
[1]: https://support.mozilla.org/en-US/kb/change-program-used-open-email-links#w_using-webmail-services
[2]: https://support.mozilla.org/en-US/kb/change-program-used-open-email-links#w_setting-your-operating-systems-default-mail-program

Comment 9

[:Gijs (he/him)]

(In reply to Hal Wine [:hwine] (use NI) from comment #8)
> (In reply to :Gijs (he/him) from comment #4)
> > (In reply to :Gijs (he/him) from comment #3)
> > > What if it's set to "use system default"?
> > 
> > And, to be clear, I think this is the default setting...
> > 
> > If we're shipping this as the default configuration in 63 we need to fix
> > this for 63, or back out bug 675428.
> 
> We have a lot of confusion here. This bug is NOT related to bug 675428.
>  - This bug is reported on multiple platforms, bug 675428 is windows only.
> (Check the diff)

Sure, but bug 675428 makes this bug more likely to happen on Windows, and Windows is by far the most commonly used OS in our userbase.

One point of clarification that I would like to see, because the summary of bug 675428 is confusing: does that patch make Firefox register as a *possible* mailto handler with Windows, or does it actually change the *default* mail handler when installed? What about when Firefox prompts the user to set it as the default browser, at that point, do we also become the default mailto handler (maybe pre-win10, given how win10 restricts default takeovers from apps) ? (Ni for this)

>  - Bug 675428 does not impact any handling of mailto links _within_ Firefox
> -- it only enables a user to configure Firefox to handle mailto links from
> _other_ applications (like a mailto link in MS Word or Slack application).

But the default for mail handling *inside* Firefox is "delegate to the OS' default mail handler".

If that default is kept, *and* either we or the user configures the OS to use Firefox as their mail handler, we end up with this infinite loop.

I just checked, and I can trivially reproduce on macOS:

1. open nightly, create a new profile
2. verify that in its prefs, if you filter for 'appl', the entry for 'mailto' lists your mac's default mail app (probably Mail.app or Thunderbird.app or something)
3. open mail.app, open its preferences, change the default mail app and point to nightly.
4. close mail.app,
5. close Firefox's prefs
6. reopen Firefox's prefs, filter for 'appl' again
7. notice that the "Mail" row now says "Firefox Nightly (default)"
8. open data:text/html,<a href="mailto:[e-mail]">Click
9. click link.

If bug 675428 puts us in a place where step 3 is either much easier for users, or even accomplished by default by our Windows installer, then I think that means we need to fix this bug prior to shipping 675428.

Does that make sense?

Comment 10

[Hal Wine [:hwine] use NI!]

(In reply to :Gijs (he/him) from comment #9)
> Sure, but bug 675428 makes this bug more likely to happen on Windows, and
> Windows is by far the most commonly used OS in our userbase.

Completely agreed - and I'll defer to any estimates you have of how many of those would perform the steps necessary to get in a bad place. (I'd been assuming very few, but don't have experience or data to back that assumption.)

> One point of clarification that I would like to see, because the summary of
> bug 675428 is confusing: does that patch make Firefox register as a
> *possible* mailto handler with Windows, or does it actually change the
> *default* mail handler when installed? 

The former -- Firefox only becomes a possible choice for the user to select. Currently, Firefox is not a choice. (I tweaked that summary to clarify.)

> What about when Firefox prompts the
> user to set it as the default browser, at that point, do we also become the
> default mailto handler (maybe pre-win10, given how win10 restricts default
> takeovers from apps) ? (Ni for this)

I do not have access to pre-win10 images to test this. Transfering ni to :cfogel

> 
> >  - Bug 675428 does not impact any handling of mailto links _within_ Firefox
> > -- it only enables a user to configure Firefox to handle mailto links from
> > _other_ applications (like a mailto link in MS Word or Slack application).
> 
> But the default for mail handling *inside* Firefox is "delegate to the OS'
> default mail handler".
> 
> If that default is kept, *and* either we or the user configures the OS to
> use Firefox as their mail handler, we end up with this infinite loop.
> 
> I just checked, and I can trivially reproduce on macOS:

Yes, this foot gun is shipped

> 1. open nightly, create a new profile
> 2. verify that in its prefs, if you filter for 'appl', the entry for
> 'mailto' lists your mac's default mail app (probably Mail.app or
> Thunderbird.app or something)
> 3. open mail.app, open its preferences, change the default mail app and
> point to nightly.
> 4. close mail.app,
> 5. close Firefox's prefs
> 6. reopen Firefox's prefs, filter for 'appl' again
> 7. notice that the "Mail" row now says "Firefox Nightly (default)"
> 8. open data:text/html,<a href="mailto:[e-mail]">Click
> 9. click link.
> 
> If bug 675428 puts us in a place where step 3 is either much easier for
> users, or even accomplished by default by our Windows installer, then I
> think that means we need to fix this bug prior to shipping 675428.
> 
> Does that make sense?

Completely makes sense! And I'll defer to your impact estimates. My interest was in ensuring the linkage between the bugs was understood as being as nuanced as described.

I will note that, without bug 675428, there is no documented or supported path for windows users to utilize gmail via Firefox as their default OS email client. They can use the other non-gecko browsers simply (see bug 675428 comment 7). SUMO won't accept the regedit manual process (too technical), and there aren't any good blog posts that search engines find.

ni: :cfogel to do the "impact on pre-win10" question :gijs asked above.

Comment 11

[Cristian Fogel [:cfogel]]

From what I saw, on both Win7 and Win8.1 Firefox is set as the mailto option after the default browser prompt.
And yes, the issue reproduces as well on them.

Comment 12

[:Paolo Amadini]

Thank you for clarifying the situation, I've commented on bug 675428. Given the release time frame and soft freeze, the only likely option is a backout of the other bug from mozilla-central. Assuming this will be carried out soon, I'm setting this bug as P3 for the purpose of triage. This would otherwise be a P1 and would need to have been already fixed.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.

Comment 14

[[:philipp]]

bug 675428 got backed out from 64 release last minute - what's the story here for 65 and beyond? should we back out the possibility to add firefox as a mail-handler in windows settings as well or will the bug here get a higher priority (so that we don't end up in the same situation shortly before the next release date)?

Comment 15

[:Paolo Amadini]

Since I have seen no recent activity here, and there are more dependencies than just this bug and UX decisions to be made if we want to get the feature prototyped in bug 675428 shipped, we should back out the patch from all channels. Thanks for keeping an eye on the status of these bugs.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Bumping the priority as it was a severe issue.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Given that the regressing bug was backed out from all affected channels, I don't think we need to track this anymore.

Comment 20

[Elle Solomina]

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

Comment 21

[Stuart P. Bentley]

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 ).

Comment 22

[Stuart P. Bentley]

(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.)

Comment 23

[:Gijs (he/him)]

(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.

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 27

[(no longer active)]

(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. :-(

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 31

[:Gijs (he/him)]

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...

Comment 32

[(no longer active)]

(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...

Comment 33

[:Gijs (he/him)]

Attachment: Bug 1496380 - stop recursion via the external protocol handler if Firefox is either the default OS handler or a configured external handler, r?Mossop

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.

Comment 34

[:Gijs (he/him)]

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.

Comment 35

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

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

Comment 36

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 37

[:Gijs (he/him)]

Attachment: Bug 1496380 - include LSCopyDefaultApplicationURLForURL in recordreplay darwin process redirect, r?bhackett

Depends on D48742

Comment 38

[david.beers]

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

Comment 41

[:Gijs (he/him)]

Attachment: Bug 1496380 - implement IsCurrentAppOSDefaultForProtocol on Windows, r?emk

Depends on D50917

Comment 42

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0094c9184c4
stop recursion via the external protocol handler if Firefox is either the default OS handler or a configured external handler, r=mossop
https://hg.mozilla.org/integration/autoland/rev/59c515d9559e
include LSCopyDefaultApplicationURLForURL in recordreplay darwin process redirect, r=bhackett
https://hg.mozilla.org/integration/autoland/rev/77b8a1ea2cc8
implement IsCurrentAppOSDefaultForProtocol on Windows, r=emk

Comment 44

[Oana Pop-Rus]

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

Comment 46

[Dimas]

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

Comment 47

[:Gijs (he/him)]

(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?

Comment 48

[Dimas]

(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.

Comment 49

[Cristian Fogel [:cfogel]]

Verified with 72.0b12, no more endless loops.