I have a question, is it possible to get the url from the history.go(-2)?
Assuming i don't know that url.
edit
I need the url, because I want to check where the visitor was redirected from. there are two cases: 1 facebook, 2 directly on the website. the second step is an automatic user check. the third step is miscoded, but if I go back to step 1. I can bypass the error. with everything working fine. the problem is that I don't know where to redirect (being two forwarders).
It is not, by design, for privacy reasons.
You can in some special circumstances get the previous URL with history.previous (and likewise for .current and .next) but you can't look back arbitrarily and see where I (the visitor) went two or three or ten pages ago. From a website, reliably getting even the most recent page URL (which is sometimes available as the "referer") is never guaranteed.
Thinking about it from your visitor's perspective, this is good. Just because I'm visiting your site now doesn't mean I want you to know about every other page I've ever visited in the same browser window.
No, not in general.
If the URL is on the same hostname as the current page you sort of could, by opening a pop-up window, navigating back 2, then using script in the pop-up to read the opener.location, navigate forward 2, and pass the URL to script in the opener. But it would be an enormous pain and pretty unreliable.
If the URL isn't on the same hostname, you can't at all, for privacy reasons.
I'm not sure if this is possible with your set up, but you could add a GET veriable (ie. page.ext?ref=1) and then store that in a session and output it on whatever page you need. Then, on your facebook page, you could add ?ref=1 to the link. This would allow you to add other site references in the future as well.
It probably isn't possible as history.go() does a URL redirection.
You can get the previous/next URL by doing history.previous/history.next property respectively. This returns you an absolute URL. For current URL, use history.current.
More info on history object.
DevGuru.com
Exforsys.com
Related
Is there a way I can get the URL of the last page the user has been? document.referrer isn't what I want, because it only gets the referrer and it won't work if, for instance, the user clicks the back button.
I suspect this isn't possible, since you can't even get the URL of the forward page in the history.
As indicated by #ctwheels, this seems to solve my problem: http://w3schools.invisionzone.com/index.php?showtopic=31256&p=169916
Quoting from the page:
get the url of just the last previous page? of your domain only, or
all previous pages? of yours and external domains?
if you require last previous page, of your domain only, would storing
url in javascript cookie work?
one cookie to store previous url, and another to store current, then
next page, the current would become the previous.
EDIT: #DontVoteMeDown recommended to use localStorage instead of cookies.
I am working on a free domain service provider and it appends its own brand name to my URL on the browser address bar. I want to prevent that by re-writing the URL to give the user a better look and feel. How do I do that using only Javascript (no add-on libraries)?
window.history.pushState(null,'title','/something');
First argument is data, you don't need that.
Second one is the new page title.
Third one is the url. However you cannot completely change it, it will still be relative to the domain.
Okay so there are solutions for this as in Modify the URL without reloading the page but I have one question regarding this.
So here is what I plan to do (let's assume my web address is example.com)
1. using pushState I plan to change the browser address to example.com/myprofile/myalbum. So to be clear, this new url may or may not exists but the browser address is changed regardless. In our case this url doesn't actually exist but we are using the address to mark a changed state of the webpage.
2. use ajax to load data regarding "myprofile > myalbum" to the same page.
But now here's the issue I have been thinking about. What if a user loads example.com/myprofile/myalbum directly on a, let's say, new tab. This page clearly throws a not found error because it doesn't exist.
So how do I load ajax corresponding to this fake url? For example http://www.usatoday.com/news/ seems to do this well (unless that's an iframe, which wouldn't be so nice).
You can add rewrite rules to your webserver, converting either specific URL's or some matching a pattern to something that your scripts can use to show the right page. You can have it rewrite the URL only internally, so the user still see the original URL in the browser. Such as:
RewriteRule /myprofile/(\w*) /index.php?path=/myprofile/$1
Different webservers will probably have different syntax, but they will be similar.
Note: The question is not how to fix the problem, as that is documented elsewhere on SO (e.g., Integrating Facebook to the leads to blank pages on some browsers / fb_xd_fragment).
1) What causes this, and under what conditions is it triggered?
2) More importantly, does this affect end users at all? For instance, how does this bug affect the URL shared by someone who clicks the FB Like button? If someone clicks the FB Like button from URL A, does URL A still get shared (but with "fb_xd_fragment" appended), or does URL A become your root URL (with "fb_xd_fragment")? In our logs, all the URLs appear as the root URL with "fb_xd_fragment" appended, so we're not sure if this is because people are clicking the Like button from the home page, or if all the shared URLs get morphed into the root URL.
Basically, what happens is whenever you use the JS API it opens your site in another iframe to use as a cross-domain receiver. What you can do is set a custom channel URL and it will use that instead. If seeing this bothers you, you can set a custom channel url. More information on http://developers.facebook.com/docs/reference/javascript/FB.init/
I've never learnt JavaScript, but I imagine this is quite a simple problem. Just wanted to know which method is most advised these days.
// use this to avoid redirects when a user clicks "back" in their browser
window.location.replace('http://somewhereelse.com');
// use this to redirect, a back button call will trigger the redirection again
window.location.href = "http://somewhereelse.com";
// given for completeness, essentially an alias to window.location.href
window.location = "http://somewhereelse.com";
edit: looks like the user who posted the better answer has left SO, i've consolidated his answers here.
Most advised? To not do it. HTTP is far better suited to the job than JavaScript is (search engines follow them, you can state if it is permanent or not, they are faster, etc).
Failing that…
If you want an immediate redirect:
window.location.replace('http://example.com/');
This will replace the current URI with the new URI in the browser history, so the back button won't land the user on a page that immediately throws them forward again.
If you don't really want to redirect, but want to send the user somewhere in response to an event:
window.location.href = 'http://example.com/';
Remember to have a non-JavaScript fallback. A link is usually the best option, but it does depend on context.
Time delayed redirects are an even worse idea. The only reason to use them is if you want to display a message to the user - and users read things at different speeds (and have them sitting in another tab while they do something else). If the message is important enough to show, then it should be important enough to leave on screen until the user has read it and clicked a link to the next page.
One important thing to remember when redirecting a page using JavaScript is, always provide a non-JavaScript redirect as well! A link would do, or better a <META> tag, for example: <meta http-equiv="refresh" content="2;url=http://example.com">
These days, I think the most advised method is not to do javascript (or meta) redirects. Do you really need it ? Could you use a redirect HTTP header instead ?
The W3C's Web Content Accessibility Guidelines (7.4) also discourage the creation of auto-refreshing pages, since most web browsers do not allow the user to disable or control the refresh rate