Facebook, please more transparency...

On 6/20, I filed a bug to Facebook about an issue with all Facebook Connect-enabled sites using IE7 with Flash getting a blank dialog screen after authenticating. If you disabled Adobe Flash, then there were no problems and you didn't see the fatal blank screen of white. The problem was so consistent that I really didn't think it required more information, but I still uninstalled Flash 11 and installed Flash 10 just to make sure it wasn't an issue with newer Adobe Flash versions with IE7.   (For more background about how Facebook Connect works, see this article.)

The response from the Facebook triage team? Need more info. To try to make a point, I suggested that all you had to do was deminify their all.js JavaScript code, disable the HTML5 'postmessage' handler, and then incorporate this modified all.js in your site in lieu of theirs to reproduce the behavior across all browsers, not just IE7. The irony was that I just noticed that this source code suggestion was removed in the "need more info" section of my bug post.

The section in all.js that deals with registering different cross-domain handlers has a function called isAvailable() to determine whether to use it.  For IE7 browsers (but not IE8+), this return value will evaluate to false.  If you want to leverage other browsers with better debugging tools, the trick is to force a return false for all attempts to register the 'postmessage' handler.  By disabling the HTML5 postmessage code, the JavaScript will revert to using Adobe Flash and implement a custom postMessage() function that mimics the same behavior of the HTML version.

            r.register('postmessage', (function() {
                var s = false;
                return {
                    isAvailable: function() {
                        return false;  /* INSERTED line here */
                        return !!p.postMessage.

Almost 2 weeks went by before I noticed that IE7 logins all of a sudden started working again. What was peculiar was that on 6/3/2012, I noticed that the xd_arbiter.php version got bumped:

Changed file all_deminified.js

1		/*1341364990,169916611,JIT Construction: v585470,en_US*/
	1	/*1341373700,169938038,JIT Construction: v585470,en_US*/
2	2
3	3	window.FB || (function() {
4	4	var ES5 = function() {
…
578	578	}
579	579	});
580	580	__d("XDConfig", [], {
581		"XdUrl": "connect\/xd_arbiter.php?version=8",
	581	"XdUrl": "connect\/xd_arbiter.php?version=9",
582	582	"Flash": {
583	583	"path": "https:\/\/connect.facebook.net\/rsrc.php\/v1\/ys\/r\/WON-TVLCpDP.swf"
584	584	},

You can actually download the files to see what versions 8 and 9 did.  There was a specific change that particularly interested in me:

wget "http://static.ak.facebook.com/connect/xd_arbiter.php?version=8" -O v8.txt
wget "http://static.ak.facebook.com/connect/xd_arbiter.php?version=9" -O v9.txt

$ diff v8.txt v9.txt 
516,517c520,521
<                 var da = z.apply(u.context || a, aa);
<                 if (da) u.exports = da;
---
>                 var ea = z.apply(u.context || a, ba);
>                 if (ea) u.exports = ea;
642c646
<         "path": "https:\/\/s-static.ak.fbcdn.net\/rsrc.php\/v1\/ys\/r\/WON-TVLCpDP.swf"
---
>         "path": "https:\/\/connect.facebook.net\/rsrc.php\/v1\/ys\/r\/WON-TVLCpDP.swf"
743c747,751

Normally a change from fbcdn.net to facebook.net doesn't matter, except that the .SWF file appears to have a check to make sure the file is hosted on a connect.facebook.net site.  If it isn't then the initialization code isn't executed and the postMessage receive handler may not work correctly, which means that successful logins will just remain stuck and not proceed to the next step.  You can review the Flash code by using showmycode.com and decompile the .SWF file listed above.

            if (_local3 != "connect.facebook.net"){
                XdComm.fbTrace("XdComm is not loaded from connect.facebook.net", {swfDomain:_local3});
                if (_local3.substr(-13) == ".facebook.com"){
                    _local4 = PostMessage.extractPathAndQuery(_local2);
                    if (_local4.substr(0, 8) != "/intern/"){
                        XdComm.fbTrace("XdComm is NOT in intern mode", {swfPath:_local4});
                        return;
                    };
                    XdComm.fbTrace("XdComm is in intern mode", {swfPath:_local4});
                } else {
                    return;
                };

Someone must have recently noticed the problem and quietly fixed it.  This change may have also explained why I started noticing a bunch of security exceptions when attempting to use the Flash v10 debugger version when logging in via IE7.  There were also a bunch of debugging messages in the JavaScript console that indicated that the SWF files were being initialized correctly except that all messages being sent were not being acknowledged by the postMessage receive handler.  


I'm not sure what could have been done except to point out to Facebook exactly what needed to be fixed.  Regardless, Facebook, please be more transparent about these issues, since this incident is not the first time you've broken Facebook Connect IE7 logins and your API platform status pages rarely advertise these issues.