mailto: links ignore target="_blank" when set to a web protocol handler
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
People
(Reporter: wa84it, Assigned: mpohle)
References
Details
Attachments
(2 files, 1 obsolete file)
Updated•14 years ago
|
Updated•13 years ago
|
Updated•13 years ago
|
Comment 8•12 years ago
|
||
Comment 10•11 years ago
|
||
Comment 11•11 years ago
|
||
Updated•11 years ago
|
Updated•11 years ago
|
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment 15•10 years ago
|
||
Comment 16•9 years ago
|
||
Comment hidden (me-too) |
Comment 18•9 years ago
|
||
Comment 19•9 years ago
|
||
Comment 20•9 years ago
|
||
Comment 21•8 years ago
|
||
Comment 22•8 years ago
|
||
Comment hidden (metoo) |
Comment hidden (metoo) |
Comment hidden (metoo) |
Comment 26•7 years ago
|
||
Comment 27•7 years ago
|
||
Comment 28•6 years ago
|
||
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)
Updated•6 years ago
|
Comment 29•6 years ago
|
||
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)?
Comment 30•6 years ago
|
||
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?
Comment 31•6 years ago
|
||
(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.
Updated•5 years ago
|
Comment 33•5 years ago
|
||
This bug is not fixed in firefox 84.0.2 (64-Bit).
Comment 34•5 years ago
|
||
I'm also using FF 84.0.2 (64-bit) on Ubuntu ... and wondering why this bug is still here ! :D
Comment 35•5 years ago
|
||
(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.
Comment 36•4 years ago
|
||
(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...
Comment 37•4 years ago
|
||
@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
Comment 38•4 years ago
|
||
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 ?
Comment 39•4 years ago
•
|
||
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.
Comment 40•4 years ago
|
||
(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 theclick
or themousedown
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...
Comment 41•4 years ago
•
|
||
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...
Comment 42•4 years ago
|
||
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.
Comment 43•4 years ago
|
||
See bug 1626068 comment 1 and also https://github.com/whatwg/html/issues/5289. I suppose there are quite a few categories of schemes:
- Fetch scheme, does the normal navigation thing
registerProtocolHandler()
registered it- OS registered it
- 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.
Comment 44•4 years ago
|
||
(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...
Comment 46•4 years ago
|
||
(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.
Comment 47•3 years ago
|
||
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.
Updated•3 years ago
|
Comment hidden (metoo) |
Comment hidden (metoo) |
Comment hidden (advocacy) |
Comment hidden (metoo) |
Comment hidden (metoo) |
Comment 54•2 years ago
|
||
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
Comment hidden (me-too) |
Comment hidden (me-too) |
Assignee | ||
Updated•1 year ago
|
Comment hidden (me-too) |
Description
•