Just read an interesting article about a buffer overflow bug dealing with the select method. Interestingly, the proof of concept choose the max signed 32-bit integer of 2147483647 to cause the bug. This does indeed crash IE8, but does not crash FF3.5. I didn’t personally test any other browser. What’s even more interesting about this though is that this shouldn’t overflow in JS, as all numbers in JS are internally represented as 64-bit floats. Moreover, even if JS had a 32-bit integer number that number shouldn’t overflow at all. Given that the bug deals with the select element, my suspicion is that it is a DOM related issue that is being misrepresented as an ECMA script related issue.
Archive for July, 2009
One Bug to Rule Them All
Friday, July 17th, 2009Please don’t destroy browser functionality
Sunday, July 12th, 2009Dear web developers,
Please consider browser functionality when designing your sites. More and more “Web 2.0″ sites are taking away my browser features. The biggest culprit so far are sites with JS that like to make links which redirect you to a different page via JS or pop-up a modal, or other similar dialog which then has a link that takes you to a different page. Both of these prevent me from being able to open a link in a new tab, which is more than annoying. My university and several large shopping sites still do this. Please stop.
If I middle click a link which, if I left click it takes me to, or has another link which takes me to, another page, that action should open that page up in another tab. Repeat: that action should not do nothing, but open the page up in a new tab! It also should open the link and not something like the same page with a # appended to it or some Javascript in the address bar.
The danger of using frameworks that augment default objects
Monday, July 6th, 2009After a bit of thought it occurred to me just how dangerous using frameworks, like Prototype, which augment built-in objects in large-scale production projects. As many avid JS developers are most likely aware, the prototype inheritance model of the language allows for the extension of virtually any object in the language, user defined or otherwise. However, this can also have severe side effects if a browser developer decides to include a method of the same name as your framework of choice added to a built-in object some years back.
Take, for example, the venerable each function. Prototype extends enumerable objects such as arrays with this function in its prototype. e.g.
Array.prototype.each = function(f){
var i = 0;
for(; i < this.length; i = i + 1){
f(this[i],i);
}
}
Now imagine this code is called in thousands of places in your project. Let’s also assume before extending the object prototype such a library would also check for the existence of said function as to not overwrite default behavior e.g.:
if(!Array.each) {
…
}
Now imagine an A-grade browser’s newest version now includes the each method on collection objects by default but with either an argument omitted, or the argument order swapped. All of the code that you had written that depended on the augmented each function instead of the built-in each function will now no longer work in that browser, and you can’t very well force users to not use the latest version of IE, Safari, Firefox, or Opera because a decision was made some years back to use a framework which augments built-in objects.
This decision may now cost many thousands of dollars, if not more. Other JS frameworks such as YUI or jQuery seem like a much more sound choice in this respect. In my opinion, YUI is probably the better of the two choices as it is far easier to pick-up and master by developers of other, not necessarily web-centric languages. Yet in the scope of this rant, both are equally more sound than using something which could very easily and most likely inevitably break a few years down the road, costing many unnecessary man-hours, and perhaps dollars, to fix.