539562 - mailto: links should *always* open in a new window for webmail clients

Status: NEW

(Firefox :: General, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

How to reproduce:
1. Make sure you have set a webmail client as your default (I use Gmail)
2. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=539560 and click the " 	
[e-mail]" link (which is a mailto)
3. Notice how the page is replaced with Gmail, instead of opening a new tab with the webmail client in it.

We should always open a new tab for webmail without exception, especially since we can't send them back to the page they were at after they have completed their email writing.

Comment 1

[Mike]

I too have been frustrated at the many emails I've been sending via gmail during my recent Craigslist job hunt.  Time after time, I forget to cmd-click, to open the mailto: link in a new window/tab.

PLEASE add a setting somewhere, in that new webmail emails should open a new tab/window and -never- overwrite what page I am browsing.

Comment 2

[Patrick Hubenthal]

I can reproduce this in FF 56. It appears to be the same issue as https://bugzilla.mozilla.org/show_bug.cgi?id=646552, and although https://bugzilla.mozilla.org/show_bug.cgi?id=526736 is supposedly about Prism, I wonder if it's the same bug as well.

Comment 3

[antishape]

I have this issue, similar not exactly to what is said here, when clicking on mailto-link it doesn't in Thunderbird but shows an error message "Thunderbird already running, can't open" (something like that). It is on Ubuntu 21.04, Firefox 88.0 and TB 78.8.1 (64-Bit).

Comment 5

[Max Christian Pohle [:/dev/max]]

Attachment: Bug 539562 - always open mailto links in a new window, r=gijs,timhuang

This naive fix works for me. I tried it with 'always ask', an
application (notepad.exe), system default (falls back to 'always ask')
and webmailers open in a new tab with it, because openURI is used. It
does not obviously look wrong to me, because the WebHandlerApp.sys.mjs
is cases sensitive to other schemes as well. So what is the deal? Or can
we simply do it like this?

the execution path for win.browserDOMWindow.openURI is:

https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/uriloader/exthandler/WebHandlerApp.sys.mjs#59
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/uriloader/exthandler/WebHandlerApp.sys.mjs#167
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#580
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#529
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#562
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#335
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#339
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#375
https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/mobile/shared/modules/geckoview/GeckoViewNavigation.sys.mjs#400

the execution path for aBrowsingContext.loadURI is more complicated and
I gave up for now, but I think it starts here:

https://searchfox.org/mozilla-central/rev/6d437ba43e7752a85f5731133ee66152b390aa16/browser/components/tabbrowser/content/tabbrowser.js#7401