Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.

2009/09/11

Why People Hate Javascript, or Must Mean Chum

I work with a web front-end to a genomics database. This is what pays my bills. We recently moved the URL from one associated with my university to a dot.org. We decided to push all users coming into the .edu address to the .org address. Easy javascript, I thought. I had finished something and decided to test it with IE, which I never use. "The only legitimate use for Internet Explorer is to download Firefox", as I always say.

But in IE, I got bouunced to some weird, wrong URL. So, I added some debug code to figure out what's going on.



Here's the code that generated this, with dyked-out relocation code.


$(function() {
var u = $( document ).attr('URL') ;
var v = u.split( /\//g )[2] ;
var w = u.split( /\//g ) ;

if ( v != host ) {
w[2] = host ;
x = w.join('/') ;
alert( u + '\n' + v + '\n' + w + '\n' + x + '\n') ;
// window.location.replace( x ) ;
}

} ) ;




u is the URL. Both the same.

v should be the host, which is the problem. A url looks like this: protocol://host/path/?querystring, where path could contain many slashes. Split on slashes,
protocol should be the first element, or element [0]. Element [1] should be blank. Element [2] should be host.

But it just isn't.

w is an array, made from the URL and joined with a comma for display purposes. The alert from Firefox says http,,host,path, showing a blank element 1, as it should be. The alert from IE says http,host,path. Evidently, it thinks the regular expression was variable.split( /\/+/g ),which matches and splits on one or more slash, rather than variable.split( /\//g ), which matches and splits on one and only one slash.

There is a scene in Cabin Boy where Chris Eliot, a candidate for upper-class twit of the year, tells the existing cabin boy (Andy Richter) that he wants some fancy soup for dinner. The cabin boy walks off and decides "He must mean chum". Chum is rotting fish guts. Microsoft decided that I must have meant chum.


3 comments:

  1. Not sure if you were aware of this, but browsers provide a [fairly uniform, if I remember correctly] interface for directly grabbing these data:

    https://developer.mozilla.org/en/DOM/window.location

    Use that rather than parsing the string manually and hopefully save yourself some heartache.

    ReplyDelete
  2. Nick,

    Not aware of that at all. I need to know the DOM a lot more. Thank you very much for that piece of information. I've demo'd the replacement code, and while I haven't pulled out my IE box to test it on, I believe it should work.

    I'm a Perl guy. I'm used to parsing the strings. While, yeah, there's a much smarter way to do it than what I did (I admit it, I did a foolish thing because I didn't know any better) Isn't IE's splitting on /(foo)+/ instead of /(foo)/ definitionally broken behavior?

    ReplyDelete
  3. Being as though I'm somewhat lousy at regex and you're a Perl guy, I'd wager you'll have a better chance of judging whether IE is behaving or not. (I'd lean toward not more likely than away)

    Also be aware that JavaScript does use /regex/g for global, etc.

    ReplyDelete