Open Bug 675428 Opened 9 years ago Updated 4 months ago

register firefox as default OS mail client on Windows

Categories

(Firefox :: File Handling, enhancement, P3)

6 Branch
x86
Windows 7
enhancement

Tracking

()

REOPENED

People

(Reporter: ivan.icin, Unassigned)

References

Details

(Keywords: feature)

Attachments

(2 files)

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.
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.
Severity: normal → enhancement
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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? ;))
Duplicate of this bug: 678767
Assignee: nobody → netzen
Assignee: netzen → nobody
Duplicate of this bug: 1346824
feature requested 6 year ago and till now mailto is not showing firefox default client.
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.
At least in Win10, Firefox is not an option to configure as a mailto handler.
Assignee: nobody → hwine
Comment on attachment 8993454 [details]
Bug 675428 - register Firefox to handle mailto URLs in Windows

Matt Howell [:mhowell] has approved the revision.
Attachment #8993454 - Flags: review+
Pushed by dvarga@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/39f0d4e66898
register Firefox to handle mailto URLs in Windows r=mhowell
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/39f0d4e66898
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Attached image 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).
Flags: needinfo?(hwine)
*Should I open a new bug for it or is it something that needs to /can be fixed here?
(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!
Flags: needinfo?(hwine)
No longer depends on: 1496380
See Also: → 1496380
Depends on: 1496380
See Also: 1496380
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?
Flags: needinfo?(hwine)
Keywords: feature
Backout by apavel@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/20773596530b
Backed out changeset 39f0d4e66898 for causing Bug 1496380 a=backout
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 63 → ---
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/725a692947dd
register Firefox to handle mailto URLs in Windows r=mhowell a=reland
Status: REOPENED → RESOLVED
Closed: 2 years agoLast year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
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"
Flags: needinfo?(hwine)
Summary: register firefox as default mail client → register firefox as default OS mail client on Windows
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.
Flags: needinfo?(hwine)
Flags: needinfo?(apavel)
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.
Component: General → File Handling
Priority: -- → P3
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.
Flags: needinfo?(hwine)
(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.
Flags: needinfo?(pascalc)
Flags: needinfo?(aryx.bugmail)
Flags: needinfo?(apavel)
Thanks!
Flags: needinfo?(pascalc)
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
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?
Flags: needinfo?(maria.berlinger)
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?
Flags: needinfo?(maria.berlinger) → needinfo?(paolo.mozmail)
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.
Flags: needinfo?(paolo.mozmail) → needinfo?(hwine)
Depends on: 1512496
/me thanks :jcristau for handling this -- it was a bit opaque to me.
Flags: needinfo?(hwine)
Backout by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4e7c1539a7a1
Backed out changeset 725a692947dd for opening multiple tabs (bug 1496380) - bug 1512496
This was backed out from all branches due to bug 1496380.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 64 → ---
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"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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"

Assignee: hwine → nobody

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.

Flags: needinfo?(ryanvm)
Flags: needinfo?(ryanvm) → needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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

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.

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

See Also: → 1587536

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

You need to log in before you can comment on or make changes to this bug.