codeRambler Ramblings on code, the web, and technology

Selenium running with Firefox 3
Thursday October 16th 2008, 11:54 am
Filed under: Agile, Web development

If you have been using Selenium as part of your continuous build process, then the release of Firefox 3 has probably caused you some problems – specifically the inability to have Firefox 3 launch with the custom profile to allow Selenium to run.

It turns out Selenium installs a tiny little extension into the Firefox profiles it generates that basically just lets selenium kill firefox by telling it to go to a magic chrome url. Firefox extensions specify which versions they are compatible with and the one embedded in selenium had 2.0.0.* as their maximum version…

It looks like the solution is actually very simple and is described in detail over at Space Vatican.

Comments Off

From The Book of Mozilla
Friday August 17th 2007, 9:38 am
Filed under: Web development

I’m sure that many of you use Firefox regularly. You may have typed about:config into your browser location bar to manage your internal browser settings.Another useful variation of this is about:cache which will show the browser cache and allow you to view individual items in the cache.Today I stumbled across another one! If you type about:mozilla into the location bar, you get presented with a passage from the “Book of Mozilla” (a play on a religious text):

And so at last the beast fell and the unbelievers rejoiced.But all was not lost, for from the ash rose a great bird.The bird gazed down upon the unbelievers and cast fireand thunder upon them. For the beast had beenreborn with its strength renewed, and thefollowers of Mammon cowered in horror.from The Book of Mozilla, 7:15

The thing I like about programming is that you can sometimes have fun doing this kind of thing. The reference above refers to the name change from Phoenix (the name of the original 2002 project) to Firefox – and reassures it’s followers that the project lives on.Now… time to have some fun…

Comments Off

Tips on converting strings into numbers
Monday August 06th 2007, 10:29 am
Filed under: Javascript, Web development

When you are reading a value from a text input, the value is returned as a string. This is not really a problem for Javascript in that it’s loosely typed and converting the string into a number is really straightforward.

As with most things, there are several ways to do this conversion. I’ve used parseInt() a lot in the past to convert a string into a number (although strictly speaking I am converting to an Integer rather than just a Number when using parseInt()), but recently ran into some strange behaviour that I wanted to understand.

var l_sValue = "07";
alert(parseInt(l_sValue)); // alerts 7

This seems to work fine, the string represents the number 7, and the parseInt() correctly parses it into the integer 7. Now we change the string value and something strange occurs:

var l_sValue = "08";
alert(parseInt(l_sValue)); // alerts 0

This is obviously not the expected result! The solution is to use parseInt() correctly, and pass through both parameters (the second parameter is the number base to use).

If you do not pass in the second parameter (the base, or radix) then Javascript will default to base 10, unless:

  • the string starts with ‘0′, then it will default to base 8 (octal)
  • the string starts with ‘0x’, then it will default to base 16 (hexadecimal)

Because the string we used above started with ‘0′, Javascript defaulted to use base 8. The reason we see 0 being returned from parseInt(’08′) is because 8 is not a valid number in octal (we would count in octal 0, 1, 2, … 6, 7, 10, 11, 12, … 17, 20, 21, …).

Now look what happens when we pass in the second parameter and use (the more familiar) base 10:

var l_sValue = "08";
alert(parseInt(l_sValue, 10)); // alerts 8

Lesson for the day: always pass in the base when using parseInt() to parse a string into an integer.

Memory leaks and closures in Javascript
Thursday August 02nd 2007, 11:57 am
Filed under: Javascript, Web development

The topic of memory leaks reared it’s ugly head again recently and I tracked down several good articles and tutorials that discuss and explain some of their causes (and how to prevent them) quite well.

One of the main symptoms of memory leaking is performance slowdown in the browser (this affects all browser, some to a greater degree than others). Investigations of this type of problem invariably lead to Javascript closures – a very powerful feature of Javascript that is very easy to abuse.

For those looking for an explaination of what closures (aka. continuation by some) are and how they are so important to Javascript, take a look at this informative article at

There is a working account of one person’s battle with closure related memory leaks titled IE: where’s my memory?. This article links to many good resources, and has a very well thought out explaination as to why closures are so useful in the first place.

Of course there is a formal description at the MSDN Library as well (complete with diagrams, code examples and patterns).

There is a good tutorial on how to avoid Javascript memory leaks at Jack Slocum’s Blog. This specifically mentions problems experienced with the Dojo Toolkit, (along with Prototype) and even WordPress (used to power this blog).

After reading all those articles, no doubt you will be itching to refactor your existing code!