Closed Bug 1577706 Opened 2 months ago Closed Last month

Mailto: links in any browser (Firefox, Chrome, Edge, etc) not launching Thunderbird if configured as default mail client on Windows

Categories

(Toolkit :: Startup and Profile System, defect)

69 Branch
x86_64
Windows 10
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
thunderbird_esr68 69+ fixed
firefox-esr68 70+ fixed
firefox69 --- wontfix
firefox70 --- fixed
firefox71 --- fixed

People

(Reporter: simplafied, Assigned: Gijs)

References

(Regression)

Details

Attachments

(3 files)

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

Steps to reproduce:

Using the 64bit Beta which updated automatically today and now mailto: links in browsers not working. Have reset Windows 10 defaults and set Thunderbird as default Mail client though still not working

Actual results:

Links that previously worked now just create a BUSY cursor icon (round circle) for a few seconds and nothing else.

Expected results:

New mail window should have opened in Thunderbird

I don't see any response when clicking a mailto link or using "Email Link... " from the Firefox Page actions menu.

I just uninstalled the 32-bit version and installed the 64-bit version made it the default during installation and tested it.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Thunderbird/69.0

Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
OS: Unspecified → Windows 10
Product: Thunderbird → MailNews Core
Hardware: Unspecified → x86_64

(In reply to WaltS48 [:walts48] from comment #1)

I don't see any response when clicking a mailto link or using "Email Link... " from the Firefox Page actions menu.

I just uninstalled the 32-bit version and installed the 64-bit version made it the default during installation and tested it.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Thunderbird/69.0

Are you saying you have the same problem or not? It was not clear, mine was working fine, then it auto updates and is now no longer working

I'm confirming I see a problem.

I'm not a Windows expert, but went to Settings > Apps > Default Apps scrolled down to "Set defaults by app".
Clicked that.
Found Thunderbird in the list.
Clicked "Manage" and set the "File type and protocol associations" for "MAILTO" to use Thunderbird.

It still didn't work. Do I need to do a reboot of Windows?

Does "Email Link..." from the Firefox Page actions menu work for you?

Flags: needinfo?(simplafied)

(In reply to WaltS48 [:walts48] from comment #3)

I'm confirming I see a problem.

I'm not a Windows expert, but went to Settings > Apps > Default Apps scrolled down to "Set defaults by app".
Clicked that.
Found Thunderbird in the list.
Clicked "Manage" and set the "File type and protocol associations" for "MAILTO" to use Thunderbird.

It still didn't work. Do I need to do a reboot of Windows?

Does "Email Link..." from the Firefox Page actions menu work for you?

I am in the process of reinstalling Thunderbird now, what Firefox Page do you mean? I am not sure what you are talking about

Flags: needinfo?(simplafied)

I am assuming your Firefox 69.0 is set as the default browser on your system.

Load any web site and try to use "Email link..." from the meatball 3 dot menu in the address bar.

See Page Actions

(In reply to WaltS48 [:walts48] from comment #5)

I am assuming your Firefox 69.0 is set as the default browser on your system.

Load any web site and try to use "Email link..." from the meatball 3 dot menu in the address bar.

See Page Actions

Got it working, though using a work around. I uninstalled Thunderbird, reinstalled 69.0b3 and then turned off Auto Update. Now all links are working fine, is definitely a bug as when I update again it reverts to not working. So basically uninstall, and download 69.0b3 from here and make sure to turn off auto update in options https://archive.mozilla.org/pub/thunderbird/releases/69.0b3/win64/

That's one solution.

FWIW I can not reproduce using TB 69.0b4 on Ubuntu 18.04.3 LTS Linux or TB 68.0 (64-bit) on Windows 10.

I can confirm this using FF 60.8 ESR and Nightly of today and TB 68.1 which has about the same changes that TB 69 beta 4 has, that means, both include bug 1573051 (when as TB 69 beta 3) didn't have that bug. Instead there, mailto links with "fragments" didn't fully work, see bug 1577350.

Toshihito, does this bug also affect the receiving side when launching an external program?

Alice, could you confirm the regression from bug 1573051 on TB truck, best with some older version of FF which doesn't have 1567614 yet (that's when the whole trouble started). This may need some experimenting since both FF and TB are involved.

Flags: needinfo?(tkikuchi)
Flags: needinfo?(alice0775)

Strangely enough, the people testing in bug 1577350 seem to have gotten a compose window, only that the "fragment", so ?subject=xxx&body=yyy was missing.

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

Strangely enough, the people testing in bug 1577350 seem to have gotten a compose window, only that the "fragment", so ?subject=xxx&body=yyy was missing.

Hi, are you referring to mailto: links in emails? I have not actually tested this, I was referring to HTML mailto: links in Firefox / Chrome /Edge, with Thunderbird set as default mail client in Windows 10. I tried reseting Default App preferences, uninstalling/reinstalling, deleting profiles though all have the same error.

In 69.0b3 mailto links in browser work fine and a Thunderbird new mail window opens. However when Thunderbird upgraded to 69.0b4 these suddenly stopped working. I have downgraded back to beta 3 for the meantime.

(In reply to simplafied from comment #10)

Hi, are you referring to mailto: links in emails? I have not actually tested this, I was referring to HTML mailto: links in Firefox / Chrome /Edge, with Thunderbird set as default mail client in Windows 10. I tried reseting Default App preferences, uninstalling/reinstalling, deleting profiles though all have the same error.

The people in bug 1577350 were testing mailto: link on a webpage just like here, I don't know which mail client they were using, hence I asked in bug 1577350 comment #6. I'm well aware of the combination "link in any browser" plus "Thunderbird client" which stopped working in 69 beta 4 and also 68.1 pre-release.

Alice: This will be tricky to bisect since you need to install TB as default mail client. The ZIP technique won't work here, I believe.

Steps:

  1. Start Chromium
  2. Load this bug and logged in
  3. Click any username of a comment and Click Mail

Actual results:
Nothing happens

Expected Results:
Default Thunderbird compose window should open

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=c69de8e90f2204e1e64c373d0336123760fb9f18&tochange=258ad57c7aeb0af843a217aa31582298701efde8
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0dc91d87721bbd95ec2bccd1bfff87f22125ae6d&tochange=2a072a09ae8d05786da6d2466a7ac02e33b0397e

Flags: needinfo?(alice0775)

Hmm, thanks, Alice. This is surprising. Your range is on 21st Aug. The bug was filed for TB 69 beta 4 when TB 69 beta 3 was still working. The difference between the those two beta version is that was added additional changesets from mozilla-beta and comm-beta.

I don't have access to that bug. As was assuming bug 1573051, but I could be wrong.

Gijs, Dave and Matt, could that have broken launching TB on clicking a mailto: link.

Flags: needinfo?(mhowell)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(dtownsend)

Wow, Alice, yes, we had a TB 69 beta build based on FF 69 beta 15 and then moved to FF 69 beta 16 in the last minute. That's the range you gave us:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=66a12ddcf77c6a1548989ced39edf39af78deb80&tochange=91c666707c219c5215117da97cbbec3bf07f42e1

Looks like bug 1572838 was backported to FF 68.1 (?), that's why we're seeing it in TB 68.1 pre-release.
EDIT: Indeed:
8b4ed9c4a3cb0598d10baaee12353f81e54a7c0c Gijs Kruitbosch — Bug 1572838 - stop processing osint in BrowserContentHandler.jsm, r=mossop a=RyanVM
01f6b1c6b4dc8a54b20ff64c578747a753045c7c Gijs Kruitbosch — Bug 1572838 - ensure osint commandline args are passed appropriately, r=mhowell,mossop a=RyanVM

I'll do a try build with that backed out to confirm.

The penny has dropped now. Bug 1572838 is in the regression range from comment #12 for trunk. And then it got backported :-(

Flags: needinfo?(tkikuchi)
Regressed by: 1572838

I bet the problem is the new EnsureCommandLineSafe function, where we check that the command line literally contains -osint -url. Correct assumption for Firefox, but Thunderbird uses -mail or -compose instead of -url.

Flags: needinfo?(mhowell)
Attached file debug log
I'm a bit late for the party.. I confirmed the repro on TB69 and Nightly with any browser (I tried Edge and Firefox). This is not the fragment issue.

The problem is Thunderbird crashed at startup.  Here's what I got.

Ah. We should probably call it from nsBrowserApp I guess.

Flags: needinfo?(dtownsend)

(In reply to Toshihito Kikuchi [:toshi] from comment #20)

I'm a bit late for the party.. I confirmed the repro on TB69 and Nightly
with any browser (I tried Edge and Firefox). This is not the fragment issue.

The problem is Thunderbird crashed at startup. Here's what I got.

Thanks, Toshi. That stack trace shows us calling exit() from EnsureCommandLineSafe(), which I would say confirms my guess. It also shows us crashing while trying to tear down an AsyncLogger, which is not good and should probably be investigated, but the crash is not related to the immediate problem.

I've tested again by making Firefox 68.0.2, 69rc, and 70.0a1 my default browser for separate tests, and as I stated in Comment 7 I can not reproduce this bug using TB 69.0b4 on Ubuntu 18.04.3 LTS Linux.

Mailto links (including Usernames in this bug report) and "Email link..." from the Page actions menu both open the Composition window for TB 69.0b4 from each browser test.

So this is a Windows only problem and a fix won't break Linux?

Thanks to all who have commented. A few remarks:

  1. The crash was reported in bug 1577796. Should I dupe this here? Looks like a "no" reading the end of comment #22.
  2. Can some of the people involved in bug 1572838 fix this quickly (and move it out of MailNews).
  3. I can't ship TB 68.1 with this issue. I assume you're planning to backport to FF 60.9? In this case TB 60.9 would inherit the problem as well. I can fix it with a backout of bug 1572838 from our release branches, but backing out a security fix is likely a bad idea. But if calling it from nsBrowserApp.cpp which is your "main" is an option, TB wouldn't be affected and a backout would be a valid short term fix. Please advise.
  4. Can you give me access to bug 1572838 so I can see what this is about.

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

  1. The crash was reported in bug 1577796. Should I dupe this here? Looks like a "no" reading the end of comment #22.

Matt is right. The crash should be a different issue. I think the root cause of this "not-launching-issue" is that EnsureCommandlineSafe terminates (not crash) the process. And if that happens, the crash happens afterward because xul!sLogModuleManager is not yet initialized.

Sorry, I've just seen this and it's now past midnight here. I'm at a wedding and am not going to be able to write a patch right now.

(In reply to Dave Townsend [:mossop] (he/him) from comment #21)

Ah. We should probably call it from nsBrowserApp I guess.

This is a good idea, but the problem is that we also removed the osint checks elsewhere, and so just not checking anything in TB would potentially reopen security issues for thunderbird w/ mailto: (or Thunderbird<installhash>:) protocol handling.

I expect that we should call it from the integration points of various apps (ie from nsBrowserApp rather than XRE code) but also make the helper function take arguments that list valid params + whether or not they take an argument. That or write a similar checking function in mail code. This would require some work from someone who knows mail code to do it at the right place in mail code...

A slightly more short-term/impromptu (for 68.1 ?) solution might be ifdefs in EnsureCommandlineSafe based on MOZ_BUILD_APP that accept -mail / -compose (with/without params), though that feels pretty yucky.

I can try to get a patch written on my (UK time) Monday, but probably not before then. Keeping needinfo for that. Even then, I likely can't test the mail side of the patch so it'd be helpful if someone who knows mail code could write and/or test the patch.

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

Thanks to all who have commented. A few remarks:

  1. The crash was reported in bug 1577796. Should I dupe this here? Looks like a "no" reading the end of comment #22.

I think "no" is right - we added exit() calls, but those shouldn't crash, per se...

  1. Can some of the people involved in bug 1572838 fix this quickly (and move it out of MailNews).

See above. The patch shouldn't be too difficult to write so if you have time before me.

  1. I can't ship TB 68.1 with this issue. I assume you're planning to backport to FF 60.9?

60esr isn't vulnerable to the issue in the bug as written, so no.

In this case TB 60.9 would inherit the problem as well. I can fix it with a backout of bug 1572838 from our release branches, but backing out a security fix is likely a bad idea. But if calling it from nsBrowserApp.cpp which is your "main" is an option, TB wouldn't be affected and a backout would be a valid short term fix. Please advise.

See above - just backing this out will likely net you the same security issue as Firefox had prior to the patch. Moving to nsBrowserApp without an equivalent check in mail code would do the same.

  1. Can you give me access to bug 1572838 so I can see what this is about.

Someone else seems to have done this.

Apologies for the delay here; I spent most of today figuring out build issues (cf. bug 1578198; the merge required a clobber...).

I'm attaching a patch to make the code here more generic and call it from browser, but even with that patch, we'll need a separate patch to nsMailApp to allow -compose and -mail. It should be obvious from the browser/ changes how to do that.

Flags: needinfo?(gijskruitbosch+bugs)

Thanks Gijs. A wedding in the UK makes me think of https://www.imdb.com/title/tt0109831/ ;-)

That aside, I looked at the patch and of course we can port the part in nsBrowserApp.cpp. What about LauncherProcessWin.cpp. We don't have that. Is that the launcher for e10s?

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

What about LauncherProcessWin.cpp. We don't have that. Is that the launcher for e10s?

It's the launcher process, see https://wiki.mozilla.org/Platform/Integration/InjectEject/Launcher_Process/ . It helps to ensure the DLL blocklist works correctly. I don't think you need to worry about that side of things if you don't have it today. I don't know how serious the type of problem that the launcher process solves is for Thunderbird - depending on the answer to that question it may be worth tackling separately but it is orthogonal to this bug.

Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/47fb3a219a9d
move checks for -url from toolkit into browser code, and make osint sanitizer app-agnostic, r=mossop

Thanks, Gijs! That will get TB rolling again. Can you please request beta uplift for this? I'll take it into our 68 ESR branch.

I'll make the necessary adjustment in our mainline.

Flags: needinfo?(gijskruitbosch+bugs)

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

Thanks, Gijs! That will get TB rolling again. Can you please request beta uplift for this? I'll take it into our 68 ESR branch.

I'll make the necessary adjustment in our mainline.

I'll ask for beta uplift once this makes central. Are you going to use it for your own branch for 69 as well, or is there no beta release off 69 anymore?

Flags: needinfo?(gijskruitbosch+bugs)

No more 69, 70 is next and I try to avoid branches on beta.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Component: Networking → Startup and Profile System
Product: MailNews Core → Toolkit
Version: 69 → 69 Branch
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/446570347623
C-C part: Check osint parameters 'compose' and 'mail'. r=me

Comment on attachment 9089890 [details]
Bug 1577706 - move checks for -url from toolkit into browser code, and make osint sanitizer app-agnostic, r?mhowell,Mossop,froydnj

Beta/Release Uplift Approval Request

  • User impact if declined: Broken TB beta builds (fail to open when clicking mailto: links in other apps)
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: N/A
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a mechanical change that moves some code around so it's called from browser/ instead of toolkit/ code and doesn't break Thunderbird, and it's early in the beta cycle
  • String changes made/needed: Nope
Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9089890 - Flags: approval-mozilla-beta?

Working again in TB 68.1 (pre-release).

Status: RESOLVED → VERIFIED

Comment on attachment 9089890 [details]
Bug 1577706 - move checks for -url from toolkit into browser code, and make osint sanitizer app-agnostic, r?mhowell,Mossop,froydnj

Support for TB builds. I agree it's early in the cycle and we can afford some risk here. OK for uplift for beta 4.

Attachment #9089890 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Thanks, Liz. I fixed TB 68.1 via a backport to our release branch, see comment #39 (and comment #40 for the comm-esr68 part).

Firefox itself is not affected, only Thunderbird with is also built with Mozilla platform code. So a backport to mozilla70 (beta) would help with our beta releases. There's no need to fix any other Firefox releases really.

Summary: Updated to 69.0b4 (64-bit) and now Mailto: links in browser not working → Mailto: links in any browser (Firefox, Chrome, Edge, etc) not launching Thunderbird if configured as default mail client on Windows

Based on discussion in the last few comments, I think we can wontfix for 69. For 68esr, Jorg has uplifted to the TB esr branch, AIUI, so I don't know what we want to do with the flag. Like, it's in the repo, but not in the branches from which we'll release fx 68esr dotreleases, so both "fixed" and "wontfix" seem sort of right and sort of wrong. But (and Jorg can correct me if I'm wrong) I don't think we're desperate to uplift to esr mainline, though I'm happy to fill out an uplift request if that's preferable. What would you like to do?

Flags: needinfo?(lhenry)

If we don't think this issue would affect other builds based off ESR, we could potentially leave it as "wontfix" for ESR68.
On the other hand, we're early in the 68 ESR lifecycle so it seems unlikely to do any harm and might be better to uplift in order to avoid any future problems from the divergence. So, let's try uplift, if you don't object.

Flags: needinfo?(lhenry) → needinfo?(gijskruitbosch+bugs)

Comment on attachment 9089890 [details]
Bug 1577706 - move checks for -url from toolkit into browser code, and make osint sanitizer app-agnostic, r?mhowell,Mossop,froydnj

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Necessary for TB builds, wanting to ensure Firefox ESR stays in sync with what we use for TB
  • User impact if declined: See above
  • Fix Landed on Version: 71, uplifted to 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Has already landed successfully for TB, early in esr cycle, fairly straightforward refactoring
  • String or UUID changes made by this patch: nope
Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9089890 - Flags: approval-mozilla-esr68?

TB 70 beta 1:
https://hg.mozilla.org/releases/comm-beta/rev/c52d9d56b0b21421ef9950c6d2a437812c75af77
comm part, uplift now possible since the uplift to M-B in comment #46.

Comment on attachment 9089890 [details]
Bug 1577706 - move checks for -url from toolkit into browser code, and make osint sanitizer app-agnostic, r?mhowell,Mossop,froydnj

NPOTB for Firefox, makes it easier for the TB folks to stay in sync with ESR68 over its life cycle. Approved for 68.2esr.

Attachment #9089890 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
You need to log in before you can comment on or make changes to this bug.