miscoded

function hide(arg2){
	if(browserType=="gecko"){
		document.poppedLayer=eval("document.getElementById(arg2)");
	}
	else{
		if(browserType=="ie"){
			document.poppedLayer=eval("document.all[arg2]");
		}
		else{
			document.poppedLayer=eval("document.layers[arg2]");
		}
	}
	document.poppedLayer.style.display="none";
}

These quaint remnants from a time where a giant, binary, document.layer-supporting lizard named Netscape 4 roamed the World Wide Web were found on Virgin America's site.

Virgin America, would you please (belatedly) enter the 21^st century?

I guess Finnair is the household's favourite airline. I don't think I've used any other carrier during the last three years or so - we don't travel that much, so we're not talking many flights overall. However, it was rather annoying to find its website broken last time I wanted to look up some prices:

Finnair site auto-complete menu broken, error in console

After selecting a local site, the auto-complete menu to choose departure and destination cities from never populates. What's worse: the site doesn't accept anything you type in by hand! If you haven't made a menu selection, you get an error message! I'm sure that does wonders for their overall accessibility and section 508 compliance..

The error message complains that they refer to a variable "i" that doesn't exist. Somewhat wrapped, the code looks like this:

a.Autocompleter.Cache=function(c){
	var f={};
	var d=0;
	function h(k,j){
		if(!c.matchCase){
			k=k.toLowerCase();
		}
		if(!k.startsWith(j)&&k.indexOf(" "+j)===-1&&k.indexOf("("+j)===-1){
			return false;
		}
		return i==0||c.matchContains;
	}

The problem is the reference to i in the return statement. There is no variable "i" defined nearby, indeed not in the entire script file. That "i==0" looks like some dead code that isn't meant to be there anymore. But it works in other browsers, no?

If I load the page in Firefox and type javascript:alert(window.i) into the address bar it says "1", so in Firefox the site does somewhere create a global variable named i. The question is where?

Firebug can't - as far as I know - break when a variable is initialized or changed. As always, Fiddler comes to the rescue - setting a "HTTP breakpoint" after response and re-loading the site in Firefox lets me add some simple debug code:
Fiddler screen in breakpoint mode, debug code highlighted

window.__defineSetter__ ('i', function(){ try{ undefined() ; }catch(e){ console.log(e) ; } })

When I click Fiddler's "run to completion" button, an error message appears in Firebug's console pointing to this function:

function isFirefoxWMPPluginInstalled(){
	var plugs=navigator.plugins;
	for(i=0;
	i<plugs.length;
	i++){

which given its name is naturally called after some browser sniffing, here:

type:$.browser.mozilla&&isFirefoxWMPPluginInstalled()?"application/x-ms-wmp":"application/x-mplayer2"

So this works in other browsers by pure luck - because JavaScript scoping rules are such that when you don't use "var" keyword to declare variables, they will be global, and Fnnar's code contains numerous loops that use "i" as a counter and don't use var. If such a loop happens to run before you try booking, the site will work for you. As if we needed any more evidence that JavaScript scoping rules suck..

If we're going to site patch this error in browser.js, the patch would be simply var i;. At 6 characters, I'm fairly sure it would be the shortest site patch ever. Meanwhile, we'll contact them and hope Fnnar will get their "i"s back in order.

And I sure hope they deploy better software for their autopilot than their autocomplete...

I've wanted to tell this story for a while, and I don't think I'm spilling any beans or disclosing any sensitive information at this point.

So, a while ago Opera Software needed more servers. Not just a few servers either - we were planning Opera Mini's growth, implementing Opera Link, and My Opera was also growing quickly. We predicted crazy server load increases for the foreseeable future (and man, were we right!)

Clearly we needed to make a massive investment on the server capacity front (basically buying these shiny things and then some.)

Management put a hefty check on the table - I'm sure our beloved sysadmins felt like kids before Christmas - and salivating sales people from major hardware vendors grabbed our requirements spec, dived into their CRMs and crunched their spreadsheets. They emerged with offers and sample servers shipped all the way to Oslo for our testing pleasure.

However, one of the world's biggest hardware vendors - whose name every single reader will be familiar with, and whose hardware a good share of you will be using right now - apparently didn't do their homework. When Opera's sysadmin booted up the server to test its web-based administration interface, they came across a single JavaScript statement that managed to piss off everyone up to and including the CTO.

This single statement, apparently written by some sub-contractor they had outsourced admin interface programming to, cost them millions of NOK in lost sales.

And the code they sent all the way to Oslo for testing? Here's an extract:

if (is.opera)
{
window.location.href="config/error.htm";
}

Yikes.

I'm seeing X-UA-Compatible abuse everywhere these days. It seems most of the big sites I look at have decided not to give the IE8 team half a chance to iron out their bugs, they've all simply decided to close their eyes and slap on a "behave like IE7" instruction instead. Guess if this is going to cause compat problems down the road when all non-IE browsers are forced to look at the META tags and figure out if they should be bug-compatible with IE7, 8 or 9 for any given site.. :-(

Here's a funny offender: adobe.com insists that if I'm going to show their "flashAbout_info_small.swf" animation correctly, then ..

GET /swf/software/flash/about/flashAbout_info_small.swf HTTP/1.0
Host: www.adobe.com
Referer: http://www.adobe.com/products/flash/about/

HTTP/1.1 200 OK
X-UA-Compatible: IE=7
Content-Type: application/x-shockwave-flash
Date: Sat, 21 Feb 2009 23:39:33 GMT
Content-Length: 594

... I have to render the .swf like IE7 would.

No problems, Adobe. Since I work for a browser vendor the server's wish should be my command. Here's your about Flash SWF rendered by IE in IE7 compat mode:



Beautifully compatible, no? Thanks for the X-UA-Compatible hint, I would never have figured that out on my own!