When using a mailto link chances are that it doesn't do anything for the user if he doesn't have an email client setup, or didn't setup his webmail to be his default client (ea. gmail as default client in macosx).
What would be the best way to gracefully offer a fallback, kindly asking the user to manually email you?
I could use JS or css to show a message once the link has been clicked:
submit was successful, or if nothing happened please email us manually.
What about using a form with mailto, can I use a redirect page upon success without or with serverside scripting? Is there a way to filter out the success from failure, instead of relying on the user's judgement with the double success/failed message above?
edit: At least what would be the most suitable way of changing a state when a mailto link (or form) has been clicked. Obviously JavaScript or css are options, but can't I simply create a double action link or form submit; mailto and also link to another page (you have submitted/clicked the button')
This article discusses a hack of checking if the window's blur event fired after clicking the mailto. It uses a timeout, so it's not foolproof, but might address most cases. Here's a JavaScript/jQuery example, simplified from the article.
(function($)) {
$('a[href^=mailto]').each(function() {
$(this).click(function() {
var t;
$(window).blur(function() {
// The browser apparently responded, so stop the timeout.
clearTimeout(t);
});
t = setTimeout(function() {
// The browser did not respond after 500ms, so open an alternative URL.
document.location.href = '...';
}, 500);
});
});
})(jQuery);
You cannot detect whether or not a user has an email client setup. So I would suggest you to setup a server-side form for the user to contact you.
Beneath or above this you can provide the user a link explaining him that if he wants to contact you directly through his main e-mail account, he can click this link (this link being a mailto: link).
By providing him two ways of contacting you (webform or e-mail client), you give the user the opportunity to choose which one he wants to use. So it's up to him to realize whether or not he has an e-mail client installed and whether or not he wants to use it.
Use a JavaScript confirm popup to ask the user if they have email setup on their computer.
Related
I am trying to do an API call when the user is trying to close/reload the browser/tab. I don't want to call the API if the user clicks on cancel. I followed JavaScript, browsers, window close - send an AJAX request or run a script on window closing, but it didn't solve my issue. I followed catching beforeunload confirmation canceled? for differentiating between confirm and cancel. I have no idea how to make the API call when the user reloads/closes the browser and not to call the API when user clicks on cancel. I followed JavaScript, browsers, window close - send an AJAX request or run a script on window closing and tried like
For showing alert on reload or close the tab
<script>
window.addEventListener("onbeforeunload", function(evt){
evt.preventDefault()
const string = '';
evt.returnValue = string;
return string;
})
</script>
and on click of cancel, nothing should happen. If the user is forcefully closing the browser or reloading, the API should be called
<script type="module">
import lifecycle from 'https://cdn.rawgit.com/GoogleChromeLabs/page-lifecycle/0.1.1/dist/lifecycle.mjs';
lifecycle.addEventListener('statechange', function(event) {
if (event.originalEvent === 'visibilitychange' && event.newState === 'hidden') {
var URL = "https://api.com/" //url;
var data = '' //payload;
navigator.sendBeacon(URL, data);
}
});
</script>
But it's not happening. Any help is appreciated. Thanks
Your problem is happening because you're using beforeunload to present a prompt.
I can see that you're handling the beforeunload event properly, so you must already be aware that browser vendors have deliberately limited the ability of script authors to do custom stuff when the user wants to leave the page. This is to prevent abuse.
Part of that limitation is that you don't get to find out what the user decides to do. And there will not be any clever workarounds, either. Once you tell the browser to present the beforeunload prompt, you lose all your power. If the user clicks the Okay button (i.e. decides to leave the page), the browser will refuse to run any more of your code.
Presenting the prompt creates a fork in the road that you are prevented from observing. So, put a laser tripwire there instead of a fork:
window.addEventListener("onbeforeunload", function(evt) {
navigator.sendBeacon(url, payload)
})
This is guaranteed to run when the user actually leaves the page, and only when the user actually leaves the page. But, you sacrifice the ability to try to talk the user out of leaving. You can't have it both ways.
You can't always get what you want, but if you try, sometimes you just might find you get what you need. -- The Rolling Stones
I can only think of one way to accomplish what you need, but it requires help from the server. This is not an option for most people (usually because the beacon goes to a third-party analytics provider who won't do this), but I'm including it here for completeness.
before the beforeunload handler returns, fire a beacon message that says "user is maybe leaving the page"
after firing that beacon, and still before returning, set up a document-wide mousemove handler that fires a second beacon message that says "the user is still here" (and also de-registers itself)
return false to present the prompt
modify your server so that it will reconcile these two events after some kind of delay:
if the server receives beacon 1 and then also receives beacon 2 (within some reasonably short time-frame, e.g. 5 minutes), it means the user tried to leave but then changed their mind, and so the server should delete the record of beacon 1
if the server receives beacon 1 but doesn't receive beacon 2 within the time-frame, then it means the user really did leave, and so the server would rewrite the previous beacon datapoint to say "user actually departed"; you wouldn't need to actually write beacon 2 to your datastore
(Or, depending on expected traffic and your infrastructure, maybe the server just holds the beacon 1 datapoint in RAM for the 5 minutes and commits it to your datastore only if beacon 2 never shows up. Or you could write both beacons to the database and then have a different process reconcile the beacons later. The outcome is identical, but they have different performance characteristics and resource requirements.)
P.S.: Never use "URL" (all caps) as a variable name in javascript. "URL" is actually a useful web API, so if you use that exact variable name, you're clobbering a useful ability. It's just like if you did let navigator = 'Henry'. Yes, it will execute without error, but it shadows a useful native capability.
Is there a way to send username and password to a url of a login web page?
For example, if the login web page contains 2 textboxes : user name and password and a login button, is there a way to send to the url the credential in order to go directly to the next page coming after the login?
The url for the login page looks like:
http://[ip address]/jsp/login.xhtml
I tried to send the username and passord as following:
http://[username:password]/[ip address]/jsp/login.xhtml
http://[ip address]/jsp/login.xhtml?[username:password]
If there is a way to do it by sending the command through a batch file?
If it can be done using c# or javascript it is also fine.
The best option is Javascript. It can easily run from a plugin of your browser.
(I'm using 'Custom Javascript for Websites', a chrome plugin: https://chrome.google.com/webstore/detail/custom-javascript-for-web/poakhlngfciodnhlhhgnaaelnpjljija)
Firstly you navigate to the login page and check the source code for the following ID's:
- Username-inputbox
- Password-inputbox
- Submit button
Knowing these things, we can add this to our plugin: (Fill in the id's at the right places)
// First we check if we're on the right page
if (window.location.href == "URL")
{
// Find the ID's of the corresponding inputs
document.getElementById("username").value = "user0";
document.getElementById("password").value = "user0scode";
// Then click the submit button, just as we do
document.getElementById("btnSubmit").click();
}
There is free tool called Fiddler. It monitors/debugs all the traffic on your machine i.e. using browsers or any other medium. You can try capturing the action/request behind the login button using Fiddler, and then mutate the same action/request and you will be able to change the username/password for that action/request.
Download from here, and read this.
I have found that if I use this code:
function emailer() {
return window.open("mailto:someone#gmail.com?subject=whatever it is")
}
emailer();
On a computer with no email client configured, well, it basically doesn't work. In that case I would like to find out if there was an error and paste the text to send into an element in my page and prompt user to paste this message into their email and send to me - in this slightly less convenient way.
How would I detect if there was an error on using mailto?
UPDATE:
I will wait a little longer for responses but it looks like it is not possible. I think I will have to offer simpler alternative every time and make it obvious to user to use this if automated email option fails.
Is it possible to test whether a user's OS/browser supports a given url scheme using javascript (or anything else)?
For example, mailto: isn't setup on most user's computer that only use webmail. Would it be possible to somehow catch attempts to click a mailto link and pop up a more descriptive explanation than the browser error message?
In the general case — I don't think so.
In the specific case of mailto: — no.
To solve the problem you need to describe you need to know if the user has a configured email client, not if the browser supports mailto:. Most browsers support mailto:, and if the user doesn't have a configured client — it still 'works' (by starting the email client and prompting the user to configure it).
Would it be possible to somehow catch attempts to click a mailto link and pop up a more descriptive explanation than the browser error message?
I don't know that you can determine whether a browser supports mailto: links. But as for attaching logic to mailto links, you could cycle through the links on the page, and test their href value. If it begins with "mailto:" you could attach a popup upon clicking it.
var maillinks = document.getElementsByTagName("a");
var (var i = 0; i < maillinks.length; i++) {
var currentlink = maillinks[i];
if (currentlink.href.substring(0,7) === "mailto:") {
alert("Sorry. These aren't allowed.");
return false;
}
}
The only real solution I can think to this problem is to host your own contact page, providing a small form that the user can submit.
I have a web application for which I am trying to use Twitter's OAuth functionality. This application has a link that prompts a user for their Twitter credentials. When a user clicks this link, a new window is opened via JavaScript. This window serves as a dialog. This is accomplished like such:
MainPage:
<div id="promptDiv">Provide Credentials</div>
...
function launchDialog(url) {
var specs = "location=0,menubar=0,status=0,titlebar=0,toolbar=0";
var dialogWindow = window.open(url, "dialog", specs, true);
}
When a user clicks the link, they are redirected to Twitter's site from the prompt.aspx page. On the Twitter site, the user has the option to enter their Twitter credentials. When they have provided their credentials, they are redirected back to my site. This is accomplished through a callback url which can be set for applications on Twitter's site.
When the callback happens, the user is redirected to "/twitter/confirm.aspx" on my site in the dialog window. When this happens I want to update the contents of "promptDiv" to say "You have successfully connected with Twitter" to replace the link and close the dialog. This serves the purpose of notifying the user they have successfully completed this step. I can successfully close the dialog window. However, when I am try to update the HTML DOM, I receive an error that says "Error: Permission denied to get property Window.document". In an attempt to update the HTML DOM, I tried using the following script in "/twitter/confirm.aspx":
// Error is thrown on the first line.
var confirmDiv = window.opener.document.getElementById("confirmDiv");
if (confirmDiv != null)
{
// Update the contents
}
window.close();
I then just tried to read the HTML to see if I could even access the DOM via the following script:
alert(window.opener.document.body.innerHTML);
When I attempted this, I still got a "Permission denied" error. I know this has something to do with cross-site scripting. However, I do not know how to resolve it. How do I fix this problem? Am I structuring my application incorrectly? How do I update the HTML DOM after a user has been redirected back to my site?
Thank you for your help!
When the popup opens the Twitter auth page, you are losing your original ability to communicate with the winodw because its document domain has changed and the window.opener has been reset.
To get around this for SitePen's NetFlix Queued, I used a timer and polled the popup window for changes to its location (which you can continue to access). If it went to an error page or a success page, I knew that and could close the popup (you have control of the window, but not the DOM) and change the content in the main page to reflect the status of authorization.
We also checked for the window closing – in the case of the user not authorizing and closing the popup.
We couldn't make use of the callback because this was done in Adobe AIR, and there was no server to "call back to", which created an extra hurdle.