Monday, January 14th, 2008

Acid 3 and the future of memory leaks

Category: CSS, JavaScript

John Resig has a couple of interesting posts on Acid 3 and memory leaks.

Firstly, with Acid 3 hopefully around the corner (but not yet ready!), John takes a look at the JavaScript side of the equation:

  • Array Elisions – Making sure that stuff like [,,] doesn’t have a length and [0,,1] has a length of 3.
  • Array Methods – Doing an unshift with multiple arguments .unshift(0, 1, 2), joining with an undefined argument .join(undefined).
  • Number Conversion – Banging against .toFixed(), .toExponential(), and .toPrecision() – especially with decimals and negative numbers.
  • String Operations – Negative indicies in substr .substr(-7, 3), character access by index "foo"[1] (part of the ECMAScript 4 spec).
  • Date – Making sure that certain method calls result in NaN results (like d.setMilliseconds(), with no arguments) and also enforcing +1900 year offsets.
  • Unicode in Identifiers – You can’t use escaped Unicode in identifiers, for example: eval("test.i\\u002b= 1;"); (that should throw an exception).
  • Regular Expressions/[]/ matches an empty set, /[])]/ should throw an exception, backreferences to non-existent captures, and negative lookaheads /(?!test)(test).exec("test test").
  • Enumeration – Make sure that object properties are enumerated in the correct order, make sure that you’re able to enumerate properties of certain names (toString, hasOwnProperty, etc.).
  • Function Constructors – The user should be able to set custom constructors on the .constructor property, .constructor should not be enumerable, and .prototype.constructor should be deletable.
  • Function Expressions(function test(){ ... })(); You should be able to call the function by name, within the function itself, you can’t directly overwrite the function name (only with a function-scoped variable), and ‘test’ isn’t leaked into the parent scope.
  • Exception Scope – Variables within the catch(){} should interact with the catch arguments primarily, followed by variables in an outer scope.
  • Assignment Expressionss = a.length = "123"; – a.length has a return value of 123 (the number) which is assigned to ‘s’, rather than the correct result of the string “123”.
  • EncodingencodeURI() and encodeURIComponent() must gracefully handle null bytes.

John then goes on to ask Will Memory Leaks Matter in 2009? where he paints an optimistic picture of the browser space in the future. We can only hope!

UPDATE: Ian has posted about Acid3.

Posted by Dion Almaer at 6:52 am
3 Comments

++++-
4 rating from 26 votes

3 Comments »

Comments feed TrackBack URI

The regular expression tests are partly bad and partly wrong. Bad because important issues like ES3’s prescription for the handling of backreferences to non-participating groups is considered by some (certainly myself, and probably most people familiar with the implications) to be a bug in the spec, and it is under discussion with TG1 group members if this will be fixed in ES4. At least one of the tests are wrong because ES3 does not support octal character indexes (tests act like e.g. “2” is octal character index 2). Rounding out the problems with the regex tests are its tests of the handling of e.g. /[]/. It includes a comment that “JS regexps aren’t like Perl”, but what it should really say about that is “JS regexps aren’t like practically every other regex flavor in existence although they claim to be based on Perl 5”. This particular issue is another thing that is under discussion with TG1 group members to be fixed in ES4.

Comment by Steven Levithan — January 15, 2008

Oops, my octal char code was eaten by the blog.

In any case, here’s a post related to one of the ES3 regex issues mentioned.

Comment by Steven Levithan — January 15, 2008

Have you emailed your problems with the tests over to Ian? Acid3 is by no means finalised yet.

Comment by Robin — January 16, 2008

Leave a comment

You must be logged in to post a comment.