SoC: JavaScript implementation

[Piotr Caban]

On Monday 30 March 2009 22:21:32 Reece Dunn wrote:
> > - Look at Wine jscript.dll related bugs.
> > These would be: 15432, 15582, 16208, 16594 and 17152. I'm not sure if
> > they are JScript or MSHTML bugs yet as they require deeper analyze. I
> > will fix their JScript part of problem.
>
> You might also want to look at 13459 ("Oberon game launcher (incl.
> buttons) does not work"). This is related to 16594 ("Oberon game
> launcher does not show the buttons to launch the game.").
>
> In the original 13459, wine would render the buttons (but would render
> them funny), but they were unusable - that is clicking on them did
> nothing. Since the commit located in 16594, only the background is
> displayed (hence them being different defects).
>
> It would be nice to have this working, as this is the only thing
> holding up Oberon games from working (well, around 50% of them, anyway
> :) ).

Thanks for pointing it out. I've missed 13459 because there was no 
evidence that it's JavaScript related. I will surely look at it.

> > - Fix W3School (http://www.w3schools.com/js/default.asp) JavaScript
> > examples.
> > These seem to be a nice tests for me. They test commonly used APIs in
> > real life scenarios. I believe that if these tests work, most web sides
> > should work as well.
>
> This is a good idea. I also wonder how we can test the mshtml
> DOM/scripting? I suspect that this is where most applications will
> trip up. (Unless they are hitting a jscript bug first!)

MSHTML currently uses Gecko JavaScript engine as well as DOM 
implementation for this site, so it will work the same way as it does on 
Firefox.

> > - Test complex web pages
> > Pages like GMail or Google Office would be really cool to have working
> > with our JavaScript. Unfortunately I'm afraid that it may be too much
> > work for SoC to fix them. I'd like to do some testing and find some
> > complex web pages that I could use as tests.
>
> These are also likely to have issues when manipulating/navigating html
> pages using the mshtml DOM API - i.e. the HTML DOM referenced in
> http://www.w3schools.com/htmldom/dom_reference.asp.

That's why I plan to use native IE for testing. This way I won't have to 
care about DOM implementation and I will be able to concentrate on 
JavaScript.

> > If someone has any more ideas about tests I'm open for suggestions.
>
> You might want to try adding some JSON ("Java Script Object Notation")
> examples - http://www.json.org/. The website even includes some JSON
> parsers released under the Public Domain! They would make interesting
> stress tests.
>
> Also, if you are feeling adventurous, there are some ray tracing
> examples written in JavaScript!
>     http://www.chromeexperiments.com/detail/javascript-canvas-raytracer/
> (the link says that it is out of bandwidth!)
> NOTE: There are several (now closed) Firefox bugs that contain various
> forms of this, which can be found on bugzilla - the Firefox bugzilla
> site is being slow for me, so I cannot look up the specific bugs at
> the moment.
>
> And more generally http://www.chromeexperiments.com/browse/.
>
> You might also want to look at some of the javascript benchmark suites
> like SunSpider and the V8 testsuite.

This are nice ideas, however after testing with a few different test 
sites, I decided that w3school would be the best. I may go back to 
others when it's done. Raytracers are not really interesting, because 
they don't use much APIs, so they test only core engine performance. The 
same applies to most of Firefox tests that I found in their source tree. 
The main problem with running V8 testsuite is that we want to be 
compatible with MS JScript implementation. This tests show the right 
implementation :-)

Thanks,
    Piotr