Code from an English Coffee Drinker: September 2011

Followers, What Followers?

Now I don't want people to think that this blog is just about code for fixing problems with Blogger but... for this post I'll be fixing a problem with Blogger!

I don't tend to read my own blog that often, which means I don't spend much time looking at it. So it wasn't until I started investigating how to disable Blogger's forced lightbox viewer that I spotted I had a problem with the followers gadget on some of my blogs. Developing my original fix to that problem involved reloading my blog over and over again as I tried different things. Sometimes the followers gadget appeared and sometimes it didn't. There didn't seem to be any pattern but there was definitely a problem.

Given that a lot of the gadgets you find on blogs are JavaScript based the first thing I checked was the JavaScript console (I use Firebug in Firefox for most of my web development work) which showed the following two errors whenever the followers gadget failed to appear; window.googleapisv0 is undefined and google.friendconnect.container is undefined.

Given that the problem was intermittent I made a guess that this was some form of race condition. Most browsers will try and load at least two files required to render a web page in parallel. This means that sometimes files download and become available to the browser in a different order. Usually this doesn't matter but my gut feeling was that this was causing the problem. A quick look at the list of JavaScript files associated with my blog showed that there were quite a few related to the followers widget and that were all loaded at roughly the same time. I experimented by manually adding each of these scripts to the head section of the HTML template until I eventually found a solution.

Strangely it wasn't a script associated directly with the followers gadget that solved the problem, but rather a script for the +1 button. This did, however, explain why I was only seeing the problem on my blogs which included the sharing buttons below each post. So if you find that your followers gadget sometimes doesn't appear then it might be worth trying the following fix.

You need to edit the HTML version of your template (you might be able to do this via a HTML/JavaScript gadget as well but I've had less success) so in the old style Blogger dashboard go to the design page or in the new style go to the template page and then click to edit the HTML version of your template. Now directly after <head> insert the following:

<script src='https://apis.google.com/js/plusone.js' type='text/javascript'/>

This fixed the problem for me, and I've suggested the fix in a couple of threads on the Blogger forum and it seems to have worked there as well, so hopefully it should stop your followers gadget disappearing for good!

Fixing Blogger's Mistakes

UPDATE: Blogger have finally stopped forcing the lightbox viewer upon us, which means the fix detailed in this post is no longer required! I'll be watching though and if it reappears as the default option, with no ability to turn it off, then I'll update the fix so that we can continue to choose how our images are displayed.

Yesterday Blogger introduced a new 'feature' to some blogs. Now images appear in a Lightbox powered overlay. Unfortunately a lot of people think that this feature is actually a bug. On one of my other blogs, it is a really problem due to the fact that I was already using a different script to achieve a similar affect. With the new feature I now get two popup copies of each image which really is horrid. So I spent a good hour trying to find a hack or workaround, until Blogger sees fit to allow us to disable the bug.

The main part of the fix is a simple piece of Javascript.

<script type='text/javascript'>
//<![CDATA[
 var images = document.getElementsByTagName('img');
  for (var i = 0 ; i < images.length ; ++i) {
    images[i].parentNode.innerHTML = images[i].parentNode.innerHTML;
  }
//]]>
</script>

The fix works because the new Blogger code adds an onClick function to the actual image, whereas most people wrap the images in a link. What I wanted to do was simply remove the onClick function but I couldn't figure out how (and believe me I tried), but simply recreating the image removes any registered events. The problem is ensuring that this code runs after the code Blogger used to add the lightbox viewer.

The trick to getting this code in the right place (thanks to Bonjour Tristesse for this bit) involves editing the HTML version of your template. From the Design page in the old Blogger dashboard or from the Template page in the new version bring up the HTML version of your template and then place the code almost at the very end, right between </body> and </html>

If you aren't happy editing the HTML version of your template then you can also add the fix via a gadget. Simply go to the layout editor and add a new HTML/Javascript gadget (it doesn't matter where). Leave the title of the gadget blank and paste in the following code.

<script type="text/javascript">
//<![CDATA[
var lightboxIsDead = false;
function killLightbox() {
  if (lightboxIsDead) return;
  lightboxIsDead = true;
  var images = document.getElementsByTagName('img');
  for (var i = 0 ; i < images.length ; ++i) {
     images[i].parentNode.innerHTML = images[i].parentNode.innerHTML;
  }
}
 
if (document.addEventListener) {
  document.addEventListener('DOMContentLoaded', killLightbox, false);
} else {
  document.attachEvent('onDOMContentLoaded', killLightbox);
  window.attachEvent('onload', killLightbox);
}
//]]>
</script>

Save the gadget and you are done. The fix will have been applied and things should be back to how they were before Blogger introduced this bug/feature. If/when Blogger see sense and allow us to disable this feature then you can easily delete my workaround simply be deleting the gadget from your layout. Note that applying the fix by editing the HTML version of your template is slightly more reliable, but in most cases you won't see any difference between the two.

Now I'm quite happy to let each individual blog owner choose how to display their photos, and some might even like the new photo viewer. From reading the forums, however, it is clear that some people just really hate the new viewer and would prefer not to see it even on other people's blogs. Well it turns out that the above fix also works when used as a Greasemonkey script. If you already have Greasemonkey installed in your browser then you can simply install the script to kill Blogger's lightbox on all Blogspot hosted blogs. If you don't have Greaemonkey installed then the Wikipedia page should point you to a version for your favorite browser.

UPDATED 17th September: I've simplified the script slightly and added a fix so that if the mouse was already within an image when the page loaded the fix will still apply if you click the image, assuming you move the mouse at least one pixel in any direction.

UPDATED 17th September: I've edited the post to suggest that the fix is used via a HTML/Javascript gadget so that new readers don't have to wade through the comments to find this out.

UPDATED 17th September: Now we specify false in the addEventListener call to ensure better backwards compatibility with older versions of Firefox.

UPDATED 20th September: Added Bonjour Tristesse's much better fix as the main suggested workaround.

UPDATED 21st September: Added the section on using the newest fix as a Greasemonkey script to kill Lightbox on all Blogspot hosted blogs.

UPDATED 21st September: Simplified the new fix slightly to do the replace inside body instead of the main div. This means that it will work even if you have heavily modified a template to no longer have the named div assumed by the previous version.

UPDATED 21st September: The old method now registers the function so it is fired when the DOM is loaded not the page. This should mean it works even before the page has fully loaded.

UPDATED 21st September: Simplified the short fix, as the replacement isn't actually required to make it work. This cuts down on the number of bytes served and should run quicker as well!

UPDATED 21st September: Switched back to recommending the gadget based fix (albeit a simpler version) because Bonjour Tristesse's version actually breaks other widgets within the posts, such as the Google +1 button in the post sharing widget. Fortunately the new and improved gadget version is applied much quicker and so seeing the viewer is much less likely than before.

UPDATED 22nd September: Only replace the actual image, not the entire content of the parent element. This should reduce the number of situations in which there is a chance of breaking any other scripts or gadgets.

UPDATED 22nd September: Attach to both onDOMContentLoaded and onLoad when running under IE to ensure the code gets run regardless of which version of IE we are using, but make sure we don't try and run twice as that is pointless.

UPDATED 22nd September: Rewrote the post to show that the same fix can be applied both by editing the HTML template or by adding a gadget. The difference from before is that now the HTML template based fix won't break the sharing buttons etc.

UPDATED 22nd September: No longer use cloneNode as IE actually clones the event handlers so the viewer still appears.

Trawling The Heap

I've spent a good few hours over the last week trying to track down a memory leak in a web application I've been working on. As far as I could tell from the code all the relevant resources were being freed when finished with, but still after a few hours the tomcat instance in which the app was running would grind to a halt as the available free memory inched ever closer to zero. In the end I decided that that only solution was to trawl through a heap dump to find out exactly what was being leaked and what was holding a reference to it.

Now it used to be that taking exploring the Java heap was a tedious and horrid process. Fortunately, the JDK now comes with VisualVM that makes working with the heap really easy.

VisualVM can attach to any running Java process and monitor it's memory usage, which in itself can be useful, but it can also take a heap dump and then provides an easy tool for navigating through the often vasts amount of information provided. Now in theory you should be able to use VisualVM to examine the heap of the tomcat server running a troublesome web app. Now try as I might I couldn't get this to work. The problem stems from the fact that I'm running tomcat under a different user account than my own, an account that you can't actually log in to (for the curious I installed tomcat under Ubuntu using the default package which runs tomcat under the tomcat6 user). I could monitor the memory usage but no matter what I tried (and believe me I tried all sorts of things) I couldn't manage to get a heap dump.

In the end I resorted to manually creating a core dump using the unix gcore utility and then loading this into VisualVM which could then generate a heap dump. This actually works quite nicely. The only downside is that it requires you to know the process ID of the tomcat web server and this changes everytime the server is restarted, which if you are debugging a problem, can be quite often. So to make my life a little easier I've written a small bash script that makes tomcat dump it's heap, which I've cleverly called tomscat!

#!/bin/bash

pid=`ps -u tomcat6 | grep java | sed 's/ .*$//g'`
count=0

ls -1 tomcat*.$pid > /dev/null 2>&1

[ $? -eq 0 ] && count=`ls -1 tomcat*.$pid | wc -l`

gcore -o tomcat$count $pid

This script firstly finds the pid for the tomcat process then works out if there are already any core dumps for this instance of tomcat and then generates a core dump into a nicely named file. Currently there is little in the way of error handling so if it doesn't work any errors may be cryptic! Anyway hopefully other people might find this script useful, I know it made the process of creating a bunch of heap dumps quite easy, and once I had the heap dumps tracking down the leak was fairly easy (turns out the the leak was due to large cache objects associated with database connections not being made available for garbage collection).