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
