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?
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.
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.
Happened for users because we used window.open(...) to open that link in new window.
Replaced to window.location.href = ... just for Safari :facepalm:.
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.
<span>link text</span>
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).
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#email.com</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.
Related
It was hard to encapsulate my question in the title.
I've rewritten a personal web page that made extensive use of javascript. I'm simplifying matters (or so I hope).
I use a home automation server that has a REST interface. I can send commands such as 'http://192.168.0.111/rest/nodes/7%2032%20CD%201/cmd/DON to turn on a light. I'm putting links on my simplified web page using an href tag. The problem is that it opens the rest interface page and displays the XML result. I'd like to avoid having that page show up. ie when you click on the link it 'goes' to the link but doesn't change the page.
This seems like it should/would not be possible but I've learned not to underestimate the community.
Any thoughts?
You can use the fetch function if your browser is modern enough:
document.querySelector(lightSelector).addEventListener('click', e => {
e.preventDefault(); // prevent the REST page from opening
fetch(lightURL).then // put promises here
})
The variables lightSelector and lightURL are expected to be defined somewhere.
The code listens for clicks on the link, and when one comes, we prevent the REST page from opening (your intention) then we send a request to your light URL with fetch. You can add some promises to deal with the response (e.g. print "light on" or "light off" for example) using then but that's another matter.
If you make the "link" a button, you can get rid of e.preventDefault(); which is the part preventing the REST page from opening.
I have an application by mean-stack that hosts a website and an Excel add-in. html5 is enabled, and it has
<script src="https://appsforoffice.microsoft.com/lib/1/hosted/office.js"></script>
<script src="https://cdn.rawgit.com/devote/HTML5-History-API/master/history.js"></script>
In the Excel add-in, I have a button that opens a page in the website by Dialog API:
$scope.openDialog = function () {
Office.context.ui.displayDialogAsync("https://localhost:3000/preview/tmp/6wr-4PqdBrYQwjp3AAAD", {}, function () {})
}
When I click on this button in Excel Online in Chrome, it opens a dialog box with the following url (note that # and several %2F are systematically appended), but it does not prevent from well displaying the page.
https://localhost:3000/preview/tmp/6wr-4PqdBrYQwjp3AAAD?_host_Info=excel|web|16.00|en-us|b6f37f78-e519-7d03-0069-b9c4317a362c|isDialog#%2Fpreview%2Ftmp%2F6wr-4PqdBrYQwjp3AAAD%3F_host_Info=excel%7Cweb%7C16.00%7Cen-us%7Cb6f37f78-e519-7d03-0069-b9c4317a362c%7CisDialog
However, when I click on this button in Excel Online in Firefox, the url changes quickly to the following url, which turns out to display the homepage of the website:
https://localhost:3000/home#%2Fpreview%2Ftmp%2F6wr-4PqdBrYQwjp3AAAD%3F_host_Info=excel%7Cweb%7C16.00%7Cen-gb%7C919fff78-e51f-dc20-0c3c-871b7d0ec25d%7CisDialog
So my questions are:
1) Why does Office.context.ui.displayDialogAsync add systematically # and %2F to the url of my website? Is it possible to prevent this from happening?
2) Is it possible to make a url (regardless of # and %2F) that Firefox accept?
Edit 1: It seems that if I don't use html5-history-api, it will work. So does not know how to disable html5-history-api for that displayDialogAsync? (The reason why I have to use html5-history-api after office.js is here.)
It is not displayDialogAsync that is doing this. It is a frequent issue with Angular routing and Angular location strategy. Search for "angular app is adding hash to my urls" and you will find a lot of information about it and solutions.
When using the MediaWiki software, how do you disable the popup saying "Your edit was saved." from appearing?
This feature has been created after A/B testing to provide users a feedback that their edit indeed has been saved. The module providing this functionality was unconditionally loaded, while now it's only loaded if a cookie, was set in EditPage.php. It will trigger a label/popup on the next page loading with action=view (the default action). There was an HTML snippet, while now, HTML is generated by JavaScript mediawiki.action.view.postEdit.js.
2 ways to get rid of it:
As a server administrator (and you'll have to remember to re-install this hack after upgrading): Remove the line loading the module mediawiki.action.view.postEdit - this will possibly save you a few bytes bandwidth, too.
As a site administrator: Hide the message by adding the following to MediaWiki:Common.css:
.postedit {
display: none;
}
When you type in an invalid address, Chrome displays a grey page that says "Oops! Google Chrome could not find X. Did you mean Y?"
Because this is not an HTTP page but rather one of the browser's built-in things, I can't put a content script in it and can't control it, so my extension is frozen until the user manually goes to another page.
Since the extension is supposed to be able to control the browser on its own, it's very important that anytime this page opens, it automatically goes back to a page I do have content script access to, and then displays a message instead.
Is this impossible?
You can use the chrome.webNavigation.onErrorOccurred to detect such errors, and redirect to a different page if you want. Unless you've got an extremely good reason to do so, I strongly recommend against implementing such a feature, because it might break the user's expectations of how the browser behaves.
Nevertheless, sample code:
chrome.webNavigation.onErrorOccurred(function(details) {
if (details.frameId === 0) {
// Main frame
chrome.tabs.update(details.tabId, {
url: chrome.runtime.getURL('error.html?error=' + encodeURIComponent(details.error))
});
}
});
According to the docs the only pages an extension can override are:
The bookmarks manager
The history
The new-tab
So, an extension can't change/contol/affect the behaviour of the browser regarding the "Oops!..." page.
I'm developing an iPhone web app using jQTouch, and it contains a simple mailto: link to a valid email address, which should launch the iPhone mail application when tapped—but it doesn't.
If I visit a "normal" web page in Mobile Safari which contains the exact same link, and tap on it, I get the expected result: the mail app pops up with the correct email address in the To field.
Here's the link HTML (with the address changed) just in case I'm going nuts and have made a stupid mistake, but it appears perfectly fine:
<p>info#mycompany.com</p>
Has anyone come across this when using jQTouch? Or can anyone at least suggest a way that I can debug this? At the moment when I tap the non-working link it flashes red (the active link state) and absolutely nothing else happens.
I found that adding target="_blank" to the links worked -- except that on some desktop browsers, it opened a new blank window AND opened the email window. Granted, jqtouch sites aren't typically going to be viewed on desktop browsers, but I wasn't fond of that behavior.
Instead, here's what I did:
Put the mailto: link in the onclick event and added return false (so actual link to # doesn't fire)
Added a noHighlight class to the link
Here is an example:
Email me
I then modified the CSS in the theme file.
Before:
ul li a.active {
background: #194fdb url(img/selection.png) 0 0 repeat-x;
color: #fff;
}
After:
ul li a.active:not(.noHighlight) {
background: #194fdb url(img/selection.png) 0 0 repeat-x;
color: #fff;
}
The reason I added the noHighlight class is that without it, the button would get highlighted and would "stick" which made the button look like it was still in some active state. To get around the issue, I added the class and modified the CSS as described above.
What the CSS change does is that if the link (inside of a li which is inside of a ul) has the class noHighlight, it will NOT change the background or text color.
Seems to work great now on both desktop and mobile browsers.
I looked again at the example code in the jQTouch demo package and saw that they were adding a target="_blank" attribute to their email link.
I did this to my link, and it began working (popping up the mail client window). However, the link that's in a standard web page works as well, but without the target="_blank" attribute...
I'm puzzled, but adding that attribute seems to solve this problem if your mobile page is using jQTouch.
It works fine just with target="_blank".
For those (like me) who find it annoying to get the "This will open in a new page" popup every time you tap on a mailto or tel link you can do this:
Edit jqtouch.js and go to line 284:
if ($el.attr('target') == '_blank' || $el.attr('rel') == 'external')
Now replace this line by:
if ($el.attr('target') == '_self' || $el.attr('target') == '_blank' || $el.attr('rel') == 'external')
And on the HTML (e.g.):
Call me
becomes
<a target="_self" href="tel:+351912345678">Call me</a>
Excellent find, I'm doing the same thing and couldn't understand why until recently. If you look round line 161 and 284 in jqtouch.js rev 109 you see that the target attribute "_Blank" will keep jqtouch from hijacking your click event. It is intercepting the event because that is the primary mechanism to move from page to page.
This isn't related to jQTouch, but mailto: links weren't working for me either and to fix them, all I had to do was add slashes after the colon.
mailto://info#mycompany.com
Got the idea to do this here: http://mobiledevelopertips.com/cocoa/launching-other-apps-within-an-iphone-application.html. Strangely enough, telephone links worked fine for me without the slashes.