Introducing a new test category: JS Extras

[GoogleCodeExporter]

There are a number of JavaScript features beyond the ES5 spec that some
browsers support and others do not, such as __proto__, the trailing comma
in object literals, etc. It would be nice to know at which point certain
browsers started to adopt these features, and Browserscope seems like an
excellent way to collect that data.

The attached patch file introduces the new category. I concede that it's
lacking some comments, but I'll happily add them if this category is accepted.

I also added a note in the README about an extra step required to create a
new category, as well as the line "var CLOSURE_NO_DEPS = true;" in
test_driver.html which will prevent Browserscope from trying to load
deps.js for Closure Library (which it doesn't need, but creates an extra
request and a 404).

Original issue reported on code.google.com by bolinf...@gmail.com on 25 Jan 2010 at 3:13

Attachments:

• js_extras.diff

[GoogleCodeExporter]

Hey Michael, I'll take a look at your patch - thank you! 
RE: js extras, have you had a look over the currently disabled, but in-beta, 
jskb (JS 
Knowledge Base) category? While the goals sound slightly different, your tests 
might 
really belong in this category thematically. Maybe have a quick look at that 
and tell 
me what you think - and then we'll ping that category's author Mike Samuel.

Original comment by els...@gmail.com on 25 Jan 2010 at 6:28

[GoogleCodeExporter]

Sorry, I haven't had a chance to look at JSKB yet, but it's certainly fine if 
the
tests are a more appropriate fit there -- I'm just interested in the 
information,
however it is gathered!

Original comment by bolinf...@gmail.com on 27 Jan 2010 at 12:26

[GoogleCodeExporter]

Cool - let's CC Mike Samuel on this bug as well, but whenever you get a chance, 
take a 
look at his tests to see if A) any of your tests are already among jskb and B) 
if you 
think it makes sense among jskb

JSKB tests:
http://www.browserscope.org/jskb/about
http://www.browserscope.org/jskb/test

Original comment by els...@gmail.com on 27 Jan 2010 at 12:42

[GoogleCodeExporter]

Hi Bolin,

>  such as __proto__, the trailing comma in object literals, etc.

JSKB captures both these pieces of info.

See http://www.browserscope.org/jskb/json?ua=Firefox which should have data 
like:
{
...
"[,].length === 1": true,
"__proto__ in {}": true,
}

Original comment by mikesamuel@gmail.com on 28 Jan 2010 at 12:54

[GoogleCodeExporter]

If you want to see the specific tests in JSKB, look at the big giant dict in
http://code.google.com/p/browserscope/source/browse/trunk/categories/jskb/ecmasc
ript_snippets.py
.

The portions relevant to your examples are line 314
    { CODE: "[,].length === 1", NAME: 'ArrComma', VALUES: BOOL_VALUES,
      DOC: 'Is a trailing comma in an array ignored?',
      SUMMARY: 'Trailing comma', GOOD: ('true',),
      ABBREV: { 'false': '[,]' } },
and line 302
    { CODE: 'typeof ({}).__proto__', NAME: 'ProtoMem',
      VALUES: TYPEOF_VALUES, DOC: 'Is __proto__ defined for objects?',
      SUMMARY: '__proto__', ABBREV: {} },

Original comment by mikesamuel@gmail.com on 28 Jan 2010 at 12:56

[GoogleCodeExporter]

For the tests in your diff, I think all are presently covered except:
(1) forEachIn.  Would the snippet "eval('for each (var k in []);')" work ?
(2) base64 enc.  Would "typeof atob" work?
(3) lambdaReplace.  Would " 'x'.replace(/x/, function () { return 'y' }) == 'y' 
" work?

Incidentally, are any browsers likely to introduce support "for each in" given 
that
E4X is now officially dead?

Original comment by mikesamuel@gmail.com on 28 Jan 2010 at 1:05

[GoogleCodeExporter]

Hi Mike, sorry, I responded via Gmail and I guess that didn't propagate back to 
the
bug report:

"Hi Mike, yes, I think your proposals would be okay. They're not as strict as my
tests, but I think they'll get the job done.

I'm not sure if other browsers are going to support "for each in", but I think 
it's
still nice to know what you can use when creating a Firefox extension."

Original comment by bolinf...@gmail.com on 4 Feb 2010 at 2:05

[GoogleCodeExporter]

Yes.  They are less strict.  That's partly intentional.  My goal is to provide 
useful info 
to JS compilers, not to come up with a conformance test suite.

The more concise, the easier it is for optimizers to use this info to optimize 
feature 
tests.  Feature testing code is more likely to look like
  if (typeof atob === 'function') { ... }
than
  if (typeof atob === 'function' && atob('Zm9v') === 'foo') { ... }

Original comment by mikesamuel@gmail.com on 4 Feb 2010 at 2:12

[GoogleCodeExporter]

I think http://code.google.com/p/browserscope/source/detail?r=504 should 
subsume 
the patches functionality so I'm going to mark this bug fixed.

If you wish to resurrect this patch, please reopen the bug with a new patch 
that doesn't 
cut JSKB and HTML5 out of app.yaml.

Original comment by mikesamuel@gmail.com on 4 Feb 2010 at 4:41

• Changed state: Fixed