This morning I noticed that my website was behaving strangely when it came to processing requests through the D7 ajax framework. When I looked into the issue I found that there is an "Uncaught Error" being thrown from line 43 of the "all.js" file provided from connect.facebook.net.

We have not made any changes to our FB setup for quite some time.

Have there been changes to the FB API? Is anyone else running into this issue?

The error seems to break the D7 ajax responder and cause erratic behavior on our site. When I disable the "Drupal for Facebook" module suite, the weird errors go away.

Comments

andres.silvao’s picture

I have the same problem. In firefox appears error in http://static.ak.facebook.com/connect/xd_arbiter.php?version=11 Line 13.

invincible1388’s picture

yes I am recieving this error too since yesterday..It seems something is broke from facebook end. Till Day before yesterday everything was working fine. Dont know how to fix it..Any ideas you guys have come up with?

agittins’s picture

I'm getting the same thing, first noticed it 24 hours ago. I'm running 6.x-3.3 so it doesn't appear to be 7-specific.

the error is being thrown from http://connect.facebook.net/en_GB/all.js at line 43 (it's minified code - line 911 when prettified in chrome) which looks like:

 __d("Assert", ["AssertionError", "sprintf"], function(a, b, c, d, e, f) {
        // ************ Uncaught Error Here (actually it seems to be the throw below that fails
        var g = b('AssertionError'), h = b('sprintf');
        function i(p, q) {
            if (!p)
                throw new g(q); // ************ here is where it seems to fail - q is "undefined".
            return p;
        }
        function j(p, q, r) {
            var s = Object.prototype.toString.call(q), t = /\s(\w*)/.exec(s)[1].toLowerCase();
            i(~ES5(p, 'indexOf', true, t), r || h('Expression is of type %s, not %s', t, p));
            return q;
        }
        function k(p, q, r) {
            i(q instanceof p, r || 'Expression not instance of type');
            return q;
        }
        var l = {isInstanceOf: k,isTrue: i,type: j,define: function(p, q) {
                l.isString(p);
                l.isFunction(q);
                p = p.substring(0, 1).toUpperCase() + p.substring(1).toLowerCase();
                l['is' + p] = function(r, s) {
                    i(q(r), s);
                };
            }}, m = ['Array', 'Boolean', 'Date', 'Function', 'Null', 'Number', 'Object', 'Regexp', 'String', 'Undefined'], n = m.length;
        while (n--) {
            var o = m[n];
            l['is' + o] = ES5(j, 'bind', true, null, o.toLowerCase());
        }
        e.exports = l;
    });

If I follow the call stack up from there when the error is about to be thrown, the first non-facebook-code call is from Drupal.behaviors.fb calling FB.XFBML.parse(elem) where elem is the root HTMLDocument.

Oddly, it doesn't fail every time although once I have the breakpoint set, it appears I hit it every time I load a page. When it does occur, it seems to break or halt further js processing, as my carousel doesn't load properly and the admin menu doesn't show on those occasions where it does fault - otherwise they show up fine.

Even if we can't fix it, is there a good reason why other processing appears to stop? Is there a way to prevent that by isolating the external code's initialisation? I have messed with a lot of bits of code so it is possible that the halting is something boneheaded that I have done - some verification if others have the same behaviour would be appreciated.

Now off to check it this breaks our checkout stuffs :-/

agittins’s picture

Lol a customer just beat me to it! Turns out the checkout still works, but no shipping quotes are triggered. Looks like I get to foot the bill for this customer's freight :-)

The main recent change I made was enabling Canvas Pages and FB Tabs modules (I think that was several days ago). I just disabled them again and still get the same problem so it's not likely related to that.

pdumais42’s picture

I've got the same problem and I've spent a few hours trying to resolve it. Has anyone figured out how to remove the conflict and restore proper Javascript behavior?

jherencia’s picture

StatusFileSize
new478 bytes

Here is the patch that fixed this issue in my apps.

jherencia’s picture

Status: Active » Needs review
james.williams’s picture

Status: Needs review » Needs work

Unfortunately HTMLDocument is undefined in IE9 so a different check is needed.

james.williams’s picture

For now, my workaround is to replace the FB.XFBML.parse(elem); line with:

        try {
          FB.XFBML.parse(elem);
        }
        catch (e) {
          // It would be better to only run FB.XFBML.parse() when we know it's
          // necessary to do so. Exceptions would then be valid.
        }

...just so that the exceptions are ignored and any other javascript on the page (that isn't asynchronous) doesn't just die. This isn't a fix though, as any exceptions there may actually need to be handled rather than ignored. I don't know what sort of check should be performed before calling FB.XFBML.parse() that would be cross-browser compliant. Anyone?

agittins’s picture

The patch in #6 works for me (chrome on linux) but I agree with james in #9 that catching the exception will be more robust and that patch is working for me also. I quite like that it should "insulate" us a bit from fb breakage (well, for that call anyway).

noahlively’s picture

Guys, thanks for the quick responsiveness on this. This is what I appreciate the most about open source

penyaskito’s picture

Status: Needs work » Needs review
StatusFileSize
new474 bytes

I'm testing now with this one, that uses Document instead of HTMLDocument because it is defined on IE9.
I need help testing it.

pdumais42’s picture

Thanks James. Your fix is working for us.

I would like to hire you for a one hour consultation to show me how you were able to determine what code to wrap in the try{}. I tried using Firebug but I just don't know how to do call tracing in Javascript. I would love to understand what tools you used and how you narrowed it down to this function call.

Please call or email me if you are available for a paid consultation. dumais at activeimmersive.com - 323-963-4242

I would be happy to pay for your time and have you post a webcast of your process for everyone to benefit.

Thanks.

EDIT - agittins, you did the initial debugging / stack trace. Maybe you would be interested in my offer.

Kirk’s picture

Any word on a fix for the 6.x version?

jherencia’s picture

StatusFileSize
new618 bytes

Ok I've tested all patches in IE:

  • #6 - Does not work in IE 7 and 9.
  • #9 - Works in IE 7, 8 and 9.
  • #12 - Works in IE 9 but not in IE 7 and 8. - Document does not exist in IE < 9

I've appended @james.williams' patch in #9 for those who want to apply it.

james.williams’s picture

@jherencia Thanks, sorry I hadn't had time to make it a proper patch myself.

I would be keen for someone to identify the actual issue (as referenced by the comment in my solution) rather than just my 'workaround' of using a try-catch block. Otherwise we run the parse function (which I imagine is relatively expensive) more than we need to.

jherencia’s picture

cirlot’s picture

#15 Patch fixed this for me. Thanks jherencia

Dave Cohen’s picture

StatusFileSize
new3.61 KB

Here's the patch I recently applied to D6. I plan to upgrade it to D7 tomorrow, along with a couple other minor fixes in the D6 branch.

The patch #15 is a good workaround in the meantime.

As far as I can tell, the XFBML.parse routine no longer works, and fails badly, when passed an entire document, as opposed to an element. So a ctools popup would trigger the error. I don't think normal pages will trigger this error.

wyattwww’s picture

FYI Facebook squished the bug today. https://developers.facebook.com/bugs/388181684587882

james.williams’s picture

Glad to see the Drupal community using this module works even faster to find solutions than Facebook's developers :-) The day we are as big a behemoth as Facebook will be a scary one.

Dave Cohen’s picture

Status: Needs review » Fixed

I merged the above patch into D7 anyway. This problem must have affected a lot of sites, for facebook to do something about it in just 3 days. :)

I didn't encounter this myself, in part because the overlay is the first thing I disable when working with D7.

Dave Cohen’s picture

Also, I'm not sure about this but I suspect the facebook fix is just to throw an exception, not to work as it previously did.

harings_rob’s picture

It works, but this aint enrolled in a new release yet?

jherencia’s picture

@tortelduif

The patch is in beta4.

harings_rob’s picture

Yes i did just see this. This error is also in drupal 6 version. Fix also fixes it there.

webfaqtory’s picture

Just in case this helps. I was getting this error from calling Drupal.attachBehaviors(); in my JS code (I had missed adding the context). Adding the context eg. Drupal.attachBehaviors(jQuery("#main")); fixed the problem.

I'm assuming that Drupal.attachBehaviors(); for the entire document was triggering some buggy FB code.

darioshox’s picture

#15 patch worked for me! Thanks to everyone for helping. I supose that on the next release the issue will be corrected.

Have a good day.

dfletcher’s picture

Just a note that I'm experiencing this bug in IE also and it's stopping other script code from functioning properly. I borrowed james.williams solution from comment #9 and it's a good temporary fix. Glad you guys are on this one. Unexpected changes coming down from Facebook are pretty awful and it's good to know that this project is active and responsive enough to have a fix for the next release. Great work, thanks.

alfredojez’s picture

After installing beta4, a new error appeared:

"if (Drupal.settings.fb.fb_reloading) {" on fb.js

some js functionality on the overlay (like drag and drop, etc.. ) is not working since the update

cirlot’s picture

Applied patch in #15 and it appeared everything was working. Noticed today that my upload button in IMCE is gone. When I disable this module, it's back. For now, i'm just disabling the module to use IMCE and then reenabling when I finish a new post.
Getting this in the Javascript Console in Chrome:

Uncaught TypeError: Cannot read property 'fb_reloading' of undefined

But it seems all other site behavior has returned to normal. But for clarity, when the error started showing I lost the admin menu, menu mini panels, uploading through the media module, and the upload in IMCE. IMCE is the only continuing problem after i applied the patch in #15.

Dave Cohen’s picture

regarding #30 and #31, please try the latest .dev builds. Had a fix for that a couple days ago and never pushed it! Thought I already had, sorry for inconvenience.

alvarodemendoza’s picture

#9 worked for me, we are 1 week before site launching. XD Thanksss

arlina’s picture

Release 6.x-3.x-dev (2012-Oct-02) seems to be working for me. Thanks for the quick response!

capellic’s picture

Thank you @jherencia -- #15 gets it done.

Status: Fixed » Closed (fixed)

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