Open Bug 1509918 Opened 6 years ago Updated 7 months ago

thunderbird can't register itself as the default mail app on win7

Categories

(Thunderbird :: OS Integration, defect, P5)

Product:
Thunderbird
Component:
OS Integration
Platform:
x86_64
Windows 7
Type:
defect

Tracking

(thunderbird68- affected)

Tracking Flags:
Tracking Status
thunderbird68 - affected

People

(Reporter: bughit.github, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

win7 x64 sp1, tb 60.3.1 x64

start thunderbird, exit, start


Actual results:

sytem integration dialog pops up on every start


Expected results:

no dialog after clicking "set as default" the first time
tb 52.9.1 is ok
Version: 63 → 60
I've started TB 60 on a new profile and left the "Always perform this check" box set and clicked "Set as Default". On second start, I didn't get the prompt any more.

What happens if you un-check the "Always perform this check" box or click "Skip Integration"?

Can you check the value of the following preferences, Tools > Options, Advanced, General, Config Editor, paste "mail.shell.checkDefaultClient" into the search window. That's the preference tied to the "Always perform this check" box.

When you click "Set Default", TB tries to register itself as the default client, if that fails for some reason, the prompt would show up again.

Are there any errors related to this in the error console?
Tools > Developer Tools > Error Console.

This is the first time I've heard about the problem, so I hope it's a singular case.
> I've started TB 60 on a new profile

Did you match os and bitness? win7 x64 sp1, tb 60.3.1 x64

> What happens if you un-check the "Always perform this check" box or click "Skip Integration"?

Then it does not prompt, that's a workaround not a solution.

mail.shell.checkDefaultClient corresponds to the ui, so there's no issue there, it was true

A manual check ("Check Now..." in options) always shows email unchecked after after a prior "Set as Default" so it looks like default setting or checking is broken. There's nothing in the error log.

> This is the first time I've heard about the problem, so I hope it's a singular case.

It's not a singular case, I reproed in a win7 vm.

The following is read from the registry on a manual check:

_________________________________

3:53:32.3276462 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: Name
3:53:32.3276991 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3278059 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3279176 PM	thunderbird.exe	9640	RegOpenKey	HKCU\Software\Classes\.eml	SUCCESS	Desired Access: Read
3:53:32.3280385 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes\.eml	SUCCESS	Query: Name
3:53:32.3281476 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes\.eml	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3282616 PM	thunderbird.exe	9640	RegOpenKey	HKCR\.eml	SUCCESS	Desired Access: Maximum Allowed, Granted Access: Read
3:53:32.3283836 PM	thunderbird.exe	9640	RegQueryValue	HKCU\Software\Classes\.eml\(Default)	SUCCESS	Type: REG_SZ, Length: 30, Data: ThunderbirdEML
3:53:32.3284954 PM	thunderbird.exe	9640	RegCloseKey	HKCR\.eml	SUCCESS	
3:53:32.3286022 PM	thunderbird.exe	9640	RegCloseKey	HKCU\Software\Classes\.eml	SUCCESS	
3:53:32.3286782 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: Name
3:53:32.3287873 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3288915 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3290009 PM	thunderbird.exe	9640	RegOpenKey	HKCU\Software\Classes\ThunderbirdEML\shell\open\command	SUCCESS	Desired Access: Read
3:53:32.3291142 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes\ThunderbirdEML\shell\open\command	SUCCESS	Query: Name
3:53:32.3292233 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes\ThunderbirdEML\shell\open\command	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3293354 PM	thunderbird.exe	9640	RegOpenKey	HKCR\ThunderbirdEML\shell\open\command	SUCCESS	Desired Access: Maximum Allowed, Granted Access: Read
3:53:32.3294533 PM	thunderbird.exe	9640	RegQueryValue	HKCU\Software\Classes\ThunderbirdEML\shell\open\command\(Default)	SUCCESS	Type: REG_SZ, Length: 132, Data: "C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe" "%1"
3:53:32.3295612 PM	thunderbird.exe	9640	RegCloseKey	HKCR\ThunderbirdEML\shell\open\command	SUCCESS	
3:53:32.3296669 PM	thunderbird.exe	9640	RegCloseKey	HKCU\Software\Classes\ThunderbirdEML\shell\open\command	SUCCESS	
3:53:32.3299573 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: Name
3:53:32.3300626 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3301652 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3302728 PM	thunderbird.exe	9640	RegOpenKey	HKCU\Software\Classes\Thunderbird.Url.news\shell\open\command	NAME NOT FOUND	Desired Access: Read
3:53:32.3303887 PM	thunderbird.exe	9640	RegOpenKey	HKCR\Thunderbird.Url.news\shell\open\command	SUCCESS	Desired Access: Read
3:53:32.3305085 PM	thunderbird.exe	9640	RegQueryKey	HKCR\Thunderbird.Url.news\shell\open\command	SUCCESS	Query: Name
3:53:32.3306130 PM	thunderbird.exe	9640	RegQueryKey	HKCR\Thunderbird.Url.news\shell\open\command	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3306715 PM	thunderbird.exe	9640	RegOpenKey	HKCU\Software\Classes\Thunderbird.Url.news\shell\open\command	NAME NOT FOUND	Desired Access: Maximum Allowed
3:53:32.3307768 PM	thunderbird.exe	9640	RegQueryValue	HKCR\Thunderbird.Url.news\shell\open\command\(Default)	BUFFER OVERFLOW	Length: 144
3:53:32.3308810 PM	thunderbird.exe	9640	RegQueryValue	HKCR\Thunderbird.Url.news\shell\open\command\(Default)	SUCCESS	Type: REG_SZ, Length: 146, Data: "C:\Program Files\Mozilla Thunderbird\thunderbird.exe" -osint -mail "%1"
3:53:32.3309866 PM	thunderbird.exe	9640	RegCloseKey	HKCR\Thunderbird.Url.news\shell\open\command	SUCCESS	
3:53:32.3310969 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: Name
3:53:32.3312025 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3313052 PM	thunderbird.exe	9640	RegQueryKey	HKCU\Software\Classes	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3314124 PM	thunderbird.exe	9640	RegOpenKey	HKCU\Software\Classes\news\shell\open\command	NAME NOT FOUND	Desired Access: Read
3:53:32.3315245 PM	thunderbird.exe	9640	RegOpenKey	HKCR\news\shell\open\command	NAME NOT FOUND	Desired Access: Read
3:53:32.3422391 PM	thunderbird.exe	9640	RegQueryKey	HKLM	SUCCESS	Query: HandleTags, HandleTags: 0x0
3:53:32.3423584 PM	thunderbird.exe	9640	RegOpenKey	HKLM\SOFTWARE\Microsoft\CTF\KnownClasses	NAME NOT FOUND	Desired Access: Read
______________________________________

the following is written when "set as default" is clicked

_____________________________________
3:58:19.1290203 PM	helper.exe	5188	RegSetValue	HKCU\Software\Mozilla\Thunderbird\TaskBarIDs\C:\Program Files\Mozilla Thunderbird	SUCCESS	Type: REG_SZ, Length: 34, Data: D78BF5DD33499EC2
3:58:19.1332224 PM	helper.exe	5188	RegSetValue	HKCU\Software\Clients\Mail\(Default)	SUCCESS	Type: REG_SZ, Length: 40, Data: Mozilla Thunderbird
3:58:19.1409178 PM	helper.exe	5188	RegDeleteValue	HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eml\UserChoice\Progid	SUCCESS	
3:58:19.1421744 PM	helper.exe	5188	RegSetValue	HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eml\UserChoice\Progid	SUCCESS	Type: REG_SZ, Length: 30, Data: ThunderbirdEML
3:58:19.1451450 PM	helper.exe	5188	RegDeleteValue	HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wdseml\UserChoice\Progid	SUCCESS	
3:58:19.1464643 PM	helper.exe	5188	RegSetValue	HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wdseml\UserChoice\Progid	SUCCESS	Type: REG_SZ, Length: 30, Data: ThunderbirdEML
3:58:19.1480965 PM	helper.exe	5188	RegSetValue	HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice\Progid	SUCCESS	Type: REG_SZ, Length: 46, Data: Thunderbird.Url.mailto
3:58:19.1491685 PM	helper.exe	5188	RegSetValue	HKCU\Software\Clients\Mail\(Default)	SUCCESS	Type: REG_SZ, Length: 40, Data: Mozilla Thunderbird
______________________________________________


the one obvious thing that jumps out is

HKCU\Software\Classes\ThunderbirdEML\shell\open\command\(Default)	SUCCESS	Type: REG_SZ, Length: 132, Data: "C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe" "%1"

This is still pointing to the x86 52.9.1 and the set default from x64 60.3.1 does not alter it
(In reply to bughit from comment #3)
> > I've started TB 60 on a new profile
> Did you match os and bitness? win7 x64 sp1, tb 60.3.1 x64
No, I have no Win7 at hand, I'm on Win10.

> Then it does not prompt, that's a workaround not a solution.
Indeed, but it gets rid of the nuisance.

> mail.shell.checkDefaultClient corresponds to the ui, so there's no issue
> there, it was true
Indeed.

> A manual check ("Check Now..." in options) always shows email unchecked
> after after a prior "Set as Default" so it looks like default setting or
> checking is broken. There's nothing in the error log.
OK, well, the setting should report an error:
https://searchfox.org/comm-central/rev/efacd58fa63199a34709dc95b05bb9ab56d45f13/suite/components/shell/ShellService.jsm#69

> > This is the first time I've heard about the problem, so I hope it's a singular case.
> It's not a singular case, I reproed in a win7 vm.
:-(

> the one obvious thing that jumps out is
> HKCU\Software\Classes\ThunderbirdEML\shell\open\command\(Default)	SUCCESS
> Type: REG_SZ, Length: 132, Data: "C:\Program Files (x86)\Mozilla
> Thunderbird\thunderbird.exe" "%1"
> This is still pointing to the x86 52.9.1 and the set default from x64 60.3.1
> does not alter it
I see you're a Windows debugging expert ;-)

Maybe that's a general problem with the 64bit version. Officially, there's isn't a 64bit version. This may well be an installer bug. Could be related to bug 1507618.

Richard, could you take a look, you also have a Win7 VM.
Flags: needinfo?(richard.marti)
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
See Also: → 1507618
Summary: "use thunderbird as default client" prompt on every startup → "use thunderbird as default client" prompt on every startup on WIndows 7 using TB 64bit
in HKCU\Software\Classes, besides ThunderbirdEML, also mailto and Thunderbird.Url.mailto were pointing to the old x86 path

I fixed the path on all of them and now the default check shows email checked and there are no further prompts on startup.

The "set as default" operation from x64 tb fails to set at least the above paths. If you notice something it misses, please post so I can fix it manually.
Could you attach a .reg file with the changed values for our reference. Thanks in advance.
it's easier to communicate this without a reg file

The default value of the following keys:

HKEY_CURRENT_USER\Software\Classes\mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\shell\open\command

contained the path to the old x86 52.9.1 tb: C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe
I changed it to the new x64 60.3.1 path: C:\Program Files\Mozilla Thunderbird\thunderbird.exe
Hmm, isn't HKCU just a copy of HKLM hauled in for the current user? Sorry, I have very partial knowledge of that. And for x64 programs the stuff goes into the Wow6432Node subkey, no?

Robert, this is the second query today from the TB team. Can you help us identifying what's going wrong with registering the x64 version of TB as the default e-mail client or the check. See the previous comment and comment #3 for registry entries read and written and tweaked. Thanks in advance.
Flags: needinfo?(robert.strong.bugs)
> isn't HKCU just a copy of HKLM

no, every user has their own HKCU hive, distinct from HKLM

> And for x64 programs the stuff goes into the Wow6432Node subkey, no?

Wow6432Node is projected for x86 binaries on x64, you would only write to it if you wanted x86 programs to see different content than x64, which in this case I don't think you do. Extensions and their handlers are the same for x86 and x64
I might be wrong but it looks to me that the checks that Thunderbird performs haven't been updated for newer versions of Windows as they have been for Firefox.

Firefox
https://dxr.mozilla.org/mozilla-central/source/browser/components/shell/nsWindowsShellService.cpp

Thunderbird
https://dxr.mozilla.org/comm-central/source/comm/mail/components/shell/nsWindowsShellService.cpp
Flags: needinfo?(robert.strong.bugs)
BTW: the setting of registry keys directly was done to workaround apps that didn't use the new api's added in Win Vista. It shouldn't be an issue to no longer do that for Thunderbird and I believe it was done for Firefox already.
Are you saying that the following keys don't need to be set at all?

HKEY_CURRENT_USER\Software\Classes\mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\shell\open\command

AFAIK, .eml is handled
didn't finish,

... to take ThunderbirdEML as an example, .eml needs to be handled by something and if tb is to be the default it needs to be handled by ThunderbirdEML which needs to exist and have the correct path.
No, just the ones that are needed by the new API's so the OS can handle the application registration. In the case of Firefox they are FirefoxURL and FirefoxHTML. The main point I'm saying is that the shell integration code should only check the keys used by the new API's when checking if Thunderbird is default and all they need to check is if they point to the installation of Thunderbird being checked along with the correct command line flags similar to.

https://dxr.mozilla.org/mozilla-central/source/browser/components/shell/nsWindowsShellService.cpp#154

The OS provided API sets the handler at the user level. iirc setting as default for all the users of the OS it still needs to set all of the registry keys.
Note: setting as default for all the users of the OS doesn't override what the user sets... it just sets the default.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #14)
<snip> 
> The OS provided API sets the handler at the user level. iirc setting as
> default for all the users of the OS it still needs to set all of the
> registry keys.
I forgot to mention that Firefox now launches the OS provided UI so the clients can set as default instead of invoking the new API directly. I don't know the details behind this decision but you should be able to find the dev that implemented this for all Windows versions using blame.
> No, just the ones that are needed by the new API's

Can you be specific? Which of the following keys are you saying don't need to be set:

HKEY_CURRENT_USER\Software\Classes\mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\shell\open\command

Because currently, not setting them (from x64 tb) produces this bug, of which the dialog on every startup is merely a symptom. The underlying issue is that without some/all of these, the 60.3.1 x64 tb is not properly set up as the default email app.

The above paths remain pointing to the wrong exe for the icon and execution. Something needs to set them.
The Thunderbird code linked below checks the values of those keys which causes the prompt that this bug report is about. That's why changing those reg values fixes it for you. What I'm saying is that it appears that the Thunderbird code hasn't been updated to reflect the changes that have been made in Firefox (for Thunderbird of course) and that the prompt is displaying because of these checks that are no longer performed in Firefox. It is also entirely possible that this could be fixed in some other manner. From this point a Thunderbird dev will need to decide on which path forward to take. I recommend taking a path similar to what Firefox does using Firefox's nsWindowsShellService.cpp for guidance, etc.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #10)
> I might be wrong but it looks to me that the checks that Thunderbird
> performs haven't been updated for newer versions of Windows as they have
> been for Firefox.
> 
> Firefox
> https://dxr.mozilla.org/mozilla-central/source/browser/components/shell/
> nsWindowsShellService.cpp
> 
> Thunderbird
> https://dxr.mozilla.org/comm-central/source/comm/mail/components/shell/
> nsWindowsShellService.cpp

You can see the defines used for these checks here
https://dxr.mozilla.org/comm-central/source/comm/mail/components/shell/nsWindowsShellService.cpp#68
> The Thunderbird code linked below checks the values of those keys which causes the prompt that this bug report is about

And I already explained that the prompt is a symptom of the underlying problem which is that the default registration has not taken place.

If DefaultIcon and shell\open\command paths are wrong then the wrong icon will be displayed and wrong app started on various actions. Do you consider that a non-issue? Because you keep insisting that there is some alternative to properly setting those paths.
I'm didn't say that and I'm not saying that
Tested now on Win7 VM. No matter if it's a 32bit or a 64bit version, it doesn't register as default. So Robert's proposal in comment 18 should be the way forward.
Flags: needinfo?(richard.marti)
> it doesn't register as default

true, so that means registration should be fixed

> So Robert's proposal in comment 18 should be the way forward.

How so? His proposal does not involve fixing the registration, i.e. setting these keys

HKEY_CURRENT_USER\Software\Classes\mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\Thunderbird.Url.mailto\shell\open\command
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\DefaultIcon
HKEY_CURRENT_USER\Software\Classes\ThunderbirdEML\shell\open\command

he is claiming that the checking for defaultness is outdated, wrong and should be updated, here's his exact claim from Comment 18

> Thunderbird code hasn't been updated to reflect the changes that have been made in Firefox (for Thunderbird of course) and that the prompt is displaying because of these checks that are no longer performed in Firefox.

What does the assertion "the prompt is displaying because of these checks that are no longer performed in Firefox" mean to you?

It seems pretty clear to me, "you're checking it wrong", according to him.
I'm saying that the current Thunderbird shell integration code should be updated to reflect the changes made to Firefox over the years. It was the first thing I noticed while briefly looking at the code. I used to update the Thunderbird shell integration and installer code many years ago but I am no longer able to and it is very out of date. There are checks for the value of FirefoxHTML and FirefoxURL in the Firefox shell integration code which are the equivalent of ThunderbirdEML, Thunderbird.Url.mailto, Thunderbird.Url.news, and Thunderbird.Url.feed. One or more of those will need to be checked for Thunderbird. I say one or more of them because one should be all that is necessary since they should all be set to the same installation at the same time. Either the shell\open\command or the DefaultIcon should be checked... in Firefox only the shell\open\command value is checked. Thunderbird would launch the helper.exe to set these registry keys if they aren't correct just as the Firefox shell integration code does. It would be a good thing to update the nsis code used by the helper.exe to reflect the changes made in Firefox at the same time. Thunderbird would also open the OS provided associations UI to set as default just as Firefox does. If the Thunderbird developers don't want to update the Thunderbird code to reflect the changes that Firefox has made over the years then they can look into fixing it in another way... as I said in comment #18 "It is also entirely possible that this could be fixed in some other manner."
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #16)
> I forgot to mention that Firefox now launches the OS provided UI so the
> clients can set as default instead of invoking the new API directly.

It is untrue on Windows 7.

> I don't
> know the details behind this decision but you should be able to find the dev
> that implemented this for all Windows versions using blame.

On Win8+, we (Firefox devs) had to launch the OS provided UI because Win8+ do not provide a way to set as default programmatically.

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #18)

From this point a Thunderbird dev will need to decide on which path forward
to take.

Hi Robert, what makes you think that we have Windows system programming skills in our team? I think we will need to hire an external contractor for this work, and while they are at it, also other Windows related issues, like MAPI, in these bugs:
Bug 393302, bug 1517955 (just in which might be a variation on this bug), bug 1506488, bug 547027.

I compared the M-C and C-C versions of nsWindowsShellService.cpp and it would be an expensive matter of trial and error for me trying to work out which bits need to be ported over.

Would you happen to know anyone with the right skill set we could approach?

Flags: needinfo?(robert.strong.bugs)

(In reply to Masatoshi Kimura [:emk] from comment #24)

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to
contact me) from comment #16)

I forgot to mention that Firefox now launches the OS provided UI so the
clients can set as default instead of invoking the new API directly.

It is untrue on Windows 7.

Looks like in Firefox's nsWindowsShellService.cpp Windows 7 launches UI as well.

Flags: needinfo?(robert.strong.bugs)

Jorg, nothing makes me think that Thunderbird has Windows system programming skills in your team especially after Scott, David, and Seth left. I've helped out on my own time over the years because of this.

You might be able to find someone from the log of changes on nsWindowsShellService.cpp

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #26)

(In reply to Masatoshi Kimura [:emk] from comment #24)

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to
contact me) from comment #16)

I forgot to mention that Firefox now launches the OS provided UI so the
clients can set as default instead of invoking the new API directly.

It is untrue on Windows 7.

Looks like in Firefox's nsWindowsShellService.cpp Windows 7 launches UI as well.

Really? Windows 7 will never launch UI due to IsWin8OrLater() check here:
https://searchfox.org/mozilla-central/rev/c3ebaf6de2d481c262c04bb9657eaf76bf47e2ac/browser/components/shell/nsWindowsShellService.cpp#410

I also confirmed that Firefox 64 did not launch UI on my Win7 box.

Thanks for pointing that out... I missed that when skimming the file. Anyways, I haven't worked on shell integration for quite some time and haven't kept up with it. Perhaps emk can help out with this.

This bug is not related with 32-bit vs. 64-bit. I can reproduce the issue if I install both Thunderbird 52 and 60 side by side. Apparently Thunderbird 52 will write registry keys under HKCU\Software\Classes, but Thunderbird 60 will not.

Keywords: 64bit

emk's observation in comment 30 looks interesting; indeed, correcting the registry keys will stop the prompts with TB x64 on a system where a 32bit release was there before - though only a clean install of 32bit TB 60 can rule out such a regression from 52.

If this bug isn't fixed for Thunderbird 68 ESR can it be closed as WONTFIX as "after January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7"? Thank you
https://www.microsoft.com/en-us/windowsforbusiness/end-of-windows-7-support

(In reply to Óvári from comment #32)

If this bug isn't fixed for Thunderbird 68 ESR can it be closed as WONTFIX as "after January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7"?

We wouldn't do that today or in the coming months, when Thunderbird (and Firefox) typically support OSes 1-2 years after a vendor desupports an OS. Not even sure why you suggest this, when there are clearly efforts to resolve the issue

Mike do you have any insight to apply to this?

This may be the last code issue standing in the way of bug 634233

Blocks: support-win64-thunderbird
Flags: needinfo?(mikekaganski)
See Also: support-win64-thunderbird →

(In reply to Wayne Mery (:wsmwk) from comment #34)

Mike do you have any insight to apply to this?

I suppose it's some problem in helper.exe - which is an NSIS installer executable. I don't know enough about NSIS, unfortunately. I only can say that a master build I made shows a UAC prompt for me when I ask it to make TB the default application on Windows 10 x64 (primary development box), while doesn't ask for elevated permissions on Win7 x64 VM, and runs and only sets some per-user settings (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts.eml and the like). But possibly that is unrelated, and could be because of some debug library missing on the VM or something...

Flags: needinfo?(mikekaganski)

Jorg, in bug 1517955 comment 2 you mention this is on your todo list. Can yuo sort this for 68? Or do we need additional resources?

Blocks: 1517955
status-thunderbird68: --- → affected
Flags: needinfo?(jorgk)

As per comment #23, the TB shell integration needs to be brought in line with years of development in FF. As per comment #25, I looked at nsWindowsShellService.cpp and concluded that a person with the appropriate skill set needs to do that. Maybe the issue is easier as per comment #30, there might even just be a regression that needs fixing.

tracking-thunderbird68: --- → +
Flags: needinfo?(jorgk)

I checked a bit the history of the FX nsWindowsShellService.cpp.cpp. Here are some bugs that manage the default browser:

Bug 1324617 - Allow any of multiple installations to be set as the Windows default browser
Bug 1337530 - Fix Windows default browser detection
Bug 1338843 - Use the install path to distinguish between multiple installations when checking default browser status

Maybe this could help.

(In reply to Jorg K (GMT+2) from comment #37)

As per comment #23, the TB shell integration needs to be brought in line with years of development in FF. As per comment #25, I looked at nsWindowsShellService.cpp and concluded that a person with the appropriate skill set needs to do that. Maybe the issue is easier as per comment #30, there might even just be a regression that needs fixing.

Did anybody look into this comment #30 thing yet?

Just updated to 60.8.0 (32-bit). Still 32 bit.

Sadly not, not many Windows "system programmers" around. But it's on the radar.

Blocks: 1568550

(In reply to Masatoshi Kimura [:emk] from comment #30)

This bug is not related with 32-bit vs. 64-bit. I can reproduce the issue if I install both Thunderbird 52 and 60 side by side. Apparently Thunderbird 52 will write registry keys under HKCU\Software\Classes, but Thunderbird 60 will not.

(In reply to Hungerburg from comment #31)

emk's observation in comment 30 looks interesting; indeed, correcting the registry keys will stop the prompts with TB x64 on a system where a 32bit release was there before - though only a clean install of 32bit TB 60 can rule out such a regression from 52.

(In reply to Jorg K (GMT+2) from comment #37)

As per comment #23, the TB shell integration needs to be brought in line with years of development in FF.

I just created bug 1572266 to get this started

(In reply to Richard Marti (:Paenglab) from comment #38)

I checked a bit the history of the FX nsWindowsShellService.cpp.cpp. Here are some bugs that manage the default browser:

Bug 1324617 - Allow any of multiple installations to be set as the Windows default browser
Bug 1337530 - Fix Windows default browser detection
Bug 1338843 - Use the install path to distinguish between multiple installations when checking default browser status

Maybe this could help.

Does someone else want to create 3 new bugs for Thunderbird to do these things?

Not really. We can do a port in this bug here. Creating more bugs doesn't fix the issue. We need to find a person who can do it.

Is there a registry editor file for me to just launch and have the prompt not appear anymore? I just installed 68 x64 on a w7 system, even using the 32bit version of TB, it comes up every start.

Why don't you switch off the check in TB?

Options, Advanced, System Integration: Always check to see if Thunderbird is the default mail client on startup.

Thank you Jörg; in fact, the very same prompt for system integration offers the checkbox, to not ask again. I just wanted to make sure, TB is registered.

Nevertheless, the "send email" explorer desktop shortcut opens up a TB compose window - I did not try from other software that calls to mapi though…

Curiously, the "default apps" system control does not even list a "send email" action, nor does TB provide a "send email" action there (only nttp and news).

TB will stay registered until some other software registers itself ... which doesn't happen on my machine, hence no need to check.

Yes, we fixed MAPI even for 64bit now, it works OK from various programs, like LibreOffice. Plus, TB is integrated via MAPI into many workflows, so we hear about it very soon if something doesn't work.

As for the "default apps", there there's only a setting for Email in the UI, but TB registers itself for stuff like news/NNTP IIRC.

Reading though the bug, you'll see that in comment #3 the reporter told us that switching off the check wasn't a solution, only a workaround, and I agree. There are also registry settings in comment #7.

Do we need to hire someone?

Flags: needinfo?(mkmelin+mozilla)

Possibly.

Flags: needinfo?(mkmelin+mozilla)

(In reply to Óvári from comment #32)

If this bug isn't fixed for Thunderbird 68 ESR can it be closed as WONTFIX as "after January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7"? Thank you
https://www.microsoft.com/en-us/windowsforbusiness/end-of-windows-7-support

(In reply to Wayne Mery (:wsmwk) from comment #33)

(In reply to Óvári from comment #32)

If this bug isn't fixed for Thunderbird 68 ESR can it be closed as WONTFIX as "after January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7"?

We wouldn't do that today or in the coming months, when Thunderbird (and Firefox) typically support OSes 1-2 years after a vendor desupports an OS. Not even sure why you suggest this, when there are clearly efforts to resolve the issue

Just an FYI that this January 14, 2020 date has now passed.

That said, I am running a Thunderbird nightly build, and whenever I click on a mailto: link in Firefox (also nightly), it will open a bazillion Microsoft IE windows, to the point of me needing to restart my computer to kill it. Not sure if this helps anything or not. Let me know if there is anything you would like me to try.

Windows 7 is no longer supported by Microsoft.

How does that affect this bug?

For the record : I have none of the keys reported by bughit in my W7 64bits registry, but still I've got the same behaviour.
Had a Thunderbird that updated itself for a long time without this problem. I decided to move Thunderbird from one disk to another by uninstalling it then installing a fresh downloaded version. Now I'm hit by the bug.
TB announces to be 68.7.0 32bits by the way.

(In reply to Worcester12345 from comment #55)

Windows 7 is no longer supported by Microsoft. How does that affect this bug?

It doesn't significantly affect this bug because a) there is still a significant percentage of Thunderbird users on win7, b) the decision of how critical we see this bug is tied to whether WE officially support Windows 7, and as of this date we still do. I suspect we will until some time in 2021. (which is essentially what I point out in comment 33)

tracking-thunderbird68: + → -
Priority: -- → P5

Is this fixed (WORKSFORME) or no (WONTFIX)? It might be good to just resolve this one way or the other.

I've long since given up on this being fixed. But it should be pointed out that:

  • win7 is supported by MS (win7 ESU)
  • whether it is or not is not particularly relevant
  • there are only two reasons for TB to drop support for win7
    • if its usage becomes insignificant
    • if it has unpatchable RCE that can be exploited via TB
  • neither is the case
  • win7 usage is still huge (~ 25%)
  • it was 40% when this bug was reported 2 years ago
  • releasing an email client that can't be registered as default by 40% of your potential users is absurd

Please look at whether something has block bug before commenting.

(In reply to Worcester12345 from comment #61)

Is this fixed (WORKSFORME) or no (WONTFIX)? It might be good to just resolve this one way or the other.

no

releasing an email client that can't be registered as default by 40% of your potential users is absurd

Thunderbird 32bit is still available and won't be going anywhere for I'd assume 10yrs or more. This bug is strictly for users hanging on to win7 and for unknown reasons want to update to 64 bit Thunderbird even it doesn't make a difference in the program's functionality.

Thunderbird 32bit is still available

This is a not a 64bit issue, I included 64 in the title because that's how I encountered it. TB cannot register itself as default on win7, period. And the excuse for not fixing it is that users can install the old working version first to do the registration and then upgrade to the broken version?

(In reply to Wayne Mery (:wsmwk) from comment #63)

Please look at whether something has block bug before commenting.

Blocks:
bug 1517955, bug 1568550

I guess bug 1517955 should be removed as blocking this bug (1509918) then (see below, and response from bug reporter).

(In reply to Magnus Melin [:mkmelin] from comment #64)

releasing an email client that can't be registered as default by 40% of your potential users is absurd

Thunderbird 32bit is still available and won't be going anywhere for I'd assume 10yrs or more. This bug is strictly for users hanging on to win7 and for unknown reasons want to update to 64 bit Thunderbird even it doesn't make a difference in the program's functionality.

I did not even notice this:
Platform:
x86_64
Windows 7

I guess the "x86_64" should be removed then. I thought it was for all Windows. We have mostly moved beyond Windows 7, so this does not concern me as much. Bummer for the bug reporter though.

Keywords: 64bit
Summary: "use thunderbird as default client" prompt on every startup on WIndows 7 using TB 64bit → thunderbird can't register itself as the default mail app on win7

(In reply to Magnus Melin [:mkmelin] from comment #64)

releasing an email client that can't be registered as default by 40% of your potential users is absurd

This bug is strictly for users hanging on to win7 and for unknown reasons want to update to 64 bit Thunderbird even [if] it doesn't make a difference in the program's functionality.

Let's ask a different question - for win7 users who lack "correct" registry settings, will moving them to 64bit break any functions that are not already broken by this bug?

If the answer is no, then we remove blocking of bug 634233. If the answer is yes, then do we exclude windows 7 from automatic updates to 64bit?

FWIW, I estimate the percentage of Windows users of Thunderbird (on a current version) to be 20-30% win7

Flags: needinfo?(rob)
Flags: needinfo?(mkmelin+mozilla)

I haven't gone trough the bugs lately, but I don't know of any other problems.
I'd think a large portion of the win7 users probably are on 32bit hardware anyway (we could probably get numbers on this). I don't see a benefit in upgrading win7 users to 64bit in general, so IMHO we could well just exclude them from the conversion. Quite frankly, it's not like that is very tested territory...

Flags: needinfo?(mkmelin+mozilla)

(In reply to Magnus Melin [:mkmelin] from comment #70)

I'd think a large portion of the win7 users probably are on 32bit hardware anyway (we could probably get numbers on this).

I would be wary of stating such assumptions.
32 bits hardware is hard to come by these days, and suggesting 20-30% of the otherwise estimated user base runs on (very, very) old hardware resembles IMHO much of a stunt.

If you got telemetry, please do check numbers.
If you don't, please avoid wild theories.

B.

Well, these days yes, but how did they end up with Win7 to begin with? You haven't been able to get that from anywhere for many years.
Anyway, I believe we do have telemetry on this so we could check.
Not sure it makes a difference for what we opt to do here though. What would the argument be for upgrading people on Win7 to 64bit? There isn't much for people on Win10 with 64bit hw either...

Flags: needinfo?(sancus)

(In reply to Wayne Mery (:wsmwk) from comment #69)

If the answer is yes, then do we exclude windows 7 from automatic updates to 64bit?

That should be doable. Does anyone have a Win7 machine to test that though?

Flags: needinfo?(rob)

(In reply to Magnus Melin [:mkmelin] from comment #72)

Anyway, I believe we do have telemetry on this so we could check.

I checked this back in November and just redid it for today, as of Thursday last week here's the breakdown:

OS Nov 2020 Feb 2021
Win10 76.3% 77.4%
Win7 64-bit 11.1% 10.3%
Win7 32-bit 4.2% 3.9%
MacOS 3.6% 3.9%
Win8 3.7% 3.7%
Linux 1% 0.7%
WinXP 0.2% 0.2%
Flags: needinfo?(sancus)

The excuse brought forward not to address this issue but circumvent it, and which needed checking, is whether Windows 7 users are in majority running 32 bits architecture hardware.
Have you got hardware telemetry by any chance?

(In reply to B from comment #75)

The excuse brought forward not to address this issue but circumvent it, and which needed checking, is whether Windows 7 users are in majority running 32 bits architecture hardware.

Sorry, my bad. The comments in this bug are very confusing. If we are talking users on Win7 32-bit only, then it's 3.9% of all. I've updated the table accordingly as well.

(In reply to B from comment #71)

I would be wary of stating such assumptions.
32 bits hardware is hard to come by these days, and suggesting 20-30% of the otherwise estimated user base runs on (very, very) old hardware resembles IMHO much of a stunt.

Per the data above, at the moment 27.5% of win7 users are in this (32bit OS) group.

Can someone explain to me why we're discussing 32-bit vs 64-bit here, and what this has to do with the migration?

According to Comment #65 by the original reporter, this bug occurs on Win7 period regardless of 32/64-bit.

(In reply to Andrei Hajdukewycz [:sancus] from comment #78)

Can someone explain to me why we're discussing 32-bit vs 64-bit here, and what this has to do with the migration?

(In reply to bughit from comment #3)

Did you match os and bitness? win7 x64 sp1, tb 60.3.1 x64

(In reply to Jorg K (CEST = GMT+2) from comment #4)

This is still pointing to the x86 52.9.1 and the set default from x64 60.3.1
does not alter it

Maybe that's a general problem with the 64bit version. Officially, there's
isn't a 64bit version. This may well be an installer bug. Could be related
to bug 1507618.

This is where it came from. There's more, but you can find the rest above.

As has been pointed out, this isn't 64bit specific, so removing bug 634233

No longer blocks: support-win64-thunderbird
Severity: normal → S3

Is this Windows 7 support still being worked on, or should this just get marked as "WONTFIX" once and for all?

(In reply to Worcester12345 from comment #81)

Is this Windows 7 support still being worked on, or should this just get marked as "WONTFIX" once and for all?

If someone wants to submit a patch I believe it would be accepted.

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