Safari mailto: "This website has been blocked from automatically composing an email."
Asked Answered
M

6

13

When using Safari (iOS 10.2) and clicking on a mailto link a confirmation prompt is shown with the following message:

"This website has been blocked from automatically composing an email." Ignore / Allow

I'd like to get rid of this on my own site and don't know what to do. It can be reproduce with Safari e.g on any BBC article clicking the mail icon.

Screenshot of dialogue on iPad

My web research brought me to these links:

https://discussions.apple.com/thread/7763735

WillieFromColo Jan 11, 2017 8:25 AM in response to Russ G

Issues with Safari and "This website has been blocked from automatically composing an email."

My research on Google suggests that this Error-type Message started happening in about November with an update to Safari, which likely occurred concurrently with Apple's update to iOS 10.2. As of today (1/11/17) that is the latest version of iOS for iPads and perhaps iPhones, too.

[...]

and

https://developer.apple.com/safari/technology-preview/release-notes/#r15

Release 15 URL Handling

Navigations to tel: and mailto: links now require a user gesture; navigations without a user gesture will show a confirmation prompt

So it seems like a Safari "feature". Does anyone know how to prevent this prompt?

Marmion answered 7/2, 2017 at 9:0 Comment(2)
According to your last quote, use a user gesture. (a button to click, something to scroll...)Forficate
I have a plain html, vanilla javascript and <a hreft='mailto...'> so what can i do to avoid this annoying alert on SafariMinaminabe
U
9

Various third party JavaScript libraries will intercept clicks on a tags in order to prevent navigation briefly while sending data to a server. Typically, they programatically trigger navigation via window.location.replace.

The change in Safari pops the warning when mailto/tel links are triggered in this way.

There was an interaction, but that's usually been stopped with preventDefault, and Safari doesn't care.

If you're using a library that's causing this issue, contact the creator and see if they can update it to skip preventDefault on mailto/tel links.

Ukase answered 1/3, 2017 at 19:50 Comment(9)
Our fallback system for reporting errors uses dynamically generated mailto links, and it would seem that not only preventDefault causes this but also changing the href location after the click but before the event triggers causing this behavior.Contemplative
In my context, this appears to be caused by HTML not by Javascript. The tag in question looks basically like this: <a href="mailto:[email protected]">[email protected]</a>.Freitas
@ChrisPrince correct, the tag is correct, the issue is that event listeners can listen for clicks on that tag, and modify the results so that the href isn't followed by a "user interaction" but instead by the JavaScript changing the window.location after the click is fired.Ukase
I'm nodding. I found a second example that confirms what you say. In another of my websites, I have the same anchor tag/mailto link and it does not cause this behavior in Safari/mobile. So, I'm digging more into your hypothesis. Thanks!Freitas
There is definitely an event listener attached to the anchor tag in my case. Looking into removing it.Freitas
This is being triggered for me by a google tag manager snippet.Omni
@Omni I would bet that it's one of the scripts GTM is loading, rather than GTM itself.Ukase
My problem is this, and like @jmc, it's GTM intercepting it. How can I get around this while still using GTM?Hat
Hey @AllenGingrich - you need to isolate which script GTM is loading that's causing it. GTM itself shouldn't be the cause.Ukase
A
3

Happened for users because we used window.open(...) to open that link in new window.

Replaced to window.location.href = ... just for Safari :facepalm:.

Adze answered 12/12, 2017 at 13:26 Comment(0)
M
2

What i did not mention initially was that we called the mailto from the JavaScript part of out page. We now again tried to solve the issue by changing to a HTML Tag based mailto (with to and subject) and it now somehow works without that dialouge. So i assume this issue solved for myself, but i am open to any hints explaining the reasons. Therefor by now i do not flag this answer as the solution.

Marmion answered 21/2, 2017 at 9:46 Comment(0)
E
1

We got this issue when tracking mailto-Links with Google Tag Manager.

I've found a solution without modifying the dom.

We had activated the trigger type "Click - Just Links" with the option "Wait for tags" with a "Max wait time" of 2000 Milliseconds.

After disabling this option, the message did not show up again. Another solution is to use "Click - All Elements" (this always works).

Eckmann answered 19/6, 2019 at 9:59 Comment(0)
D
0

We have encountered a similar issue - and have identified the issue as being triggered via Google Tag Manager.

Specifically we were triggering the event (in Tag Manager) on all href elements that contained a mailto: prefix. We altered the event to be triggered via a click on a nested <span> element inside the anchor tag.

This allowed both the tracking of the event in Tag Manager and removed the offending user prompt. eg.

<a href="mailto:[email protected]"><span>link text</span></a>
Drawers answered 11/6, 2019 at 6:58 Comment(0)
C
0

None of the solutions in here worked. There was a plugin/script that was attaching itself to click event which was causing this behaviour. I finally used jquery to create the mailto: links with jQuery.

Add emails in html in this manner

<span class="email-link">[email protected]</span>

and add this jquery to transform the <span> to a link

$(function() {
  $( ".email-link" ).each(function( index ) {
    var a = $('<a />');
    var link = $( this ).text();
    a.attr('href', 'mailto:' + link );
    a.text(link);
    $( this ).html(a);
  });
});        

This way you can avoid any external scripts attaching to the mailto link click event.

Countershaft answered 23/11, 2020 at 22:18 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.