I have 3 steps form, like this:
http://example.com/first-step
http://example.com/second-step
http://example.com/summary-step
I also have profile page:
http://example.com/profile
Requirement is that user cannot get back (using browser's back button) from summary-step to any of previous steps, he/she should be redirected to profile page.
This logic, for some reasons, unfortunely cannot be done on backend side, so only thing remaining is manipulating browser's history. In other words, if user reaches summary-step, previous page in browser history should be replaced from second-step to profile.
Is it doable? Important fact is that this should work not only on desktop, but also most popular mobile devices (iOS >= 7, Android, WP7+). Anchor hacks or adding url's get parameter is also impossible, as long as it hits backend.
This is how you can add your Profile page URL to the history using Javascript!
window.history.pushState('profile', null, '/profifeURL');
Related
My goal here is to create a Javascript function in a one-page app that can tell me if the back-button would do anything.
I thought that window.history.length would help me: if the length is same as when the app started, you are at "the beginning" and the function should do nothing.
But no. Imagine that there is one internal link in the app, #a. When you start the app from a new tab, the browser is at #, the length is 1 and you know the back button will do nothing. If you click the #a, you go to #a, the length is 2, and you know the back button would work.
Then, sadly, if you do press the back button, you go back to #, but the length is still 2, because #a is in the "future history".
Help me out. How do I know whether the back button is currently "active"? This is killing me.
(The problem is a little complicated by the idea that there might be a URL from a completely different site in the history. For me, that should be treated as "inactive", even though the back-button would itself actually work.)
Assuming your users never modify the url manually, then the only ways they navigate are by either
Pressing a button/link in your app, or
Pressing the back button
Therefor, you can track this with your own history. Every time a button is clicked, store what page it was on and that a button was clicked (possibly in localstorage). Then, when it loads again you can simply test whether or not where the user is now was reached by hitting a button/link or hitting back. If it was by hitting back, decrement your history. If you have no recorded history, you know the back button either won't work or goes to a different site.
The solution is to store route changes within your app and keep your own state history. This is because of the following:
For security reasons the History object doesn't allow the
non-privileged code to access the URLs of other pages in the session
history, but it does allow it to navigate the session history.
To do this in angular you need to use the $locationChangeSuccess event. See: How to detect browser back button click event using angular? for detecting back button and if its not back button simply append to an array that you track.
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.
My website will revert visitors to a seperate mobile site, this seems fairly simple after reading a few guides online.
However, I would like people to be able to click a link on the mobile site which will then take them to the desktop site.
The problem I see is that if I link back to the desktop site it will just redirect them back if they are on mobile?
How can I get around this?
Really you want to be doing this sort of thing server-side, not client-side. The issue is you're forcing a mobile user (on a potentially bad connection) to download your whole desktop site first (which might be over 1MB), just for the javascript redirect to take effect.
By that point, your mobile visitor may have lost patience and left already.
I blogged about the process here: http://www.9xb.com/blog-2012-08-6-common-pitfalls-when-deploying-a-mobile-site-and-how-they-can-be-avoided/ - if you jump to the bottom of the article, you'll see a flow diagram that maps out the whole process. This particular method uses cookies, but it could be adapted. The beauty of this flow diagram is that it is language independent - you can develop it in any server side programming flavour.
For your convenience, I've included the flow diagram below (although I strongly recommend you give the article a read):
http://www.9xb.com/wordpress/wp-content/uploads/2012/08/mobile-deployment-small.png
The alternative to all of that work, would be to develop a mobile-first responsive site. Not knowing your circumstances, I'll leave it at that - it's not always appropriate in every single scenario.
Make the redirect-to-mobile optional (i.e. a link at the top of the desktop page), or put the mobile redirect only on the initial entry point, i.e. mydomain.com. If they go to mydomain.com/index.html, then don't redirect. That way your 'back to desktop' link can be simply a normal link to index.html, from index_mobile.html or wherever you send them for their mobile experience.
Personally, I would much rather the layout was fluid enough to fit whichever browser anyway, then there is no problem to begin with. Remember, there are now tablets of various sizes to muddy the mobile browsing waters.
Unfortunately you cannot check for the referrer after window.location change. But you can add a hashtag and then check for it.
if(window.location.hash == "#stayHereDude"){
// do nothing, or whatever
} else {
window.location = "mobile/index.html";
}
Then, you'ld make a link to /index.html#stayHereDude on the mobile page.
On your home page that makes the mobile redirect, you'll want to check for something in the href that marks them as having coming from the mobile site. In my case I've used a link to the home page from the mobile site with a ?m=0 at the end of it. For example: http://www.yoursite.com/?m=0
Then you check before the redirect on the home page for that m=0 in the href. if it's there, don't redirect, if it isn't, redirect to mobile.
if (window.location.href.match("m=0")) {
} else {
window.location = "http://www.yoursite.com/mobilesite";
}
This works if you're only redirecting from a single page to your mobile site.
You can use Cookies, Session or Local Storage such that when a user clicks on "go to desktop site", it sets a value.
Let's say you set the name to be "mobileOff" and the value set to "1" or "true" when a user on a mobile phone clicks on "Go to Desktop Site". Then, wherever you're doing your mobile check, add a conditional to check for the mobileOff in the user's cookie/session/localStorage, if it's set to true, bypass the automatic mobile redirect, otherwise, load the main desktop site.
you should combine user agent method to detect device clubbed with query string to this sort of functionality.
so lets assume your link is
site/default.aspx
if some one hits this page check the user agent and give in the response the appropriate site or event better if the device detected if a mobile device simply redirect to m.yourdomain.com/site/default.aspx
but if some one hits the page site/default.aspx?type=desktop then override the behaviour of checking the useragent and render the desktop site.
never ever you should first load the desktop site and then via javascript reditect to a mobile site. do this using user agents server side.
Static
/site/index.html
/site/mobile/index.html
Then you can use a range of things.
Cookies
Session States
User Logged in and Preference Settings (even database saved)
If you're using a static site - becomes more difficult as it gets messy with JavaScript redirects and two many duplicate pages. Post your code and tell us your how you are currently doing your setup and I will update my solution.
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.
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().