Suppose I have a page open in a browser and I go to my address bar and enter another page. Then I hit the back button to go to my original page. I'd like to write some Javascript code that can detect this scenario and respond to it.
As best I can tell neither the ready event, the onload, nor any inline Javascript on the page itself is re-executed in this scenario. Is there anything else I can do?
Cross-browser support is important here. jQuery based solutions preferred but not required.
Edit for clarity: the navigation I'm assuming is Page A -> Page B -> back to page A where I'm assuming that Page B may or may not be under my control.
You should try to give the user a cookie on both pages, the navigated to page and the page itself, with dates and times and compare see if they're close, or if they show that he's been on one page, been on another, and then redirected.
Another option is to give the user a cookie when he is redirected
In Firefox, you can check for the DomContentLoaded event. For a cross-browser solution, a little more work is required:
http://dean.edwards.name/weblog/2005/09/busted/
Related
Hi I'm wondering if there is a way to give window.history.go(-1) a default back page? If you enter a page directly from another site and someone clicks the back button, I don't want to direct them back to the referring site, I'd rather redirect them back to a search page within my application. I notice on some sites they are somehow reading the previous session, is that an option or no? Thanks
may be try something like this:
Back
I think you might be interested in the window onbeforeunload event.
Have a look at this thread: using onbeforeunload event, url change on selecting stay on this page
I am trying a new functionality for my web site. I want to do simple navigation by hiding/showing <div> elements.
For example, when a user clicks a "details" button on some product, I want to hide the main <div> and show the <div> containing the details for the product.
The problem is that to go back to the previous "page", I have to undo all the display/visibility style changes, which is ok if the user clicks the "close" button in the newly opened <div>. But most users will hit the BACK button.
Is there a way to make the BACK button go back to the previous "state" of the page i.e., undo the visibility/display changes?
Thanks.
Yes. What you're looking for is called AJAX browser history.
There are a few open implementations out there, like RSH as well as plugins/modules for frameworks like jQuery and YUI.
to answer the question of your title (that's what I was looking for)
Using the BACK button to revert to the previous state of the page
and from the link from #reach4thelasers's answer, you have to set up a timer and check again and again the current anchor:
//On load page, init the timer which check if the there are anchor changes each 300 ms
$().ready(function(){
setInterval("checkAnchor()", 300);
});
because there's no Javascript callback triggered when the BACK button is pressed and only the anchor is changed ...
--
by the way, the pattern you're talking about is now known as Single Page Interface !
You need to add an anchor to the URL whenever a change is made
www.site.com/page.html#anchor1
This will allow the browser to maintain the pages in its history. I implemented it in my current site after following this tutorial, which works great and gives you a good understanding of what you need to do:
http://yensdesign.com/2008/11/creating-ajax-websites-based-on-anchor-navigation/
Your example in the comments won't work, because it works like this:
Page Loaded
Page Changed, Add Anchor to URL (back button takes you back to back to 1)
Page Changed, Anchor Changed (back button button takes you back to 2)
Page Changed, Anchor Changed (back button button takes you back to 3)
.... and so on and so on..
If there is, it sounds like a pretty evil thing to do from a UX perspective. Why don't you design a "back" button into your application, and use design to make it obvious to the user that they should use your application's back button instead of the browser.
By "use design," I mean make your application look like a self-sufficient user interface inside of the browser, so the user's eye stays within your page, and not up on the browser chrome, when they are looking for controls to interact with your app.
You can do this with anchors, which is how it's done in a lot of flash applications, or other apps that don't go from page to page. Facebook uses this technique pretty liberally. Each time the user clicks on a link that should go in their history, change the anchor on the page.
So say my home page link is:
http://www.mysite.com/#homepage
For the link that works your javascript magic, do this:
My Other Page
This will send the user to http://www.mysite.com/#otherpage where clicking the back button will go back to http://www.mysite.com/#homepage. Then you just have to read the anchors with
window.location.hash
to figure out which page you're supposed to be on.
Take a look to this tutorial based on ItsNat a Java web framework focused on Single Page Interface web sites
A website contains a "random" link, which loads a url that returns a 307 redirecting to the url we want. It works fine: click it and you load a random page. The problem is that each time you click it, the browser assumes you're loading the same page: so if you're on the homepage, then you follow the random link 5 times, then you press back, you'll be taken all the way back to the homepage, with no way to find the random pages you were just looking at. I want to modify this behavior so that users can access previous random pages via the back and forward buttons.
I don't own the website, so I can't just change the redirect code.
Here's what I've tried, all of which has failed.
Predicting what would be redirected to. While somewhat possible, there would be no way to avoid failure in up to .1% of clicks, and it would react very poorly to unexpected events, like a page that's published a day late, let alone a sit structure change.
Loading the 307 page via ajax. The request stops at readystate == 2 and I can't access the location header.
Cancel the click event and instead set location.href = random_link.href. This has no effect - the new page still doesn't go into history.
Have the new page call history.pushState. This successfully adds the page to history, but I can't find a way to distinguish between new pages and ones being opened via the back button, so the history quickly becomes very corrupted.
Keeping my own history in localStorage. As above, I can't tell when the back button is being used.
I'm working on a solution that I'm pretty sure will work, involving loading the page in an iframe over the existing page and using a background process and messaging to work around the fact that content injections from chrome extensions can't access window.parent from within iframes. And using the history API to reflect the current iframe's URL in the address bar, and get the back and forwards buttons to apply to the current iframe where appropriate.
While I'm pretty sure the last solution can be made to work, it's a hideously complex and heavyweight approach to what seems like a simple problem. So I thought I'd ask you guys before I continue: any other ideas?
Have you tried storing the locations in localStorage, then hi-jacking the back button ?
I am sure you know how localStorage works, for hi-jacking the back button you can refer to this : Is there a way to catch the back button event in javascript?
T.
i want to know is there any way we can know browser's events.. like : clicking on BACK button, FORWARD button, REFRESH button by javascript.
These specific browser events are not available as it would be vulnerable to severe privacy violations. Privacy is something browser vendors hold sacred and a key selling (proverbial) point. All browsers allow you to know is when a user enters or leaves your page for which Kamui pointed out the technical details.
Within the same site, it's possible to achieve some browser event tracking using cookies and javascript. For example track wether users click on a hyperlink and label it as a forward event and when a user leaves the page without clicking on a hyperlink it could be one of:
browser url input
back action
javascript location.href replace
The location.href replace can be tracked as well when you have full control over all javascript, just use a helper method with tracking code instead of directly chaning location.href.
That leaves browser url input and the back action. With cookies and request headers (getting the referrer) it is possible to get close to finding out the forward and back events, though not 100%, but pragmatically, 99% sure is good enough.
Figuring out the refresh event is easy with request headers (referrer), if the current url matches the referrrer, it's a refresh event.
Now I offer no code or definite solution, but I outlined what you could do to track back, forward and refresh events within a single domain context. It won't be a quick and easy way to implement it and as far as I know, there's no framework in existance that reliably tracks browser events or even comes close to what I described above.
A more common/lazy technique to achieve something similar is to create a single page app, for which there are many frameworks available. Just google single page app framework, but thats a pretty heavy solution with other implications that I won't go into now.
You can not capture (for example run some piece of code when user presses Back button) them, however, you can direct your pages in history by using:
history.go
history.back
history.forward
More about JS History object.
As #sarfraz says you cannot capture the back and forward button clicks but you could call
window.onbeforeunload = function(){alert("you just tried to leave the page");};
which should be triggered when either the back/forward/refresh buttons are clicked to perform an action, unfortunately you can't tell if they are going back or forward. Please note don't alert a message it's really annoying when trying to exit a page.
EDIT
you can also do this in jQuery if you have it
$(window).unload( function () { alert("Bye now!"); } );
Once the user is on my page, I do not want him to refresh the page.
Anytime, the user hits F5 or refresh button on top. He should get an alert saying
You cannot refresh the page.
Also if the user opens a new tab and tries to access the same url in prev tab he should get an alert
You cannot open same page in 2 tabs
Anyway I can do this using JavaScript or jQuery? Point one is really important.
#1 can be implemented via window.onbeforeunload.
For example:
<script type="text/javascript">
window.onbeforeunload = function() {
return "Dude, are you sure you want to leave? Think of the kittens!";
}
</script>
The user will be prompted with the message, and given an option to stay on the page or continue on their way. This is becoming more common. Stack Overflow does this if you try to navigate away from a page while you are typing a post. You can't completely stop the user from reloading, but you can make it sound real scary if they do.
#2 is more or less impossible. Even if you tracked sessions and user logins, you still wouldn't be able to guarantee that you were detecting a second tab correctly. For example, maybe I have one window open, then close it. Now I open a new window. You would likely detect that as a second tab, even though I already closed the first one. Now your user can't access the first window because they closed it, and they can't access the second window because you're denying them.
In fact, my bank's online system tries real hard to do #2, and the situation described above happens all the time. I usually have to wait until the server-side session expires before I can use the banking system again.
You can't prevent the user from refreshing, nor should you really be trying. You should go back to why you need this solution, what's the root problem here?. Start there and find a different way to go about solving the problem. Perhaps is you elaborated on why you think you need to do this it would help in finding such a solution.
Breaking fundamental browser features is never a good idea, over 99.999999999% of the internet works and refreshes with F5, this is an expectation of the user, one you shouldn't break.
Although its not a good idea to disable F5 key you can do it in JQuery as below.
<script type="text/javascript">
function disableF5(e) { if ((e.which || e.keyCode) == 116 || (e.which || e.keyCode) == 82) e.preventDefault(); };
$(document).ready(function(){
$(document).on("keydown", disableF5);
});
</script>
Hope this will help!
Back in the ole days of CGI we had many forms that would trigger various backend actions. Such as text notifications to groups, print jobs, farming of data, etc.
If the user was on a page that was saying "Please wait... Performing some HUGE job that could take some time.". They were more likely to hit REFRESH and this would be BAD!
WHY? Because it would trigger more slow jobs and eventually bog down the whole thing.
The solution?
Allow them to do their form.
When they submit their form... Start your job and then direct them to another page that tells them to wait.
Where the page in the middle actually held the form data that was needed to start the job.
The WAIT page however contains a javascript history destroy. So they can RELOAD that wait page all they want and it will never trigger the original job to start in the background as that WAIT page only contains the form data needed for the WAIT itself.
Hope that makes sense.
The history destroy function also prevented them from clicking BACK and then refreshing as well.
It was very seamless and worked great for MANY MANY years until the non-profit was wound down.
Example:
FORM ENTRY - Collect all their info and when submitted, this triggers your backend job.
RESPONSE from form entry - Returns HTML that performs a redirect to your static wait page and/or POST/GET to another form (the WAIT page).
WAIT PAGE - Only contains FORM data related to wait page as well as javascript to destroy the most recent history. Like (-1 OR -2) to only destroy the most recent pages, but still allows them to go back to their original FORM entry page.
Once they are at your WAIT page, they can click REFRESH as much as they want and it will never spawn the original FORM job on the backend. Instead, your WAIT page should embrace a META timed refresh itself so it can always check on the status of their job. When their job is completed, they are redirected away from the wait page to whereever you wish.
If they do manually REFRESH... They are simply adding one more check of their job status in there.
Hope that helps. Good luck.
No, there isn't.
I'm pretty sure there is no way to intercept a click on the refresh button from JS, and even if there was, JS can be turned off.
You should probably step back from your X (preventing refreshing) and find a different solution to Y (whatever that might be).
Issue #2 now can be solved using BroadcastAPI.
At the moment it's only available in Chrome, Firefox, and Opera.
var bc = new BroadcastChannel('test_channel');
bc.onmessage = function (ev) {
if(ev.data && ev.data.url===window.location.href){
alert('You cannot open the same page in 2 tabs');
}
}
bc.postMessage(window.location.href);
Number (2) is possible by using a socket implementation (like websocket, socket.io, etc.) with a custom heartbeat for each session the user is engaged in. If a user attempts to open another window, you have a javascript handler check with the server if it's ok, and then respond with an error messages.
However, a better solution is to synchronize the two sessions if possible like in google docs.