I am using Facebook Connect on Drupal 6.16 installation. The Facebook connect module adds the div FB_HiddenContainer at the bottom of the page, containing two iframes. The last of the iframes points to this source http://www.facebook.com/extern/login_status.php?api_key=*** API KEY ***&extern=2&channel=http%3A%2F%2Fbeta.orestad.net%2Fadmin%2Freports%2Fupdates%2Fsettings%3Ffbc_channel%3D1&locale=da_DK

This page contains another FB_HiddenContainer with an iframe, which has the following source http://beta.orestad.net/admin/reports/updates/settings?fbc_channel=1#%7B... Which points back to the page I am currently viewing.

If I decode the url encoding i get this url http://beta.orestad.net/admin/reports/updates/settings?fbc_channel=1#{"id":0,"sc":"http://www.facebook.com/xd_receiver_v0.4.php","sf":"loginStatus","sr":2,"h":"loginServer","sid":"0.759","t":0}[0,"loginStatus","InitLogin",{"baseDomain":"orestad.net","connectState":3,"perms":null,"publicSessionData":null,"session":null,"settings":{"inFacebook":false,"locale":"en_US"}},false]

See the test page here http://beta.orestad.net/

I hope someone can make som sense of this. I will investigate further to see if I can find if there are any conflicting modules..



prinds’s picture

Category: bug » feature

Okay, changing this to a feature request, since I realize this is probably normal behavior.

I looked at another drupal site using facebook connect module - http://www.fitpassnetwork.com/ - and I noticed the exact same issue.

But maybe it's only me who thinks this is an issue. It seems doing a full page load (including css, scripts and content) is a bit much, and I wonder if there's a way change this in order to speed up page load.

Looking at a non drupal site using facebook connect - http://www.somethingtoputhere.com/therunaround/ - I see that FB_HiddenContainer only loads a very minimal page from http://www.somethingtoputhere.com/therunaround/. I imagine that's better for performance.

But maybe I'm wrong, and in either case I'm hoping to hear some comments on this..


Arnaud Kali’s picture

Hi prinds,

Well, I have exactly the same problem on my site and i really don't think it's normal. The problem may be originating from Facebook, but this completely distorts statistics of my site and just doubles the site's loading time.

After 'google'ing this issue, I found some more people complaining about it, but didn't find anything helpful.
Some say that Facebook recently updated their policies and eventually made changes in their codes (which may be the cluprit for all this).

There's another thread about it : #761630: ?fbc_channel=1#.. appended to url

I really hope that someone will be able to fix this as soon as possible because my site-users are really annoyed by the site's loading time.


rares’s picture

same problem here. I've excluded the fbc stuff from my analytics reports, and you could also write a block or something that would exit(); php if it detected that it is a duplicate request.

dalin’s picture

Title: FB_HiddenContainer iframe is causing page to load twice » FB_HiddenContainer iframe with a source of [current_page]?fbc_channel... is causing every page to load twice
Category: feature » bug
Priority: Normal » Critical

This is critical since it causes the full page and all its resources to be downloaded twice. I've spent several hours trying to debug this and all I've been able to find is that when FB.Facebook.init() is run, somewhere in static.ak.connect.facebook.com/connect.php/en_US/js/Api/CanvasUtil/Connect/XFBML this ?fbc_channel iframe is created. It's very difficult to trace the problem since that file is minified.

dalin’s picture

Enabling debugging doesn't seem to offer any useful information:

Error: Facebook.init() has already been called.
XFBML (line 23)

>>>>>> http://example.com/
XFBML (line 23)

received hash %7B%22id%22%3A0%2C%22sc%22%3A%22http%3A%2F%2Fwww.facebook.com%2Fxd_receiver_v0.4.php%22%2C%22sf%22%3A%22loginStatus%2...
XFBML (line 23)

XdComm: Received packet
XFBML (line 23)

received full packet: id: 0 sc: http://www.facebook.com/xd_receiver_v0.4.php sf: loginStatus sr: 2 h: loginServer sid: 0.877 t: 0 d: %5B0%2C%22loginStatus%22%2C%22InitLogin%22%2C%7B%22baseDomain%22%3A%22example.com%22%2C%22connectState%22%3A3%2C%22perms%22%3Anull%2C%22publicSessionData%22%3Anull%2C%22session%22%3Anull%2C%22settings%22%3A%7B%22inFacebook%22%3Afalse%2C%22locale%22%3A%22en_US%22%7D%7D%2Cfalse%5D
XFBML (line 23)

sender: frameName: loginStatus relation: 2 channelUrl: http://www.facebook.com/xd_receiver_v0.4.php UID: 0 origin: null
XFBML (line 23)
XdRpcServer.Received: InitLogin

dalin’s picture

I've got a workaround

 * Implementation of hook_init().
function my_module_init() {
  // There's an untracable bug in FB Connect that causes the every page to get loaded twice.
  // Thus doubling the page load time.  The second page always has the same URL but with
  // ?fbc_channel=1 and maybe some other stuff.
  // @see drupal.org /node/777672
  // I can't trace the error so lets try to just abort.  
  if (arg(0) !== 'fbconnect' && isset($_REQUEST['fbc_channel'])) {

EdgarPE’s picture

Same here, subscribing.
I solved the problem with these .htaccess rules:

  RewriteCond %{QUERY_STRING} ^.*fbc_connect.*$ [NC]
  RewriteRule ^(.*)$ 404.php [L,QSA]

  RewriteCond %{QUERY_STRING} ^.*fbc_channel.*$ [NC]
  RewriteRule ^(.*)$ 404.php [L,QSA]

And the 404.php named file:

  header("HTTP/1.0 404 Not Found");
  print '404 Not Found';
prinds’s picture

Many thanks for your replies..

I'm glad to learn, that I'm not the only one, who thinks this should be fixed..

I will try the workarounds, but I'm wondering, won't this affect the functionality of the fbconnect module?

dalin’s picture

Yes actually neither of the workarounds really work. The one that I wrote prevents users from logging in with FBC. The .htaccess one doesn't really do anything, the full page is still loading twice (the rewrite rule just returns a 404, it doesn't prevent the page from loading).

We're also looking into better solutions.

dalin’s picture

Ah my bad, we had reworked that rewrite rules a bit, that's why ours didn't really work. The ones posted here will work as expected, but they will break FBC.

mcarbone’s picture

I'm not sure this problem is avoidable without rewriting this module using the new Facebook SDK. There's already an issue out there for this: #788118: This module needs to be updated

In a blog post (http://developers.facebook.com/blog/post/379), Facebook stated:

As you may have seen, we're transitioning away from the Facebook Connect brand to reflect that there is one underlying platform behind any integration with Facebook, whether you are building an application on Facebook.com, a website, or on a device. This change has no impact for the 250,000 sites using Facebook Connect today. All the same technologies exist on Facebook Platform, so no transition is needed.

However, it seems that this claim so far is wrong -- the old way of using Facebook Connect is causing this fbc_channel problem. Unless we can somehow get Facebook's attention to fix this problem, I think rewriting the module with the new SDK is the only way. (Such as Dave Cohen has been doing with his Drupal for Facebook module.)

mcarbone’s picture

So I commented out the following line in fbconnect_footer in fbconnect.module and it seems to be helping a lot:

    //$footer .= '<script type="text/javascript">FB.init("'.$config['api_key'].'");</script>';

Not sure why FB needs to initialized on every page for every user, especially since there's already a call to this function in fbconnect.js that's called as required.

In any case, FB Connect still seems to be working, and I'm not getting double page loads on every page anymore.

dadis’s picture

offer from #12 comment solved problem in my site.
login works and no redirect, hope everything else works also ok:)

thank you.

TCRobbert’s picture

Im not sure why, but the solution described in #12 did the trick for us as well. Tested on IE8, Opera, Chrome and FF.

prinds’s picture

#12 worked for me as well..

Many thanks..

carlop’s picture

#12 worked for me too.

Thank you very much.

vectoroc’s picture

Status: Active » Needs review

it's already fixed long time ago in github
Soon will be in cvs

nestor.mata’s picture

Has this being fixed?


nestor.mata’s picture

I applied the workaround in comment #12 and fixed the issue for me too, I hope nothing of the facebook logic gets broken.


esolano’s picture


michel.abboud’s picture

Assigned: Unassigned » michel.abboud

This bug drove me crazy for a while now.

Fix #12 worked for me too.

thanks :)

vectoroc’s picture

Assigned: michel.abboud » Unassigned

nestor.mata: I mean that changes from #12 comment are already commited. I did'nt see problems that are described here

vectoroc’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

james.williams’s picture

For anyone thinking of applying the solution in #12 above (and this only applies to people using that version of the module) - Instead of just commenting out the line

$footer .= '<script type="text/javascript">FB.init("'.$config['api_key'].'");</script>'; 

... A better fix that keeps the functionality of FB.init intact (though that function is a mystery in itself), is to add an extra argument for fbconnect's 'receiver' path (this fix was developed after reading http://www.electrictoolbox.com/facebook-connect-disqus-comments/ - scroll to the 'Not using Disqus? Then do this' section.):

$footer .= '<script type="text/javascript">FB.init("'.$config['api_key'].'", "/fbconnect/receiver");</script>'; 

It seems that FB.init no longer correctly finds the receiver path with this old facebook API, so needs this extra argument to find it.

davegan’s picture


Dipposh’s picture