I can add some more mystifying information to this. It turns out that for one of my FF profiles, starting TB as the mail handler works as expected, i.e., does not start up the the TB profile manager.

I therefore copied the mimeTypes.rdf file from the good profile to an offending one. But, to my surprise, that did not fix the problem.

So, I am still going to need some more info about exactly what FF does when it wants to start up the mail handler.

For the most part, all my profiles have similar extensions installed, but it is also always possible that the problem is caused by some extension.

However, starting a FF profile without any extensions still causes the TB profile manager to run when I invoke "email link."

Does the same problem occur with a plain email address link (no subject line or body being sent), or is it only with Email Link?

When I use Firefox 44 to Email Link on this page to a webmail site, it passes this:

mailto:?body=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fquestions%2F1108691&subject=Exactly%20what%20args%20does%20FF%20send%20to%20default%20mail%20handler%3F%20%7C%20Thunderbird%20Support%20Forum%20%7C%20Mozilla%20Support

It's more difficult to tell what it is sending to an external mail client, or should I say, I don't know how to figure that out.

If Thunderbird is your default mail client, could you check the value in the Windows registry under:

HKEY_CLASSES_ROOT\mailto\shell\open\command

Does that match the other keys you checked?

Thanks for the help.

Yes, the same problem occurs with a vanilla 'mailto' link, such as the one found here as "example" in the 2nd line of text: http://kb.mozillazine.org/Changing_the_mail_program_used_in_Firefox

I did check HKEY_CLASSES_ROOT\mailto\shell\open\command and it does match the other command mentioned in my post. Its value is:

"C:\pctools\Mozilla\Thunderbird\v38.4.0\thunderbird.exe" -osint -compose "%1"

As for the arg you give, that makes perfect sense to me, but apparently there can be issues with spaces and various kinds of quotes.

However, I also am mystified by the following thing I did. I created a copy of the working correctly FF profile by copying the good profile lock stock and barrel into the new profile. Nevertheless, the new identical profile did not work right. The only difference I can see is that the default profile is started as 'default' in profiles.ini, while the new one is started with the -no-remote switch.

It occurred to me that I could capture what args FF is sending to the default mail handler by changing the mail handler to some other prog or bat file that would just print out its arg.

I did attempt to change the handler in HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Mozilla Thunderbird\Protocols\mailto\shell\open\command to something else, in particular emacs, but it had no effect (it still ran TB), so it's not clear to me how the handler is being selected, either. Maybe I instead need to change the mailto in HKCR, but changing the TB command you would think would change the command that is run.

Unfortunately, windows is very opaque about what happens in these situations, or what the UI config changes you can make actually do to what occurs at command level when you run something.

I think I now understand more about my problem.

First, I realized that I can see what the command line was to TB by simply using Process Explore or Process Hacker. It turns out that the command line is identical in the winning and losing cases!

I also determined that I can make (at least some of the) FF profiles (that I checked) work, simply by starting them WITHOUT the "-no-remote" switch.

I find it hard to believe that TB can detect that, and it's unclear to me what else FF might be doing to change TB's behavior. I'm just wondering if there might be some global variable (presumably in the registry or ENV) that is being shared between them.

So, at this stage, the question is no longer what the args are, but the more obscure question of what is causing this interaction between FF and TB.

Perhaps the -no-remote switch on Firefox is preventing Firefox from sharing your existing Thunderbird session when launching Thunderbird??

jscher2000 said

Perhaps the -no-remote switch on Firefox is preventing Firefox from sharing your existing Thunderbird session when launching Thunderbird??

Well, apparently, but either that is a tautology, or I don't understand what you mean by "sharing"?

I mean, as I understand it, FF just hands off the arg it wants to windows, which runs TB with that arg as per the registry entry(ies), OR FF examines the registry entries and runs TB. (I could check which, probably, but I doubt that it matters.)

Regardless, I can tell that TB, as far as its command line is concerned, is being started identically in both cases. So, unless there is another avenue of communication, the result should be identical. But, it's not.

To be clear, when TB is started with the same command, it simply runs TB, who then decides whether it already has a session going or not, and whether to enter its profile manager. Probably the code is identical to FF's code for doing the same thing. So, it's up to TB to decide what to do, and the command line told it the identical thing, so maybe it checks some other registry value I don't know about, or maybe FF puts something into an ENV variable that I don't know about for the shell that starts TB.

Ok, I have found the source of the problem. It is an ENV variable. I am not sure whether this is a FF bug or a TB bug. I'm inclined to say it's a FF bug. (Or maybe code they share.)

Here is the problem. When FF is started with the "-no-remote" option, when it runs the email program it wants to run, it starts a shell in which it first sets the env variable "MOZ_NO_REMOTE=1". Unfortunately, TB apparently uses the same ENV variable for the same purpose. The consequence is that TB thinks it is supposed to start up a separate incarnation, and a different profile is required for that, so it starts the TB profile manager.

My solution for the moment is to change FF's mail handler in the options to a small bat file I wrote which first unsets the MOZ_NO_REMOTE env variable before running TB. This creates some problems handling arguments, because the windows cmd shell is a total kludge. A better solution would be to do the unset in the command that is stated in the registry keys. Or, to write and compile an actual program that does that and can therefore be reasonably decent about the args. Maybe I'll try one of those one of these days.

I should add that there is a mozilla bug for this problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1100900

Too bad I did not find that bug 9 hours ago.

If anyone comes across this and is brave enough to diddle the registry, here is the most effective way I found to fix this problem.

First, it turns out that the version of FF that I am using consults the following registry key to decide what to run to send an email:

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

(There are two other similar registry keys that it appears to ignore.)

When you have made TB your default email handler, the above key gets set to:

"<path>\thunderbird.exe" -osint -compose "%1"

where the quotes are in the key value, and <path> represents the path to your TB executable.

In order to reset the MOZ_NO_REMOTE env variable before running TB, it is sufficient to change the above registry key as follows:

cmd /c set MOZ_NO_REMOTE=&"<path>\thunderbird.exe" -osint -compose "%1"

Note that what I did was prepend 'cmd /c set MOZ_NO_REMOTE=&' to the existing key value (without the single quotes). There must be no spaces in 'MOZ_NO_REMOTE=&' and no spaces after the '&'.

The '&' concatenates the two commands, running them in a cmd shell that first resets the offending env variable. An unfortunate consquence of that is that a (usually black) cmd shell window opens briefly.