675428 - register firefox as default OS mail client on Windows

Status: RESOLVED FIXED

(Firefox :: File Handling, enhancement, P3)

Description

[Ivan Ičin]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110721152715

Steps to reproduce:

I wanted to register Firefox as default mail client (it can handle mailto: links from websites, so the same way it could handle system calls).



Expected results:

Firefox should be able to handle system mailto calls.

Comment 1

[Ivan Ičin]

If I wasn't precise enough: it should be able to handle system mailto calls by opening webmail that is registered within Firefox as mailto handler.

Comment 2

[Asa Dotzler [:asa]]

This is a fine idea. When a user clicks a mailto link in an IM client or some other non-browser context, it would be nice to have Firefox handle this with a webmail service.

Comment 3

[Ivan Ičin]

(In reply to comment #2)
> This is a fine idea. When a user clicks a mailto link in an IM client or
> some other non-browser context, it would be nice to have Firefox handle this
> with a webmail service.
Not precise enough... I mean if you click link in Internet explorer it would open Firefox, and Internet explorer still counts as browser, right? ;))

Comment 6

[anoopsinghrathaur2]

feature requested 6 year ago and till now mailto is not showing firefox default client.

Comment 7

[Hal Wine [:hwine] use NI!]

Still an issue with Windows 10 :(

The workaround requires user to edit the registry:
  You have to say to Windows 10 that Firefox can handle "mailto" protocol :

  "Win + R", lauch "regedit" and go to "HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE\Capabilities\URLAssociations". Then add a string value named "mailto" with "FirefoxURL" as value.

  Reboot your computer, it's works
(from https://answers.microsoft.com/en-us/windows/forum/windows_10-other_settings-winpc/how-to-set-firefox-gmail-as-windows-default/296816f4-e2d7-48dd-ae71-84d18a02dc18)

Which is not a good UX.

Firefox 60 ships with support for 3 protocols registered with Windows (the hack above adds a fourth):
  ftp, http, https

Chrome 67 ships with "support" for 13 protocols registered with Windows. I quote support, as Chrome (just like Firefox) requires additional configuration within the browser to handle a "mailto" url by opening the appropriate web mail URL.

Given the prevalence of web mail, it's a shame we require folks to run regedit.

Comment 8

[Hal Wine [:hwine] use NI!]

Attachment: Bug 675428 - register Firefox to handle mailto URLs in Windows

At least in Win10, Firefox is not an option to configure as a mailto handler.

Comment 9

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8993454 [details]
Bug 675428 - register Firefox to handle mailto URLs in Windows

Matt Howell [:mhowell] has approved the revision.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39f0d4e66898
register Firefox to handle mailto URLs in Windows r=mhowell

Comment 11

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/39f0d4e66898

Comment 12

[Cristian Fogel [:cfogel]]

Attachment: mailTO_spamTabs.gif

While trying to verify the fix, I've noticed another issue in this area; see attachment.

Multiple tabs opened after trying to open the mail client (checked only on win10x64 _64.0a1 (2018-10-02) for now).

Comment 13

[Cristian Fogel [:cfogel]]

*Should I open a new bug for it or is it something that needs to /can be fixed here?

Comment 14

[Hal Wine [:hwine] use NI!]

(In reply to Cristi Fogel [:cfogel] from comment #13)
> *Should I open a new bug for it or is it something that needs to /can be
> fixed here?

Please open another bug - it sounds like a Firefox issue. (This was a windows installer issue.) Thanks!

Comment 15

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

RC week is next week, we have our last beta built on Thursday, given that this was not a planned feature for 63, I would prefer that this feature gets backed out for the 63 release and lands again later for 64. 

Hal, can this patch be backed out for 63 or do you feel that the fix for bug 1496380 is a trivial one that could be part of our last beta this week?

Comment 16

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/20773596530b
Backed out changeset 39f0d4e66898 for causing Bug 1496380 a=backout

Comment 17

[Andreea Pavel [:apavel]]

Backed out from central/beta for causing bug  1496380

Backout:  https://hg.mozilla.org/mozilla-central/rev/20773596530b6b6a6fb405a7bd7110a990f8db8f

https://hg.mozilla.org/releases/mozilla-beta/rev/6eb227fec6d5a3ca1a21f8fd57292b7855a975f4

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/725a692947dd
register Firefox to handle mailto URLs in Windows r=mhowell a=reland

Comment 19

[Hal Wine [:hwine] use NI!]

sorry - forgot to set the PTO info on bz

It's waited for 7 years - one more release won't kill anyone. Or it, and the bug 1496380 may just be "won't fix"

Comment 20

[:Paolo Amadini]

I don't know why this re-landed in comment 18 since there's no explanation on this bug and I also see no activity on bug 1496380 at the same time, but based on the recent discussion there, this needs to be backed out from 64 and cannot land on any release until bug 1496380 and related matters are sorted out.

In particular, the default for Firefox is to defer to the operating system for e-mail handling. Not only Firefox shouldn't be set as the default e-mail handler when set as the default browser, but there also needs to be an explicit UX decision on the expected behavior when Firefox is configured manually by the user as the default e-mail client in the operating system (which can happen at any time, not only when initiated by Firefox), but there is no web-based mail service configured in Firefox (which can also happen pretty much at any time, since protocol handlers can be added and removed by the UI, by deleting "handlers.json", or by the Firefox Reset feature). There's probably more than one dependency here.

Comment 21

[:Paolo Amadini]

In fact, I think this is a really valuable feature, not just a bug fix, and something worth tracking as such. I would say there can be value in more involvement from product and UX design teams, maybe with mockups of the behavior in various situations.

Comment 22

[Hal Wine [:hwine] use NI!]

Agreed -- I'll note that other browsers have a workflow that precludes setting the browser as OS default email handler unless a webmail client has already been configured. Firefox currently has this as a two step process, and badness ensues if the steps are not done in the correct order.

Comment 23

[Andreea Pavel [:apavel]]

(In reply to :Paolo Amadini from comment #20)
> I don't know why this re-landed in comment 18 since there's no explanation
> on this bug and I also see no activity on bug 1496380 at the same time, but
> based on the recent discussion there, this needs to be backed out from 64
> and cannot land on any release until bug 1496380 and related matters are
> sorted out.
> 
> In particular, the default for Firefox is to defer to the operating system
> for e-mail handling. Not only Firefox shouldn't be set as the default e-mail
> handler when set as the default browser, but there also needs to be an
> explicit UX decision on the expected behavior when Firefox is configured
> manually by the user as the default e-mail client in the operating system
> (which can happen at any time, not only when initiated by Firefox), but
> there is no web-based mail service configured in Firefox (which can also
> happen pretty much at any time, since protocol handlers can be added and
> removed by the UI, by deleting "handlers.json", or by the Firefox Reset
> feature). There's probably more than one dependency here.

Hi. Pascal requested this bug to be backed out from beta and we backed it out from central first by mistake. The conversation is on #sheriffs. 
After the backout we agreed that the central one was not the correct one and thus this was relanded. 

For additional info, ni pascalc and aryx. 

Thanks.

Comment 24

[:Paolo Amadini]

Thanks!

Comment 25

[Maria Berlinger [:mberlinger], Services QA]

I've managed to reproduce this enhancement using the following STR:

1. Install Firefox.
2. Restart your PC.
3. From "Default app settings" for Email choose Firefox.
4. Launch Firefox and go to preferences (about:preferences).
5. From applications set for "mailto" Firefox.
6. Form any app choose mail option (e.g Bugzilla).

This enhancement is verified fixed in 64.0b3 (BuildId 20181024221315) on Windows 10x64 and Windows 7x86.

Comment 26

[:Paolo Amadini]

Thanks for reminding us that this still needs to be backed out from both Beta and Nightly.

Out of curiosity, what happens after step 6?

Comment 27

[Maria Berlinger [:mberlinger], Services QA]

Actual result:
- The mailto link is opened in Firefox but also in Chrome too and displays a blank page.

This issue refers that you can't choose Firefox to be default app for mailto option. Maybe I wrongly understand what's the issue?

Comment 28

[:Paolo Amadini]

Thanks! The specific issue in the description of the bug is solved, but clearly the blank page and opening in Chrome is not a useful result for users, and in some cases it may be worse, per discussion in bug 1496380.

Hal, can you take care of making sure that this bug is properly backed out from Beta and Nightly, and the backout verified? To do this, you may need to file a new bug with qe-verify+ for the backout patch and request approvals, see for example bug 1472105.

Comment 29

[Hal Wine [:hwine] use NI!]

/me thanks :jcristau for handling this -- it was a bit opaque to me.

Comment 30

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4e7c1539a7a1
Backed out changeset 725a692947dd for opening multiple tabs (bug 1496380) - bug 1512496

Comment 31

[Ryan VanderMeulen [:RyanVM]]

This was backed out from all branches due to bug 1496380.

Comment 32

[Elle Solomina]

Hello! I need fix for the Windows 10 because Windows 7 support is ending soon. In the Windows 7 I simplify add registry files and all works fine. In stupid Windows 10 this method is not working because OS reset application to default value.

For system (with admin rights):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE\Capabilities\URLAssociations]
"mailto"="FirefoxURL"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

For each user:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice]
"Progid"="FirefoxURL"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Comment 33

[Elle Solomina]

Update: for Windows 10 and Windows 7 working:

for all mashine:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Firefox\Capabilities\URLAssociations]
"mailto"="FirefoxURL"

64bits additional:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Clients\StartMenuInternet\Firefox\Capabilities\URLAssociations]
"mailto"="FirefoxURL"

For each user ONLY ON Windows 7 (Windows 10 is stupid and corrupt Firefox ID after this):
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice]
"Progid"="FirefoxURL"

Comment 34

[(no longer active)]

Are (In reply to Ryan VanderMeulen [:RyanVM] from comment #31)

This was backed out from all branches due to bug 1496380.

Are we sure this backout was sufficient? This patch added a new key to the registry, and the backout simply removed the code that added them to the new installations but didn't remove the existing keys from existing installations. As a result, for example on my system I have a mailto=FirefoxURL-6F193CCC56814779 key under HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Firefox-6F193CCC56814779\Capabilities\URLAssociations, and I can reproduce bug 1496380 right now.

Comment 35

[Molly Howell (she/her) (no longer active)]

I left it at the backout because this patch wasn't around for very long (it never made it to release), and because the uninstaller removes this key even with the specific handler backed out, so that means there's an easy and obvious fix already in place in the event of trouble. This is the first report of this problem that I've seen since then.

Comment 36

[(no longer active)]

(In reply to Matt Howell (he/him) [:mhowell] from comment #35)

I left it at the backout because this patch wasn't around for very long (it never made it to release), and because the uninstaller removes this key even with the specific handler backed out, so that means there's an easy and obvious fix already in place in the event of trouble. This is the first report of this problem that I've seen since then.

FWIW I'm commenting here because a user who knows me personally complained to me about what ended up being bug 1496380 after I looked into it. That user runs Firefox Beta, and after extensive web searches trying to identify the source of their problem they had found no helpful pages that described anything about the problem they were facing (e.g. how to rectify Firefox opening tabs in a loop once a link was clicked) and they spoke to me when they were convinced they had no recourse option left to examine besides switching to use Chrome as their main browser. This user wasn't aware of the existence of Bugzilla (as many of our users aren't) but they walked me through a very long list of every single thing they had tried. They also remembered having selected Firefox as the default email application, but the problem had started some time after that had happened (probably because they clicked on the first mailto: link a while after) so they couldn't connect the problem to their action which had caused it.

I think looking at this from the user's perspective, given the severity of the problem that would essentially render the browser completely unusable, I really doubt that there is an obvious and easy fix already in place... I was actually shocked to have discovered that my own system's registry was similarly affected and this could have just as easily occurred to myself, so I guess I really sympathize with how easily this could happen to someone else. :-)

Comment 37

[Molly Howell (she/her) (no longer active)]

Okay. I'm sorry this person had a bad experience, and for my part in causing it. I think I could write a patch that would remove just the mailto: handler registration during an update, but it would need to be more surgical than what the uninstaller is doing, so I would need some time to test that it doesn't affect any other handlers that we want to stay registered for; on Windows 10, the default app settings are pretty fragile, and there's some risk that everything can get automatically reverted to Edge if the OS doesn't like something we did.

Also, for my own reference so that I handle situations like this better in the future, is there some guidance on where to draw the line between issues that we can reasonably expect the nightly or beta population to be able to deal with on their own vs. issues that we should be writing additional patches to mitigate for them? My thinking was that this fit nicely into the former category, so it seems like I had the wrong idea.

Comment 38

[(no longer active)]

(In reply to Matt Howell (he/him) [:mhowell] from comment #37)

Okay. I'm sorry this person had a bad experience, and for my part in causing it. I think I could write a patch that would remove just the mailto: handler registration during an update, but it would need to be more surgical than what the uninstaller is doing, so I would need some time to test that it doesn't affect any other handlers that we want to stay registered for; on Windows 10, the default app settings are pretty fragile, and there's some risk that everything can get automatically reverted to Edge if the OS doesn't like something we did.

Thanks, makes sense.

Also, for my own reference so that I handle situations like this better in the future, is there some guidance on where to draw the line between issues that we can reasonably expect the nightly or beta population to be able to deal with on their own vs. issues that we should be writing additional patches to mitigate for them? My thinking was that this fit nicely into the former category, so it seems like I had the wrong idea.

To be honest I can't blame you for thinking that at all. I could be totally wrong here but I think this was a super tricky case where we had a patch which caused a particularly bad behaviour without any obvious recourse path for the user which we were aware of and tried to mitigate against through a backout and that didn't work completely either. I was looking at the problem from the effect back to the cause and it was still completely non-obvious what had gone wrong and what should have happened to have prevented it, and it took hours of looking through various bugs, comments, patches to tie the full back story together.

I could see anyone else in your shoes (myself included) to have made the same decision to stick with a simple backout previously. The only reason why I am now arguing perhaps we should do more is that I saw the implications play out for a user which convinced me that a reasonable trade-off here would be the other way around. Unfortunately this information isn't always available right when we need it. :-/

Comment 39

[Molly Howell (she/her) (no longer active)]

(In reply to :ehsan akhgari from comment #38)

Thanks, makes sense.

I've filed bug 1587536 for this

To be honest I can't blame you for thinking that at all. I could be totally wrong here but I think this was a super tricky case where we had a patch which caused a particularly bad behaviour without any obvious recourse path for the user which we were aware of and tried to mitigate against through a backout and that didn't work completely either. I was looking at the problem from the effect back to the cause and it was still completely non-obvious what had gone wrong and what should have happened to have prevented it, and it took hours of looking through various bugs, comments, patches to tie the full back story together.

I could see anyone else in your shoes (myself included) to have made the same decision to stick with a simple backout previously. The only reason why I am now arguing perhaps we should do more is that I saw the implications play out for a user which convinced me that a reasonable trade-off here would be the other way around. Unfortunately this information isn't always available right when we need it. :-/

Thanks. It was certainly an odd situation, and I apologize again for missing how severe the failure mode was.

Comment 40

[:Gijs (he/him)]

Do we want to reland this now that the infinite loop thing has been fixed? (at least on Windows/macOS, in bug 1496380)

Comment 41

[Hal Wine [:hwine] use NI!]

That would be awesome -- I hadn't been following that bug. I have no idea how to request the reland, though.

Comment 42

[:Gijs (he/him)]

(In reply to Hal Wine [:hwine] (use NI, please) from comment #41)

That would be awesome -- I hadn't been following that bug. I have no idea how to request the reland, though.

I think you can just update the patch and use lando as usual? I would have just hit the button, but it tells me:

Diff does not have proper author information in Phabricator. See the Lando FAQ for help with this error.

Comment 44

[Hal Wine [:hwine] use NI!]

Attachment: Bug 675428 - register Firefox to handle mailto URLs in Windows

Allow Firefox to be specified as a handler for 'mailto:' urls on Windows.

Re commit of Phabricator differential D2247 -- that's too old to be reused.

Comment 45

[Hal Wine [:hwine] use NI!]

waiting on bug 1620132 so I can run on try -- this is what I get for taking a year to fix it ;)

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be2f741ae6af
register Firefox to handle mailto URLs in Windows r=mhowell

Comment 47

[Cristina Coroiu [:ccoroiu]]

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

Comment 48

[abodenlosz]

Tried to verify the enhancement on Firefox Nightly 76.0a1 (2020-03-11) but the default mailto application is disabled in Windows Default Programs. Also tried to set default mailto app within Nightly in about:preferences but was unable to start it when selecting Firefox for select prompt, the button was not disabled but was uable to start it until choosing another mail sendoff from the list This verification took place on Windows 7 x86.

Attaching link to screenshot: https://imgur.com/FjSViCk

Comment 49

[:Gijs (he/him)]

(In reply to abodenlosz from comment #48)

Please do not change the status flags.

the default mailto application is disabled in Windows Default Programs.

What does this mean?

Also tried to set default mailto app within Nightly in about:preferences

I don't understand this either.

but was unable to start it when selecting Firefox for select prompt, the button was not disabled but was uable to start it until choosing another mail sendoff from the list This verification took place on Windows 7 x86.

Yeah, this seems like you're just telling Firefox to start Firefox to open a mailto link, which is going to end badly - it used to mean infinite tabs, but after bug 1496380 we will just prompt.

To be clear this set of changes is meant to enable clicking a mailto: link outside of Firefox to open with Firefox and use a web page inside Firefox (like gmail or yahoo mail, which are in your screenshot) to handle the mailto link. It's not meant to magically change Firefox into an email client itself...

Comment 50

[abodenlosz]

Okay, thank you for clarifying. Updating flag to verified.