FacebookTwitterGoogle+Share

Sometimes people do interesting things!

Facebook. The other day, Jeff and I noticed their footer bar – let’s call it the presence bar, since that is how they’ve identified the div – behaves differently with different browsers!

In Safari, Opera, and Chrome it works normally. You click a link, the page reloads, and the presence bar opens to where you’d left it.

In IE (6 and 7), as well as in Firefox, not so much. The links only alter the part of the URL succeeding the hash mark. The page never reloads.
New content is loaded via an invisible iframe. On completion, the data is extracted from the iframe and inserted into the main section of the page – which doesn’t include the presence bar.

Facebook can use JS to read the section of the URL after the # and load the appropriate page, which allows pasted URLs and bookmarks to work, as well as the back and forward buttons.
If you inspect their HTML, you will notice that the links’ destinations are identical for either set. They probably use Javascript to hijack clicks via eventlisteners.

I have no idea why they’ve decided facebook should behave differently based on browser. Maybe they ran into some sort of problem? Ideas?

I prefer the first approach, but they could have done much worse with the second. They’ve made sure it preserves usage assumptions common to web applications, and degrades gracefully.

 

Comments

  1. Shaun says:

    I don’t believe you re: interesting things. Rebuttal?

  2. Brad says:

    I will let karl dispute that with you?

    here is an example of what i meant by after the # in the url: http://www.gigglingcorpse.com/index.php?p=9#HIHI-THIS-IS-THE-STUFF-AFTER-THE-HASH

  3. Karl says:

    I think the second approach is sort of like a more-compatible kind of ajax? I like how it stops the page from reloading (flicker, extra load time from unnecessary components), and they probably implemented it because they had difficulty preserving state for some reason, but it does sound incredibly fragile.

    I think the blog was quite interesting but only after I realised that “first” and “second” referred to “reloading the page” and “faking ajax with an iframe”. Up until that point it was pretty confusing.

  4. Brad says:

    I am confused by this part of your comment:

    Karl :
    I think the second approach is sort of like a more-compatible kind of ajax?

    thoughts?

  5. Karl says:

    you know what
    maybe they know it works in firefox and IE and only check for those
    and other browsers just get fallback code =O

    Brad: What is confusing about it? Back when not everybody supported AJAX, you could fake it (like phattie did) by loading the content in an iframe and then transferring, just liek you describe.

  6. Brad says:

    Oh, i thought you meant a more compatible kind of ajax than the other method… which didn’t make sense to me since it wasn’t ajax at all 😛

  7. Jeff says:

    My original speculation was that there might be some JavaScript issues with Safari/Opera/Chrome, perhaps to do with accessing the content reliably. However, I never really checked. 🙂

    I wonder what kind of overhead there is in faking the AJAX with the iframe? Replacing the entire content of a page seems like it might be a bit slow? /curious