Open Bug 646552 Opened 14 years ago Updated 7 days ago

mailto: links ignore target="_blank" when set to a web protocol handler

Categories

(Core :: DOM: Navigation, defect, P3)

74 Branch
defect

Tracking

()

REOPENED

People

(Reporter: wa84it, Assigned: mpohle)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 A mailto: link with attribute target="_blank" opens in the current frame/window. This is a problem as the current frame/window may not allow Javascript which some web mail handlers(at least Gmail) require. As an example: the NewsFox extension has this problem with its mailto: of links from a frame where Javascript is not allowed, and can never be allowed according to addon.mozilla.org editors. Reproducible: Always
Attached file testcase
Version: unspecified → 4.0 Branch
I don't think that target="_blank" is the issue here, Firefox should regardless open a new tab on mailto: with mailto handler set to a webmail application in Options > Applications. You can bump up the version number as well, as this is still an issue in Fx7beta.
Attached file mailto links should open in a new tab (obsolete) —
Turns out there is another issue here as well, as the page you click the mailto link on will be gone from back-forward history in the tab. Adding an example.
Attachment #556605 - Attachment mime type: text/plain → text/html
Comment on attachment 556605 [details] mailto links should open in a new tab <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title></title> </head> <body> <ol> <li>Open this page in a new tab to make sure that there is no back-forward history for this tab <li>Set a webmail provider, eg. gmail, to handle mailto links in Options > Applications <li>Click this <a href="mailto:test@example.com">mailto link</a> </ol> <p>Pass if gmail opens in a new tab</p> <ol> <li>If gmail opens in current tab, which is a fail, go back in history to this page using the Back button <li>click the mailto link above once again <p>Pass if this page is in the back-forward history for this tab after last step</p>
Attachment #556605 - Attachment is obsolete: true
Attachment #556612 - Attachment mime type: text/plain → text/html
(In reply to heraldo from comment #3) > Created attachment 556605 [details] > mailto links should open in a new tab > > Turns out there is another issue here as well, as the page you click the > mailto link on will be gone from back-forward history in the tab. Adding an > example. This is bug#499527.
Thanks R Pruitt, would you be so kind and delete comment nr. 4 for me? I messed up a bit, thought i could edit the attachment directly..
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → Windows 7
Version: 4.0 Branch → 17 Branch
Is this issue expected to be resolved. It seems that target="_blank" should be respected particularly with mailto: links.
This is particularly bad with respect to user experience; most sites use a mailto: in order to allow the user to contact the webmaster. This bug will be seen a lot. One of a designer's goals is to keep the user on the site as long as possible (time is money); in the case of a 404 or another error where there's already a certain level of frustration for the user, this problem compounded by the inability to use history to go back to the site elevates that frustration and can cause visitors to abandon the site. Hopefully this can be fixed in the near future.
Firefox 30.0 - I can't get it to respect *ANY* "_blank" links - let alone "mailto".
Same problem in FF 31 Mac. mailto link ignores target="_blank" and previous (page with the mailto) is missing from browser history when pressing back button.
Flags: qe-verify?
Flags: firefox-backlog+
Points: --- → 8
Depends on: 1116478
Voting for a fix although I think this is a significant issue. Especially after the user sends the email they remain on a blank Gmail page? This effectively kills the opportunity to engage the user any more on our sites.
This issue is nerly 5 years old. Opening the link in the same window kills the usage in web-apps. I'm also voting for a fix. Please!
Please do something to fix this bug of _blank mailto links opening in _self tab !!
This is an especially bad bug since it kills history as well. Please fix.
+1 I work on an interactive web app (chat, group annotations, etc). We are trying to use mailto with target="_blank" to allow people to share an email link to their session, but obviously leaving the webapp to do so is horrible user experience! I feel like this is a serious issue, and would love a fix.
+1 requesting attention. Horrible that this bug has existed for 6 years+ and has not been handled. Whenever we offer a mailto: link to our visitors, we are making it horrible to click for FF users, of whom there are many in our target audience.
I can reproduce this in FF 56. It appears to be the same issue as https://bugzilla.mozilla.org/show_bug.cgi?id=539562, 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.
Triage pls. Unless... Is there a reason why such feature appears abandoned in time?
Flags: needinfo?(mstriemer)
I would say that if this problem is still reproducible it should be fixed, maybe in the way suggested by bug 539562. At this time, however, we don't have a team working on the File Handling component, so it's unlikely to be fixed in the short term.
Flags: needinfo?(mstriemer)
Priority: -- → P3

until it is fixed one can use

window.open('mailto:....

or

data:text/html,<meta http-equiv='refresh' content='10;URL=mailto:gdewilde@gmail.com' />

(you can hate me later)

OS: Windows 7 → All
Hardware: x86 → All
Version: 17 Branch → 74 Branch

The ticket got qe-verify? set 5 years ago. Any chance to get this out of backlog (if firefox-backlog+ still means anything - https://groups.google.com/forum/#!topic/firefox-dev/6mFFmxCGDzo)?

Something's off with the priorities assigned to bugs…

This is a 9-year old bug. Its "Type" is (appropriately) set to "defect".

But its priority is set to P3 = "This isn't a bad idea, and maybe we'll want to implement it at some point in the future, but it's not near-term roadmap material. Some core Bugzilla developer may work on it."

If fixing defects is not a priority, what is?

(In reply to fabien.snauwaert from comment #30)

But its priority is set to P3 = "This isn't a bad idea, and maybe we'll want to implement it at some point in the future, but it's not near-term roadmap material. Some core Bugzilla developer may work on it."

If fixing defects is not a priority, what is?

That P3 you found is for developers of bugzilla, not used in this instance of bugzilla which is for mozilla products.
The P3 for mozilla products means the bug is in the backlog.
That means... It may be done... when more priority bugs are dealt with and it won't be handled in the current sprint.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

This bug is not fixed in firefox 84.0.2 (64-Bit).

I'm also using FF 84.0.2 (64-bit) on Ubuntu ... and wondering why this bug is still here ! :D

(In reply to roy.nico from comment #34)

I'm also using FF 84.0.2 (64-bit) on Ubuntu ... and wondering why this bug is still here ! :D

True. It doesn't sound to hard to handle. We would really appreciate if this would get fixed, since it would change the whole handling and process of our webmailer.

(In reply to Erik Krause from comment #33)

This bug is not fixed in firefox 84.0.2 (64-Bit).

Same here. Still not fixed...

@Krejouche and others, I just tested it and it works for me in current Firefox 86 as well as in Nightly. I tested it here: https://codepen.io/scheinercc/full/VwmJqQP

Hello.
Thanks for looking into this. I can confirm that it works for me too on your codepen.
But weirdly enough, it will not work on my website, and I don't understand were the difference is... http://degaudemar.fr/contact.html
Just in case, would you have any clue ?

Anne, Gijs, there is something weird going on. Do you mind having a look if the ticket needs to be reopened?

For some reason the target="_blank" seems to work on this pen: https://codepen.io/scheinercc/full/VwmJqQP (I don't think the click or the mousedown on the iframe's html element have anything to do with it, but might be wrong) ...

... but it does not work on Krejouche's page: http://degaudemar.fr/contact.html

... nor on my example page, where I took the code from the pen and uploaded it somewhere else: https://scheiner.cc/email-test.html

It does also not work for me with the test case attached to the ticket.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(annevk)

(In reply to Albert Scheiner [:alberts] from comment #39)

For some reason the target="_blank" seems to work on this pen: https://codepen.io/scheinercc/full/VwmJqQP (I don't think the click or the mousedown on the iframe's html element have anything to do with it, but might be wrong) ...

It works because it's in a frame and because we refuse to open the link in the same (sub)frame. The other pages where it doesn't work aren't in frames so we don't correct the target from within the web protocol handling code.

The web protocol handling code assumes that the target browsing context it gets given is correct. It seems like here, the docshell code should be giving it a different browsing context for the _blank link, but presumably we don't want to do that for all external protocols because if they're not going to be handled in Firefox, what's the point - we would just open a blank tab for no reason at all.

I don't know what the best solution here is. Hopefully :nika has some idea. Maybe we should pass some kind of bool for "open this in a blank context" to the file handling code? That feels yucky, but OTOH it is clear that docshell cannot pass a browsing context that doesn't exist...

Severity: normal → --
Status: RESOLVED → REOPENED
Points: 8 → ---
Component: File Handling → DOM: Navigation
Flags: needinfo?(nika)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(annevk)
Priority: P3 → --
Product: Firefox → Core
Resolution: DUPLICATE → ---
Summary: mailto: links ignore target="_blank" → mailto: links ignore target="_blank" when set to a web protocol handler

Actually, maybe my clearing Anne's needinfo was premature - are there spec conversations about always assuming _blank for web-handled (known, rather than web+) protocol links? That would also fix this...

Flags: needinfo?(annevk)

I can confirm that all my websites which have been waiting years for this fix still do not open in a new tab or window when Firefox is set to use gmail as it's default email.

See bug 1626068 comment 1 and also https://github.com/whatwg/html/issues/5289. I suppose there are quite a few categories of schemes:

  1. Fetch scheme, does the normal navigation thing
  2. registerProtocolHandler() registered it
  3. OS registered it
  4. Other

For anything but 1 I think we should a) not navigate the current document away b) not let the current document get a handle to what was openened (at best it would get something that's closed). That is, mailto: which translates to https: should behave equivalently to a mailto: that does not. The latter results in another OS application to be opened and the former would result in a new tab or window within the browser, but the document that contained the mailto: URL isn't able to observe the difference.

The standards discussion is in https://github.com/whatwg/html/issues/5289.

Flags: needinfo?(annevk)

(In reply to Anne (:annevk) from comment #43)

The standards discussion is in https://github.com/whatwg/html/issues/5289.

I left a comment there, but always sending web+ or ext+ schemes to _blank effectively re-breaks the usecase specified at https://bugzilla.mozilla.org/show_bug.cgi?id=1196151#c0 . I assume we don't want to do that, but perhaps I'm missing some rationale. Let's continue the discussion on the standards ticket, I guess...

P3

Severity: -- → S3
Priority: -- → P3

(In reply to :Gijs (he/him) from comment #40)

I don't know what the best solution here is. Hopefully :nika has some idea. Maybe we should pass some kind of bool for "open this in a blank context" to the file handling code? That feels yucky, but OTOH it is clear that docshell cannot pass a browsing context that doesn't exist...

One option would be to, instead of passing a BrowsingContext through nsExternalHelperAppService, nsIContentDispatchChooser and friends we could pass a new interface (nsINavigationTargetInfo? I'm not great at names) which records both BrowsingContext openerBrowsingContext and AString target, which could then be passed back into loadURI to ensure that the target is configured correctly when navigating. Just passing a boolean down with "is the navigation target a different window" would probably be fine as well.

Flags: needinfo?(nika)

The severity field for this bug is relatively low, S3. However, the bug has 27 votes.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)
Flags: needinfo?(htsai)

Changing qe-verify? to qe-verify+.

Flags: qe-verify? → qe-verify+

If it can helps someone This is working for me
<a onClick="javascript:window.open('mailto:mail@domain.com', 'mail');event.preventDefault()" href="mailto:mail@domain.com">Send a e-mail</a>
Here

See Also: → 539562
Assignee: nobody → mpohle
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: