I'm looking to implement a warning if the user attempts to leave the order process before it's completed in any fashion other then of course following the payment button.
Something like this:
<script type="text/javascript">
window.onbeforeunload = function(){
return 'You must click "Buy Now" to make payment and finish your order. If you leave now your order will be canceled.';
};
if document.getElementsByClassName('eStore_buy_now_button').onclick = function(){
};
</script>
I'm sure that's detrimentally wrong in a few ways, but it's the best way I can illustrate what I'm trying. And I understand some browsers will display default text instead of the actual warning I've written, that's fine.
A few notes, I'd rather use plain old JS instead of loading up jQuery for just this one simple task. There are no settings on the page so it's a simple leave page or click "Buy Now" operation.
UPDATE:
I assure you it's not for my sake, it's for the user's sake. Although it's explicitly explained (what to do), I think user's are jumping the gun and leaving before the process is truly finished out of an instant gratification, ignore the messages kind of mentality. It's a simple 2-step process, they submit the details for the project and then make payment. For whatever reason they're submitting details and then not following through with payment about 50% of the time. And then they'll follow up "So, are you working on the project or what?" and then I have to explain "You never finished your order." They follow up with a "Whoops, here ya go."
Unfortunately, I would chalk this up as marketing and web design 101. Rule #1, people are dumb. Not to be taken in a rude or pessimistic sense. Basically, the idea is assume everyone is dumb in your design, instruction so that you make something so easy a five-year-old can do it. I totally agree with not holding users hostage. But this page is ONLY reached in the middle of their intended order process that THEY initiate (this page will never be reached in a browsing sort of way). So I think it's a pretty legitimate use case where you're saving a common user mistake from themselves. A demographic of customers that are not tech-savvy, so they honestly need such guidance.
document.querySelector('.eStore_buy_now_button').addEventListener("click", function(){
window.btn_clicked = true; //set btn_clicked to true
});
window.onbeforeunload = function(){
if(!window.btn_clicked){
return 'You must click "Buy Now" to make payment and finish your order. If you leave now your order will be canceled.';
}
};
This will alert the user whenever the page unloads (eg leaving the page) until btn_clicked is set to true.
DEMO: http://jsfiddle.net/DerekL/GSWbB/show/
Don't do it.
There is a fine line in terms of usability - on one hand sometimes I may have intended to place an order but accidentally left the page; on the other hand it could get annoying pretty quickly. When abrowser is set up to save previous session (i.e. reopen tabs on next launch) and one page behaves this way, you'll end up with only that tab re-opened next time (confirmed on Mac Safari), discarding the rest of the tabs. They'll not be buying from you again!
I'd suggest you make it clear to the user by means of inline messages that the order has not been submitted yet and they still need to confirm their action, but if they were to accidentally navigate away you should make it easy to pick up where they left off. Would be fairly trivial to store such info in a cookie so that on subsequent page visits the user would be prompted with "you have an incomplete order for ..., would you like to finish it now?"
As an alternative, you could use rely on an inactivity alert (think of online banking prompting you when your session is about to expire) to bring the user back to the "complete order" page if they get distracted.
If you are certain you want to rely on this event, the answers to this question may provide better insight. Basically, the functionality or its implementation beyond a basic text warning should not be relied onto because of inconsistent (?) implementation across browsers as well as possibility of having it blocked by the user.
Another update:
Prompted by Derek's comment on this approach being used by Gmail etc., I've come across an article suggesting you stick with onunload instead and rely on AJAX calls to save the state of the page - which backs my thoughts on allowing the user to pick up where they left even if the javascript event is never triggered.
Related
I am making a browser game in html, css, and javascript, written in perl. Health and stamina are kept in the server and I use javascript to show the user a live updated count of these stats while the current page is loaded. This works fine, however if the user switches tabs or switches away from the browser and leaves it running in the background, the count value you see when you return does not keep up properly. So when you switch back to the browser, your counter might say 50/100 stamina when you actually have 100/100. So when you do something in the game (loads a new page) the server updates the counter to the true amount because the javascript is just keeping time to show the user a "live" rolling view in the browser.
Is there a way to ensure the javascript counter will continue to function even if the page/tab isn't active or on the forefront? Aside from completely re-writing my game to include continuous live server pushes in what is displayed on the browser to the user?
Say you are playing the game. You see your health and stamina regenerating. You switch to another program for a minute, then return to the game in the browser. You notice your health and stamina have not updated while you were away. But when you perform an action in the game, this value is updated to what it should be because it is tracked internally on the server. This is what I would like to fix. Hope that makes sense!
I have not tried anything to fix this issue yet besides searching the web and ending up on this site without a really "good" answer in sight, so I decided to ask the question.
Continuous server pushes wouldn't work either. Anything in the main event loop like a timer, or events happening when it's out of focus, gets slowed down by the browser to conserve resources. Some mobile browsers will stop it together.
The answer to the question is to change how your app keeps track of these stats.
Now some will say to use WebWorkers to run the timer in a separate thread but this won't solve all your issues. You'd still have a different version of the issue, like if someone restored your webpage from sleep or something along those lines. No background task can survive that.
You mention that you track these stats also on the server. That's convenient, so the most obvious thing you should do is detect when the tab comes back into focus using the Window focus event. You would then make all the calls to the server to fetch the most up-to-date stats and reset the timers based on that fresh data. To stop it from showing stale data while the request is in flight, you might choose to show a loading spinner or something during that period.
Another common way of fixing this is you keep around on each timer increment a var which says when the data last came back (a timestamp). When you leave focus, you detect this with the blur event and store that last timestamp somewhere. Then they come back into focus, you handle the focus event and calculate the difference between the current time and the last recorded time before defocus (blur). You may be able to recalculate from this period what the values should be.
But if your server has this info, it'd be far less error-prone and easy to just ask the server when they refocus.
How can I write a function that will display an alert when the user tries to leave the page?
I've been thinking about a 1px high div at the very top of the website, and when the user hovers it an alert appears, but I can't place it there, the less html code I place for this purpose the better.
Another method I've been thinking of is unload, or beforeunload events, but they seem to be deprecated.
How can I do this?
How can I write a function that will display an alert when the user tries to leave the page?
The only way to do that is to use onbeforeunload, and you get very little control: Basically, you can supply a message which will probably (but only probably*) be shown to the user. The user will get two choices: Go ahead and leave, or stay.
onbeforeunload is a very unusual event. Here's how you hook it:
window.onbeforeunload = function() {
if (youWantToShowAMessage) {
return "The message goes here.";
}
};
Another method I've been thinking of is unload, or beforeunload events, but they seem to be deprecated.
I'm not aware of either of those being deprecated. What you can do in them is very restricted (for good reason), but until there's a replacement, onbeforeunload serves a useful purpose: It lets the web page tell the user they may be losing something (e.g., unsaved work) when they leave. The current mechanism which only allows a message and very, very few other actions is a decent one: It puts the user in control, but lets the page be useful.
* Mozilla has flirted with just showing a generic message, not showing your message.
I was curious if there was a way to detect the user pressing the "stop navigation" button in the browser using javascript (or, even better, jQuery.) For example, if you click a link for a webpage that takes a while to load, you may want to show a spinning loader. But what if the user cancels navigation to the page? Is there anyway to detect that to get rid of the spinning loader that you put?
EDIT: I did a bit more research, and there seems to be an onStop event in javascript but, wouldn't you know it, it only works in internet explorer. If anyone has any other ideas to implement a cross browser solution like onStop, that'd be wonderful, but if not, I'll answer my own question in a few days to close this.
EDIT 2: https://stackoverflow.com/a/16216193 says it's not possible. As do a few other answers.
Alright so, as promised, I'm going to answer my own question.
I've thought about this quite a bit - and I've come up with a solution. I wasn't able to make it work in code (I didn't try too hard), but it should work in theory.
So I thought about the criteria of deciding when a webpage should decide stop was called. I came up with this:
If the script hasn't died after a reasonable amount of time, it can be assumed navigation has been canceled.
Then a jQuery event can be fired on the body or something like that. But what constitutes "a resonable amount of time?" I figured it would be partially based on page render time (fetching images, etc.) to get an idea of how fast the user's internet is. That can be gotten by doing:
var start = new Date();
var time;
$("body").load(function () {
time = new Date() - start;
...
});
Multiply that by a coefficient (maybe 3 or something) and get an approxamate transfer time. (This would have to be adjusted to account for how long it would take for the server to generate the next page, dependent on how dynamic it is.) Then, using this new found time*3 you'd write something like this:
$("a").click(function() { //Anything that could go to another page should filter through here
setInterval(function() {$(document).trigger("navstopped");},time*3);
}
$(document).on("navstopped") {
//Do stuff now that we assume navigation stopped.
}
Assume. That's really all we're doing here. We may have an inconsistent internet connection, fast one minute, slow the next. Server load could be inconsistent too. Maybe it's serving up images like a ninja for this page, but it's hit with a bunch of requests the next, making it generate/serve the next page a bit slower. So we're just assuming that something interrupted the navigation some how, but we are not certain.
Now, of course, this could be used in conjunction with IE's onStop event, but this was really the only cross browser solution I could think of. I wasn't able to get it to work, but maybe some jQuery god may be able to in the future.
Edit before post: Even before I posted this, I had another idea. More browsers support onAbort. If we have a picture that never loads, and the user presses stop, will onAbort be fired? Even if another webpage is loading? It requires testing but that may work too. I like my first idea better though. Although unstable, it is more stable than this cockamamie idea and I realize this could be bad practice.
I am supporting an e-commerce app, which pretty much makes and submits orders.
A user found that if they submit their order, and press back really quickly, they can cause an error condition.
I want to prevent this. When the user clicks submit, I want to bind some kind of event to the browser's back button that instead will redirect them to the Index page. However, after about two hours of Googling (including a few StackOverflow topics), I have not found any clear way of influencing the behavior of the back button.
I briefly attempted to use history.pushState(), but as the HTML 5 documentation mentions, that will not cause a redirect; it merely alters the displayed URL/state.
Similarly, the history.onpopstate event appears unhelpful, because it occurs whenever a state is removed from the history listing; I'm looking for an event that occurs whenever the history listing is traversed backwards.
Question: Does an event for the browser's back button, or at least a way to prevent this particular stupid user trick exist?
You can't listen to the browser back button because it's outside of your reach (it's not part of the DOM).
What you can do is fix the previous page so that it detects if you've used the back button.
Without more information I can't give you any tips on how to achieve that.
Also, an error condition is not necessarily a bad thing. Just make sure it's clear what is happening: the error message should make sense.
Wrong answer...
Instead listen to window.onBeforeUnload and ask the user if he knows what he is doing. Return false if not. This is usually done via a confirm dialogue
I'd like to add an onbeforeunload javascript, asking the user to bookmark the page (there's a small button in the header for that purpose).
The problem is, no matter if they'd like to bookmark it, it's pointless and annoying after running once.
So, what's a generic solution to stop a javascript from running more than once?
Thanks,
Emilia.
EDIT:
Yes, I guess an onload event would be more appropriate?
I don't really want to add "big red buttons"...
Any basic example how a IP validation + script would look like?
I would say it's already a bad idea to use a pop up when the user wants to exit the page even if it is only once, it's annoying and obtrusive. I suggest you place a big button on site itself if you want to call the visitor to an action, bookmarking in this case.
If you still want to though, you should use IP validation and not cookies, cookies are temporal, they can be removed by the user, and visitors will not like to be presented the same suggestion over and over.