The Coding Paparazzi

On many sites, the Google Friend Connect widget (and its counterpart the Followers gadget for Blogger) will not appear at all or rarely on Firefox.  A solution was published by Google (see "Why is my Google Friend Connect rarely displaying on my blog???" but it seems appropriate only for a group of sites using Prototype.js and remains without effect on other sites.

This article proposes another solution for this display problem of Google Friend Connect and of the Followers gadget on Firefox for those for whom the solution offered by Google is not appropriate.  It has been tested successfully with different types of templates - including those produced by Artisteer - and for sites hosted on Blogger or not.  A quick way for testing if this solution will be suitable for your site - without having to first modify it - is also provided along the way.

Note - the application of this solution requires to have some basic knowledge of javascript and also requires that you are capable to edit the template of your site but the necessary change is relatively simple and a Copy & Paste of the code provided at the end of the article should suffice in most cases.  This article is provided with several examples of code to explain how it works but it is not necessary to understand them to use it and if you want, you can go straight to the end of this article to use the code.

The examples in this article have been made with the Google Friend Connect (GFC) widget on an Artisteer template hosted on Blogger but this solution is not limited to this configuration only and will also applies to the Followers gadget as well as to other types of templates and hosting services. Those who also have the compatibility issue with Prototype.js will still have to apply the solution provided by Google about JSON; all the necessary explanations for this is also provided in this article.

You can see various tests done with GFC on the demo site "Google Friend Connect and Firefox" and see by yourself the difference in results between Internet Explorer (IE) and Firefox with different possible solutions.  It is normal for many of these tests to not display properly on Firefox.  There is an article on this site describing quickly each of these tests but this is only for an illustrative purpose and it does not repeat the explanations already provided here.

A future article will deal specifically with the specific changes to make for the Followers gadget for those wanting to use it on Blogger instead of Google Friend Connect but overall, the solution is essentially the same as the one described here for GFC.  You can see a second serie of tests done with the Followers gadget on another site: "Gadget Followers and FireFox".  Remember, it is normal to see several of these tests not displaying properly with Firefox.

For those who have problems with the display of GFC on Firefox, the solution recommended by Google - and published in the post "Google friend connect social bar is blank in Chrome and Safari - Google Friend Connect Help" by Seth Fitness - is to add the following code between prototype.js and the code of the GFC widget (preferably just before the latter):

This code aims to resolve a problem of incompatibility between prototype.js and the GFC code by restoring the default JSON parser.  However, if it actually solves the problem for those who have this specific problem of incompatibility, it resolves nothing for others who do not use prototype.js but still have a display problem on Firefox with GFC.  Thus, we can divide the situation into three groups:

    1- The problem of incompatibility with prototype.js

    2- Another source of problem

    3- The first two put together

Those who have only the first problem may correct their site using the Google fix and be done with it.  However, for the others, you can try with the possible solution offered in this article, either in combination with or without the Google's fix.  I should say that if you don't need it, using nevertheless the fix could broke the solution provided here; so you really need to test it without the fix as well if it doesn't work with it.

If we exclude the problem of incompatibility with prototype.js, I found that the display problem on Firefox seems to stem from the difficulty that it has to correctly handle the dynamic creation of an <iframe> element within one or more <div> elements when they have not yet been closed; that is to say when the terminal tag </div> have not yet been parsed:

In the previous example, the javascript code is inline code; that is to say that it will be run immediately by the browser before the following HTML code is to be parsed.  This also means that at the time of its execution, many of <div> elements which cover it will still be open because their terminal tags </div> will have not been parsed by the browser and won't be until the inline code is finished.  This is a necessary behavior because it is possible for the inline javascript code to issue (or inject) a new piece of HTML code with a call to document.write and in this case, this new piece will have te be parsed before the remaining HTML code that follows the inline javascript code.

But as we can see in the previous example, the inline javascript is contained inside two open <div> elements; alongside a previous third <div> element that has been closed but which is itself inside the two open <div>.  This is into this third <div> element - with and ID likes "div-1234567899" and highlighted in yellow - that the Google Friend Connect widget will dynamically create an <iframe> (whose content is the elements for the GFC widget) and add it as a child node.  So, the inline javascript code of the GFC will dynamically create an <iframe> and add it to a closed <div> element but this closed element is itself in an hierarchy of still open one or more <div> elements and that's what Firefox seems to have a problem with.

If this is really the source of the Firefox's display problem, then we can see that a possible solution would be to make sure that the <div> to receive the soon to be created <iframe> element is not located inside an open hierarchy of <div> when the code execute and this can be easily achieve by a variety of ways; for example:

1 - Moving the <div> element earlier in the HTML code, before any open open div element.

2 - Moving the inline javascript code farther away in the HTML code, after any relevant closing </div> tag; the best place probably being near the ending </body> tag.

3 - Change the javascript code so that it is no more an inline piece of code with immediat execution and instead, delay its execution at a more appropriate time; such as when the closure </div> tags have been parsed or even better, after the loading of the final <body> element.

The previous example has been made from an Artisteer template and your own personal mileage will vary but the overall principle should remain the same.  However, it's now the time to take a deeper look at the GFC widget code itself.  One such example of code is shown below.  Some values as the ID for the principal <div> tag (in yellow), the width or the colors will change in your own case but the rest should be identical.  Highlighted in yellow is the <div> designated to receive the <iframe> element and in blue is the method renderMembersGadget. This is the method that will create the <iframe> element and therefore, this is the one that we must delay in one way or another (beside moving the <div> element) if we want to try our solution.

Note that in this example the ID for the main <div> tag is "div-4539487656055420414".  It's a long number but you can change it to whatever you like (it doesn't even need for the new value to begin with "div-"); all it needs is to be unique among all the other IDs on your site.  It's also interesting to see that the automatic value provided by GFC always begins with "div-"; this way, it make it easy to found it on your site if you need to.  This would prove to be particularly useful in the case of the Followers gadget.

However, what's more important is that this ID's value is also passed as a parameter to the renderMembersGadget method below; so you can change its value but you must change it at both location.  This is important if you want to take the below examples and try them on your own site.  Beside this ID, you must also change the value identifying the site to GFC: this is the value
« site: '16774183366910057534' » in the above example which is passed as the second parameter to the renderMembersGadget method and it must be replaced with the value of your own site.  Look at the code provided by GFC to find it.

The rest of the GFC widget code consists of a link to the javascript file "friendconnect.js" and of lines of code which initializes the variable skin{} with the values for the visual appearance to be displayed by the GFC widget.  There is nothing particular with these lines of code and they can be executed anywhere as long as it is before the call to the renderMembersGadget method.  The same is also true for the call to the setParentUrl method.

However, the reading of the file "friendconnect.js" might pose a problem in some particular situations: the javascript code for the renderMembersGadget method (which by the way is a member of the google.friendconnect object) is part of this file; so this file must have been loaded before we get the right to call this method.  This is not a problem for the code as it is actually written - the browser will garantee that it has been loading before executing any inline javascript code that follows it - but if we change this inline code so that it's no longer inline, there will be no more any garanty.  Later, we will take a measure to prevent this in the final example.

The examples that follow have been made using an Artisteer template for Blogger.  Your own situation will likely be different if you are using something else but that's not important for the comprehension of what follow.  I have highlighted in yellow the beginning and ending of two <div> elements that contain the inner <div> and the javascript code that will create the <iframe> for the GFC widget; the later two beeing highlighted in a darker shade of blue.

And as already mentioned, what we need to do is to make sure that inner <div> is not inside any open <div> when the javascript executes; so the first solution would be to move it before them:

and the second solution would be to move instead the javascript code after them:

Finally, the third solution would be to keep both at their same locations but to change the javascript code so that it will no longer be executed immediately but only at a later time; at least after the moment that the closing </div> will have been parsed.

On the site "Google Friend Connect and Firefox", I made several tests to illustrate some of the above points to varying degrees.  All these test should display correctly under IE but but of course, some of them won't do it on Firefox.  I remind you that this site has been made with an Artisteer template but you won't necessary get the same result using another template.  However, it's my expectation that the solution provided at the end of this article should work for you and this, whatever the template that you are using.

In the first box, with the title "Google Friend Connect", we simply have the original code as directly produced by the GFC page, without modification.  Probably that if you test it with Firefox 3.5 or the latest version, Firefox 3.6 Beta 5, this widget won't display at all; unlike with IE.

The second box, titled "GFC 1", is simply an empty box excerpt for the inclusion of a comment; so it shouldn't display anything.  This is not very useful but we'll put it to good use in the next article about the Followers gadget and in which we'll need to take a look at the structure of a (empty) gadget on Blogger.

The following box, titled "CFA 2", was for the tests that I did make with the solution provided by Google about the compatibility problem between GFC and prototype.js.  As I do not use prototype.js, my expectation was that I would get no positive result and this is exactly what I got.  However, I also found that the simple fact of using this fix when you don't need has a negative effect in the way that the following boxes with the right solution - for my case - were not working anymore after that; so I had to remove this fix from the demo site.

Then comes the first real test for a potential solution - at least! - which is the use of the defer attribute and which result is shown in the box under the title "GFC 3 - Defer".  You can find more information about this attribute in the article "Deferred Javascript" but in our case, all we have to do is to add it to the script element containing the method call to renderMembersGadget:

This test is also the first one where we get tangible result because with the add of this attribute, Firefox 3.5 will now display the GFC widget correctly on this demo web site.  Unfortunately, this is not the case with the latest version of Firefox, the 3.6 beta 5.

This special attribute "defer" is an index indicating to the browser that is not necessary for the script element to be executed immediately before the browser can continue the parsing of the remaining HTML elements that follow.  This allows the browser to display the page and return control to the user more quickly; while the processing of the javascript is completed in the background.  Many browser will interpret this as a signal to wait for the parsing of the final </body> tag before beginning the execution of the scripts with this attribut. However, this interpretion or even any interpretation about this attribute is not mandatory; which explains in part why this potential fix does work with Firefox 3.5 but not with the version 3.6 Beta 5.

Although unfortunately this does not work with the latest version of Firefox, this result is nevertheless interesting in that it tells us that basically, probably that there is no major error or problem in our template and that the display problem with GFC seems to lie more on the side of Firefox or in the code of the GFC widget instead of beeing in the template itself.

The two following examples, GFC 4 and 5, are even more interesting than #3 because we will see the the first solution which will work as well with both the Firefox 3.5 version and the 3.6 beta 5 version.  For these two tests, I separated the code of the GFC widget into two different gadgets; so that the second gadget - the one with the javascript code - will come after any closing </div> that might present in the first gadget.

In the first case, the #4, I've put the second gadget right after the first while for the second case, the #5, I put it at the very end of the list of gadgets. This end of the list is not really at the very end of the template itself and many other elements such as the footer and the copyright notice still follow it but in our case, this was sufficient for the case #5 to show correctly on Firefox, including the beta 5 version!

The test didn't work in the case #4, even if its code is identical to #5; which shows us that the gadgets in this Artisteer template are themselves located inside a deeper hierarchy.  However, because the #5 did work, this also tell us that probably that there is nothing fundamentally wrong in the template itself and that this problem is most likely to be caused by a bug from either Firefox or Google Friend Connect than by a design error with the template.

If all you need is a working solution, than you don't really need to search any further than the solution used in #5; which is simply to move the javascript code away, toward the end of the HTML page (the </body> tag).  But there are some interesting points to find by digging deeper and in particular, we'll take a look at how we could test for these different scenarios in the easiest way possible and preferably, without to even have to modify our code and this is exactly what the test GFC 6 is all about.  For this one, I've put the javascript code for calling to the renderMembersGadget method inside the clicking event of a button and by clicking it on the demo site, you can see that this method is working perfectly well; not only on IE but also on all versions of Firefox as well.

Maybe you're not that tempted to install a button for displaying the GFC widget on your site - personally, I am as this will make the loading of the site much faster! - but in reality, this is very insteresting for everyone because it gives us an easy to test this solution on any web site; without having to modify it first.  All we have to do is to copy one line of code, to modify the value of the parameters for the div's and the site's iD, to add "javascript:" at its beginning and finally to paste the result into the address bar of the browser and to execute it by pressing [Enter].  Of course, in the case of the demo site, you don't have to change anything.

If everything is correct and if you don't need the Google fix, you'll see the elements of the GFC appearing on the page. In the case that you would also need the fix, all you have to do is to add it, too.  A full example for both cases is given below.  Also, in the case of Firefox, you don't have to remove any line break but for IE, everything must be on one line.  You will find below a full example for each of these cases: without or with the fix and on multiple lines or a single one:

Without the JSON fix:

javascript:google.friendconnect.container['renderMembersGadget']({id:'div-6508336042659712443',site:'10657890614271830163'},skin);

And with the JSON fix:

javascript:window.JSON={parse: function (st) {return st.evalJSON();}, stringify: function(obj) {return Object.toJSON(obj);}}; google.friendconnect.container['renderMembersGadget']({id:'div-6508336042659712443',site:'10657890614271830163'},skin);

Remember that if you don't need the compatibility fix for prototype.js, adding it migh make the problem got worst; so you really have to test for both cases.

Finally, in the tests GFC 7, 8 and 9, we'll use the window.onload event to run the code only after the last HTML element of the <body> segment has been parsed and loaded by the browser.  To do this, we first enclose the code inside a function and then we load this function in an event so that it will be run a a later time istead of being executed immediately.  For the first test of this type, the #7, I've used the window.onload event.  The following listing show in yellow the change that I've made to the GFC's original code:

As you can on the demo site, this method works perfectly with Firefox, all versions.  However, using directly the window.onload event is possibly not the best thing to do.  First, we have to think about the possibility that another event might already be enregistered on this event.  Second, this event will fire not immediately after the parsing of the ending </body> tag but only when all the images on the page have also been loaded; something which could bring a significant delay on many sites. You will find more information about these point as well as about the window.onload event itself on the following articles: "Using window.onload",  "Dean Edwards: The window.onload Problem - Solved!" and "How to Use window.onload the Right Way - Robert Hahn".

The article by Dean Edwards mentions the possibility of utilizing the addEventListener method in Firefox in order to accelerate the onset of the event but we must also think about the other browsers on the market.  You can obviously build all the code required by yourselves to get the best option for many cases but those using Artisteer have access to the artLoadEvent() function to ensure an optimum loading:

Notice that even if the box #8 is located after the #7, it will appears before the later on the demo site because the window.onload event used for the #7 will usually fire later than the event used in the #8.

Finally, there is also the question - already mentionner earlier - that the code in the file friendconnect.js might not have been loaded yet when the event is triggered; so a call to the renderMembersGadget will fail at this point because it's to early.  Remember that it's only for inline code that the browser will garantee that any previous javascript file has been loaded before attempting to execute the code; so in our case, it's not a bad ideal to add the necessary extra code to make that verification and to step back to come back later if necessary.  This is exactly what's has been added in the next example.  At the beginning of the function, there is a check about the presence of the google.friendconnect object.  If it's not found, a timer is set for the function to be called back in two seconds and the function is then exited.  (See "JavaScript Timers with setTimeout and setInterval".  This process is repeated if necessary until success or up to a maximum of 10 retries; for a total maximum of 20 seconds before a timeout.  After that, if the object is still not available, the display of the Google Friend Connect widget is canceled.

This example uses artLoadEvent() but the code remains the same if you want to use the window.onload instead.

Are we there yet?  Almost!  There's one last minor problem remaining and this one is about IE.  In my tests with the demo site and for wich there is many GFC widgets, I noticed that often IE will indicate forever that the loading of the page is not yet finished.  This happens very rarely when there is a single GFC widget on the page and is only a minor hassle but still, it leaves me an uneasy feeling (and by the way, it's also an indication that the problem is probably lying inside the GFC code than with Firefox or the template) so I decided to leave the thing unchanged when IE is used.  You can do this in a variety of way but for this case, I chosen to use the conditional comments feature of IE:

When using the window.onload event:

and for the artLoadEvent() function:

Here's is the final version that I'm curently testing on my blog The Coding Paparazzi :

You can use this code directly if you want to, all you have to do is to change the value for the ID of the site (in yellow).

===>> Also, if you don't use Artisteer then you must also replace the line: artLoadEvent.add (function() { DisplayFollowers(); }); with the line: window.onload=DisplayFollowers;

===>> Finally, I remind you that you might also need to add the fix for the compatibility problem with prototype.js but only if you need it; otherwise things might get worse.

The widget for Google Friend Connect can be easily changed because its code is provided to us directly; unfortunately, this is not as easy with the Followers gadget.  In a following article, we will see how to proceed with this gadget.
 

-- Erratum, december 22, 2009 --

    In the example GFC-9 and in the last listing above, the following line of code (en yellow) contained an error:

and has been corrected with the following addition, in yellow: