miscoded

Opera uses the Browser JavaScript feature to automatically fix older scripts that otherwise would not run correctly.

One of the interesting challenges of doing that is to work out how, exactly, browser.js can tell when Opera is about to run an "outdated" script that needs fixing? Because if we apply the fix to a modern script, we might break things instead of fixing them..

Until today I thought the AllWebMenus fix was one of the safest in the book. It takes advantage of the fact that every AWM script contains a "build number" variable showing what version the script is. This variable is not even part of the comments where webmasters might remove it, it is right there embedded in the script. It is also relatively unlikely (though not impossible) that other scripts would define a variable called awmBN with a value that would trigger the patch, and even more unlikely that the patch would break a script doing so.

OK, think again. Browser.js breaks the menu on Aquaria.info because the inline script says

var MenuLinkedBy='AllWebMenus [2]', awmBN='438';

while the script file the page links to actually reveals a much more recent build number:

//****** AllWebMenus Libraries Version # 626 ******

So the webmaster has changed the .js files to upgrade, but not bothered changing the script in the HTML file. Not such a safe patch after all..

Once I stop saying "d'oh" I'll have to figure out what to do about it.. :-(

Ryanair, if you want customers to fly with you it may be a good idea to avoid rejecting them arbitrarily because they have names with characters outside US-ASCII. Seriously.

Web developers like to complain about browser x or browser y being "difficult" to work with. Bah. Sure, there are really annoying bugs in any browser, but most of the time the one you test initially in and are used to will be easy. The others will present small or big surprises. A couple of times I have written pages that only worked in Opera, because I happened to use both standardised features that are missing from Internet Explorer and IE-specific features supported by Opera but not others. A natural risk when one knows a specific browser's capabilities very well.

Here's a page I created recently that I thought was pretty standards-compliant (apart from event.offsetX and offsetY - perhaps I should ask WHAT WG to standardise those?):

Japanese new year's breakfast

..but whops, I did it again: it only appears to work in Opera. All the content is visible in any browser and I simply like creating Opera DOM capability showcases, so I won't add workarounds - but it makes me rather curious that even old Opera 7.23 does a perfect job but new FireFox 1.5 fails. I know IE doesn't get the setAttribute('style', 'some css code') part, but I have no idea where FireFox stumbles.

Usually I use this blog for opining on the quality of other people's and systems' code. Well, that's a bit one-way and biased, isn't it? Since I just found a bug in browser.js, written and maintained by yours truly, I'll sweep the street in front of my own door (as a Norwegian saying goes).

So, can you spot the broken logic in this browser.js excerpt?

if( hostname.indexOf('walla.co.il') ==hostname.length-11 ){
// Walla.co.il odd CSS styling causes display problems
// Bugs 184398, 184399
opera.addEventListener('BeforeEvent.load',
function(){ if(document.documentElement){(document.documentElement.appendChild(document.createElement('style'))).appendChild(document.createTextNode(' .btn-t,.btn{display:inline !important;} .wp-0-b{width:auto !important}'));
opera.removeEventListener('BeforeEvent.load', arguments.callee, false); 
opera.postError('Opera has modified the JavaScript on '+hostname+'. See browser.js for details');}}
,false);
}