It's a bold thing to state, but since Chrome's latest update their interpretation of window.location.replace seems wrong. I have a site loading content in an iframe, to be able to add a toolbar on top. This toolbar can be disabled. When the toolbar is disabled a cookie is set. Every time a page is loaded the cookie is checked, if the cookie is there the user is redirected directly to the site normally loaded in the iframe, like this:
if($.cookie("noframe")==true)
window.location.replace='http://www.amazingjokes.com/';
This worked great 'till Chrome's latest update. People were sent straight to the site if they had the iframe disabled, and clicking 'back' sent them to my main page.
Not anymore...
People are now redirected back to the page loading the frame, with the cookie set they're redirected back to -in this case- amazingjokes.com. This is behavior of window.location.replace is now identical to :
window.location.href='http://www.amazingjokes.com/';
But this is not the behavior I'm looking for. I could set another cookie to track the redirect, but that's creating more and more overhead. And the 'replace' option should cover this. Is there a workaround? Or should this be reported as a bug at Chrome?
Related
I've been having an issue with the Facebook Like button for quite some time. I've looked all over for a solution but am quite stuck. The error occurs on my site www.MapYourVote.com. When you go to a poll page and click 'Like' the dialog appears and quickly disappears. At the same time, the counter also goes to 1 and quickly goes back to 0.
The problem is always solved for individual poll pages by using the Facebook Debug tool (http://developers.facebook.com/tools/debug). Once you use it on the url, the like button will work as expected. The issue is my website is dynamic and I can't use the Facebook Debug tool every time someone creates a new poll. The Facebook Debug tool does not reveal any problems (apart from og image size but I doubt that's the issue).
Here is an example of a page in which the Like button does not work. If you were to enter this url into the Facebook Debug tool, the Like button would work.
http://www.mapyourvote.com/Poll/Election-Result-Feelings/
Any help would be much appreciated!
I also had this problem. I was constructing a referrer url to give link-sharers a credit, so there was a different url for each user that wanted to share something. The referrer link would give the user credit and redirect to the login page of my site. With this configuration, the like dialog would appear for a moment and then disappear again, unless I went to facebook's debug tool.
What fixed the problem for me was to change from a redirect to rendering the page directly from my referral link. In fact, I changed the referral link to be a ?r=refid parameter on my root page URL. It appears to work correctly if facebook doesn't have to follow a redirect to get the og: data.
I had a similar problem and it turned out I had too restrictive cookie policy set in my browser - I only allowed Facebook to use 1st party cookies. When I allowed Facebook to use other cookies, the problem was solved. It's hard to debug when no error appears other than the immediate pop-up closeup.
I had the same problem. It was caused by url value in data-href attribute. I had there url pointing to my localhost.
When I changed the url to existing one, problem was solved.
Hope it helps
For me, the problem (Like popup disappearing after a second) was happening when the Like button URL redirected to another URL.
The fix was to add og:type, og:url, and og:title (required per https://developers.facebook.com/docs/reference/opengraph/object-type/website), then running the URL through the Facebook debugger to clear the cache (https://developers.facebook.com/tools/debug).
More at https://stackoverflow.com/a/16597060/2391566
I would like to know on my web page whether the user has loaded the page normally through clicking a link, entering the URL or whatever, or whether the page is from the history and the user came there by pressing the Back button in the browser (or using a hotkey...).
So essentially I'm looking for a method like window.location.canGoForward(). Does something like this exist? If not, what are the workarounds?
I don't care about what happens when the Back/Forward button is pressed, there's plenty of content about that on the web. I just want to query the loaded page about whether it is the latest in the browsing history or not. Wide browser support is appreciated.
You could count the length of the history variable to see if they are new to your site. Here are some helpful links
http://www.w3schools.com/jsref/obj_history.asp
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history
https://github.com/browserstate/History.js/
I've searched for answers to this -- seems like all the answers relate to the old Facebook API so the solutions are no longer relevant.
The problem I'm having: I've got a custom Facebook tab which has a button on it that, when clicked, triggers FB.login(). The way it should work is: user clicks to log in, popup comes up to authorize the app, user clicks authorize, the popup closes. This flow works correctly on all browsers except IE8 and below. On IE8, the user clicks to log in, the popup comes up to authorize the app, the user clicks authorize, then the content INSIDE the popup refreshes with the content from the redirect URL. Needless to say, this is not the desired experience for IE8 users :(
I've tried everything I could find: doublechecked that there are no javascript errors, ensured that there is a valid channel file, etc. Nothing appears to fix it. Everything is happening through secure (https), so I'm not sure if that has anything to do with it.
I've been trying to fix this for DAYS now; any help would be GREATLY appreciated!
Make sure fb-root element is only once in your page , I have faced this issues and when i made sure that fb-root div is only once the issue got resolved
You should specify a p3p header in all responses from your web server. Please see: http://www.hanselman.com/blog/TheImportanceOfP3PAndACompactPrivacyPolicy.aspx.
By "the content INSIDE the popup refreshes with the content from the redirect URL" do you mean that you are passing a redirect URL? If so, don't do that. The popups work using some cross-domain JavaScript magic with a specially constructed redirect URL. If you put your own, then the popups may break.
Also, make sure you're setting a proper channelUrl when you call FB.init().
A site that links to mine keeps my site in a frame, so I added the following JavaScript to my page:
if (window.top.location != window.location) {
window.top.location = window.location
}
Now if I get to my site via the offending site, my site successfully breaks out of the frame. But the back button breaks! The back button sends the user to the framed version of my site, which immediately breaks out again, returning him to where he was trying to leave! Is there a simple way to fix this?
window.top.location.replace(window.location);
The replace method is specifically for this purpose. It replaces the current item in the history state with the new destination so that the back button won't go through the destination you don't want.
jfriend00's answer is indeed correct. Using the window.location.replace method will work without affecting the back button.
However, I'd just like to note that whenever you want to stop a page from being framed, you should do more than just that! There are a couple methods of preventing a simple script like that from breaking out of the frame, which work in many modern browsers. Perhaps you can disable the page, display a message with a link to the full page, something like that. You could also use the X-Frame-Options response header that tells the browser not to display the page in a frame. If you don't take some of these measures, your site could be clickjacked.
Another solution is to open your site in a new window leaving a friendly message in the iframed site:
if (parent.frames.length)
{ window.open("mySite.htm", "MySite");
location.href= "framedMessage.htm";
}
Where framedMessage.htm contains some friendly/warning message.
I want to know how Facebook is doing their iframe footer bar. I mean, i know they have an iframe on footer, but i want to know how they are reloading pages without reloading the iframe also, 'cause the iframe always stick there even though the page does reload again. Any ideas/knowledge?
EDITED:
Try clicking on a link which is different section and it changes the url and so far i know, if you try to change the URL, then the page will reload again. Also, try using Facebook on Chrome: you will see it reloads on every new page. It's not AJAX, because the URL wouldn't change if it was AJAX (do little research on URL changing, you will know).
Well, powtac pretty much gave you the answer: Facebook doesn't reload the whole page when you click a link, it requests the new content via XMLHttpRequest and refreshes only those portions of the page that change.
It's pretty slick about this: a naive implementation might not use real links at all, thus preventing you from opening, say, a different Facebook tab in a separate browser tab.
This technique - intercepting link navigation - also allows Facebook to use custom prompts when you try to navigate away without saving, and re-write paths as fragments, allowing it to track the current location in the URL without reloading the page.
FWIW, this question has already been asked and answered - see: How are the facebook chat windows implemented?