Skip navigation.

miscoded

the web is a hack

Posts tagged with "funny"

Most expensive javascript ever?

, , ,

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";
}

'ESPN FLASH detection system' meets Flash 0

, , , ...

Even in the classy company of bad version detection scripts we've met since we started testing Opera 10, this Flash detection approach stands out. That script goes to great effort to require an update every.single.time Adobe releases another Flash version.

It starts with a bold claim to be the ESPN "Flash detection system", no less:

// Author: Danny Mavromatis
// Version: 2.07.0
// Created: 10/29/2001
// Updated: 3/6/2006
// ESPN.com FLASH detection system
var f2 = false;
var f3 = false;
var f4 = false;
var f5 = false;
var f6 = false;
var f7 = false;
var f8 = false;
var f9 = false;

Look at all those variables. What might they be used for? Read on:

var fD = navigator.plugins["Shockwave Flash" + isVersion2].description;
var fV = parseInt(fD.charAt(fD.indexOf(".") - 1));

So, first it extracts one single letter that precedes a dot in the plugin's description of itself. This is presumably the plugin's major version number, you know the 8 in "8.0", the 9 in "9.0", and, um, the 0 in "10.0". Then:
f2 = fV == 2;
f3 = fV == 3;
f4 = fV == 4;
f5 = fV == 5;
f6 = fV == 6;
f7 = fV == 7;
f8 = fV == 8;
f9 = fV == 9;


..it just sets the corresponding "f"-variable to true. If the major version was 8, f8 will be true and so on. A great way to make sure the code will require maintenance - new variables for each new version. And then comes the real gem:

for (var i = 2; i <= mV; i++) {
if (eval("f" + i) == true) aV = i;
}
// alert("version detected: " + aV);



Let's see, we just had a variable fV which contained Flash's major version number (or at least its least significant digit) - but this script has severe amnesia. What was that number again? Better use a loop and 8 eval() calls to check the value of that variable. You never know, do you?

Now, dear readers - Mr. Mavromatis clearly needs some help with this code. Obviously, complexity and maintenance requirements are among his design goals. The natural question is whether there are good, non-obvious ways this script could be improved to be more complex and require even more maintenance? Suggestions welcome in comments.

Update: Danny Mavromatis responded in comments and - though he no longer works on the ESPN site - has made sure that the page where we found this problem has been updated. Kudos to Mr. Mavromatis for his quick response and sense of responsibility. I wish more web developers would act this way!

No more personal attacks, please!

Rabobank trusts only Rabokeys

, , ,

The Rabobank site in the Netherlands has a peculiar problem caused by an even weirder script. The forum discussion explains what the problem is: the site's search box doesn't allow you to type the letter T!

This is caused by a keypress handling JavaScript - it's all on one line so I made a re-formatted copy. If you thought the bug was weird, wait till you try figuring out what the point of the script is..

The basic logic that causes the problem is: "any browser that supports addEventListener() will support charCode but not keyCode in the keypress event". As it happens, Opera does support addEventListener() but not charCode. The site blocks keypress events with keyCode 116 which is the correct keyCode for a "t" keypress. (If we didn't support addEventListener they would listen for keyDown events with keyCode 116 instead - which is what they basically intended to do.)

With the problem analysis out of the way: I simply don't get what this site is trying to do. They set one handler for keypress events to cancel them if it's the F5 key, and another handler for keyup events to call location.reload() if it's the F5 key!? See here:

function F5DownEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
return cancelKey(evt,this.keyCode,this.target)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
return cancelKey(evt,this.keyCode,this.target)
}
}
function F5UpEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
window.location.reload(this.ctrlKey)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
this.target.parentNode.parentNode.submit()
}
}


So: "we don't mind that [F5] reloads the page and [enter] submits forms as long as we re-implement the browser's functionality in JavaScript".

Or: Rabobank trusts only Rabo-programmed keys?

I guess the browser's OWN implementation of [F5] and [enter] just wasn't buggy enough. :wink:

Hotmail has class

, ,

Hotmail's choice of class attribute for its HTML element if you use Opera to access it just strikes me as very funny.. The output of a
javascript:alert(document.documentElement.className)
command is:



That's right. In other words
<html class="Firefox FF_Win FF_M1 FF_D5 Opera">
Is that what you would call exquisite confusion? :confused:

Aside, I hope to have the basic Hotmail working again in Opera 9.2x before the end of the day. After all, what's an insulting class declaration to a browser from the proudly egalitarian Scandinavian peninsula? We're above class, for sure p:

nobody told the backend about the merger

, , , ...

Nearly a year ago Adobe made a big move and aquired Macromedia. When doing so they made big announcements (though I much prefer John Gruber's unspun FAQ) and generally hyped the deal as best they could.

Apparently, they forgot make their online store backend read the pressreleases:

GET /cfusion/store/index.cfm?store=OLS-NO&view=ols_prod&category=/Applications/DesignPremium&distributionMethod=FULL&promoid=RWTS&nr=0 HTTP/1.1
Host: store2.adobe.com


HTTP/1.1 302 Moved Temporarily
Date: Fri, 30 Mar 2007 12:22:37 GMT
Set-Cookie: TID=--RWTS; path=/; domain=.adobe.com; expires=Sun, 29-Apr-2007 12:22:37 GMT
Set-Cookie: CFID=40105465;domain=.macromedia.com;expires=Sun, 22-Mar-2037 12:22:37 GMT;path=/
Set-Cookie: CFTOKEN=7c9bb3da703d2768-A2CC1D8D-B3D9-8643-43D13FDD8990B947;domain=.macromedia.com;expires=Sun, 22-Mar-2037 12:22:37 GMT;path=/

If you aren't fluent in HTTP, that is Opera asking for a page on store2.adobe.com, and the server responding "well, we've moved the page over there for now but by the way please remember these cookies and send them next time you visit us at macromedia.com".
p:

security through stupidity

, ,

I already blogged a piece of nonsense called "HTML protector", commercial software that pretends to "protect your HTML/JavaScript/CSS code from theft". Readers of this blog will know that this software is absolutely worthless at "protecting" any code, and seriously harmful to any site that is meant to be accessible or meant to show up in Google.

We've found a few more sites where this tool blocks Opera-users but I can't imagine any site that has content I would WANT to see being this clueless so I won't patch them or anything. However, while researching this I found evidence that this software is used by phishers. That makes a lot of sense when you think about it: phishing sites do not care about Google findability and they may even try to obscure themselves from security software.. So, this adds a touch of extra security for our users! Certain phishing sites actively detect Opera and automatically show a clean white page instead of their spoofed login forms. A case of security through stupidity!