I have a website that has been entirely designed to operate without generating any browser history other then the main page. This was mostly for security so the browser state and the server never are out of sync.
I want to know if there is a way to intercept the browser "back" button when they are anywhere except on the main page of our site to operate an internal "back" button.
You can use Push State Navigation to handle browser's back button. Take a look at this link https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
Related
The main question: I need to know that previous link in my browser - is link of my site?
There are several problems:
I can put current url to my stack, and when i go back through my internal method, I just remove it from url. But! If I go back or forward by press browser button how can I know is back or forward event?
If I have a stack, after refresh page this stack is clear, but browser has a history (browser buttons back and forward is active).
This is the single page backbone application.
Thanks!
After long investigation of this problem, I understand that browser (substantially I do it in Chrome) do everything to not give application information about browser history. Because it's security information. So legal way to do this does not exist.
So, in my case I assume that refreshing browser restarts single page application, and it has no history. And I serve my own history using managed Backbone router events and "back" event is handled only by clicking on MY button "back", but not browsers.
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
I've seen a few web apps lately that by clicking buttons change the content and effective state of the page. Then they have links to navigate to another part of the app. Sometimes I'd then like to go back by pressing the browser back button, and I expect the page to be in the state it was when I left. But I often see the content from when I first entered that page.
What's a good way in a modern web app to architect the navigation so that back button returns to you the previous (last) state of the page.
This article may have some answers. It details how to use HTML5's pushState and popState to maintain state in an web app when forward/back are used, without fully refreshing the page.
http://diveintohtml5.info/history.html
Am not sure what u mean by "modern", but you might wish to check this discussion here (about how manipulation of browser history might be controlled and why [it's not evil sometimes]), and also look into this jQuery plugin (for hashable history and state).
And for a related SO Question : check this
I suppose you are referring to a dynamic one page app, powered by AJAX.
You can use the new PushState() and replaceState() methods of the history object, which are supported in most modern browsers (inc. IE10), and allow you to manipulate the browser's history without triggering a page refresh.
This allows you to attach an object to the state, which will be available to you once an onpopstate event has been triggered, that is, when the user presses back or forward in his browser.
once the object has been passed you can manipulate the page accordingly. e.g. you can pass a unique ID for a post, and load it with AJAX.
You can read more about it in Mozilla Developer Network
Most resources suggest using onclick handler with trackEvent() for tracking outgoing links. BUT this way does not work with all navigation methods! It won’t work if you click with middle button (except Chrome) or control-click (except Chrome and FF) to open new tab, if you right-click and select new tab or window from context menu or if you drag link to another tab. Is such cases onclick is simply not called. You can check it with very simple link:
GO
Putting JavaScript in href attribute breaks the link in all cases when new tab or window is opened.
Putting onclick in span that looks like a link, will not allow users to decide if they want to open in new tab or not.
Finally, going through a redirect page, which tracks outgoing event, causes problems with back navigation – when users try to go back, they get back to the redirect page and then JS again redirects to the destination page. They need to click back twice … quickly.
Is there a better way, which would be both accurate and user friendly?
Context menu can't be detected by using JS. So if you want to catch that you need to use the redirect method. To fix the back button problem, redirect using location.replace to remove the tracking page from the back-button history.
I don't know any details about Google Analytics. In general, to track users' external navigation:
<a ping> is made for this purpose. If ping is not available, fall back to changing the links to go through a redirect page. Use a 302 redirect to prevent it from showing up in history; if you can't, try javascript:window.location.replace().
My webapp has a CLIENT_CERT based JAAS authentication. I am using IE7.
When I click on logout, it takes me to my home page. Now clicking on the back button, the user should remain on the same page, which I acheived using history.forward() javascript. But the certificate dialog comes up since the previous page was secured.
How can I avoid the certificate dialog from not coming and also remain on the non-secure home page when user clicks on back button after logging out.
The only way to disable the back button within a window is to use location.replace() for every single interaction, which you cannot do if you need to submit any forms unless you target them to a hidden iframe and then do a location.replace() in reaction to the iframe's onload event once the form is submitted. This is really nasty and complicates everything.
The other technique to avoid users going back through pages (some online banking sites do it this way) is to launch the secure section in a new window, and have logout close it (you can force a close in IE with window.opener = null; before window.close();.