register firefox as default OS mail client on Windows
Categories
(Firefox :: File Handling, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox76 | --- | verified |
People
(Reporter: ivan.icin, Assigned: hwine)
References
Details
(Keywords: feature)
Attachments
(3 files)
Updated•13 years ago
|
Comment 2•13 years ago
|
||
Updated•13 years ago
|
Updated•11 years ago
|
Comment 6•7 years ago
|
||
Assignee | ||
Comment 7•6 years ago
|
||
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Comment 9•6 years ago
|
||
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Assignee | ||
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
Comment 16•6 years ago
|
||
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
Updated•6 years ago
|
Assignee | ||
Comment 19•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Comment 20•6 years ago
|
||
Comment 21•6 years ago
|
||
Assignee | ||
Comment 22•6 years ago
|
||
Comment 23•6 years ago
|
||
Updated•6 years ago
|
Comment 25•6 years ago
|
||
Comment 26•6 years ago
|
||
Comment 27•6 years ago
|
||
Comment 28•6 years ago
|
||
Assignee | ||
Comment 29•6 years ago
|
||
Updated•6 years ago
|
Comment 30•6 years ago
|
||
Comment 31•6 years ago
|
||
Comment 32•6 years ago
|
||
Comment 33•6 years ago
|
||
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 | ||
Updated•6 years ago
|
Comment 34•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 35•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
(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. :-/
Updated•5 years ago
|
Comment 39•5 years ago
|
||
(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•5 years ago
|
||
Do we want to reland this now that the infinite loop thing has been fixed? (at least on Windows/macOS, in bug 1496380)
Assignee | ||
Comment 41•5 years ago
|
||
That would be awesome -- I hadn't been following that bug. I have no idea how to request the reland, though.
Comment 42•5 years ago
|
||
(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.
Updated•5 years ago
|
Assignee | ||
Comment 44•5 years ago
|
||
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.
Assignee | ||
Comment 45•5 years ago
|
||
waiting on bug 1620132 so I can run on try -- this is what I get for taking a year to fix it ;)
Comment 46•5 years ago
|
||
Comment 47•5 years ago
|
||
bugherder |
Comment 48•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
Okay, thank you for clarifying. Updating flag to verified.
Description
•