7 comments

[ 3.1 ms ] story [ 26.1 ms ] thread
Looking at it through Chrome, it triggers a bunch of JS errors in the Facebook javascript plugin.
It's generating the errors because it's not detecting a parent container (cross domain iframe communication).
I wonder how they discovered this, and whether this is truly a problem - when would someone come into a site with that hanging on their url?
I found out about this issue when a few users complained. It turns out google was indexing the pages, so sometimes those types of URLs would appear on a search page.

The simplest way to combat it is to have google ignore that parameter in google webmaster tools. Then it won't ever get indexed.

Facebook doesn't want people to enable cross domain authentications/spoofing. If Facebook enabled their plugins to work inside iframes external to the Facebook environment, it'd be easy to maliciously authenticate users to give data to a fourth party.
This is working as designed. The author of the article didn't fully investigate why he was getting users with the fragment and if he alters his code, will negatively affect page performance on his page.

In order to do cross domain communication, Facebook iframes the current page with the fragment. When Facebook's javascript library in the iframe detects the parameter, it blanks the page to reduce the render time that it takes for the iframe to complete so that it can generate the cross domain communication channel faster.

Originally, Facebook had developers upload a file to act as the cross domain script but became a problem for some people who couldn't do this so for the most part. This is still doable, but most people don't read the documentation clearly and Facebook doesn't want to complicate it's message of a simple install( http://developers.facebook.com/docs/reference/javascript/FB.... ).