The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
via Facebook's Platform Updates:
ReplyDeleteChange in Session Redirect Behavior
This week, we started adding a fragment #_=_ to the redirect_uri when
this field is left blank. Please ensure that your app can handle this
behavior.
To prevent this, set the redirect_uri in your login url request like so: (using Facebook php-sdk)
$facebook->getLoginUrl(array('redirect_uri' => $_SERVER['SCRIPT_URI'],'scope' => 'user_about_me'));
UPDATE
The above is exactly as the documentation says to fix this. However, Facebook's documented solution does not work. Please consider leaving a comment on the Facebook Platform Updates blog post and follow this bug to get a better answer. Until then, add the following to your head tag to resolve this issue:
<script type="text/javascript">if (window.location.hash == '#_=_')window.location.hash = '';</script>
The Facebook has a frame and inside the frame everything works with AJAX communication. The AJAX solution's biggest problem in this case to show the current state. As far I understand, the Facebook decided that they use simulated anchors. It means if you click somewhere, they simulate that this is an anchor inside the page, and when starts the AJAX communication they change your anchor bit of your URL as well.
ReplyDeleteThis solution helps you normaly, when you try to reload the page, becuase your borwser send the whole url with anchors to the facebook server / if you refresh the page (not ENTER, press F5)/. So the Facebook pick up the latest state, what you see, and able to continue there.
When the callback returns with #_ it means nothing changed compare to basic state. Because this anchor parsed by the browser, not need to worry about it.
Not sure why they're doing this but, you could get around this by reseting the hash at the top of your page:
ReplyDeleteif (window.location.hash == "#_=_")
window.location.hash = "";
Major annoying, especially for apps that parse the URI and not just read the $_GET... Here's the hack I threw together... Enjoy!
ReplyDelete<html xmlns:fb='http://www.facebook.com/2008/fbml'>
<head>
<script type="text/javascript">
// Get rid of the Facebook residue hash in the URI
// Must be done in JS cuz hash only exists client-side
// IE and Chrome version of the hack
if (String(window.location.hash).substring(0,1) == "#") {
window.location.hash = "";
window.location.href=window.location.href.slice(0, -1);
}
// Firefox version of the hack
if (String(location.hash).substring(0,1) == "#") {
location.hash = "";
location.href=location.href.substring(0,location.href.length-3);
}
</script>
</head>
<body>
URI should be clean
</body>
</html>
if you want to remove the remaining "#" from the url
ReplyDeleteif (window.location.hash == '#_=_') {
window.location.hash = ''; // for older browsers, leaves a # behind
history.pushState('', document.title, window.location.pathname); // nice and clean
e.preventDefault(); // no page reload
}
A change was introduced recently in how Facebook handles session redirects. See "Change in Session Redirect Behavior" in this week's Operation Developer Love blog post for the announcement.
ReplyDeleteAdding this to my redirect page fixed the problem for me ...
ReplyDeleteif (window.location.href.indexOf('#_=_') > 0) {
window.location = window.location.href.replace(/#.*/, '');
}