|Summary:||Add tests to dump textual representations of entire HTML and SVG JS DOM trees|
|Product:||WebKit||Reporter:||Eric Seidel (no email) <eric>|
|Component:||Tools / Tests||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, ddkilzer, emacemac7, ggaren, mrowe, sam|
|OS:||OS X 10.4|
Description Eric Seidel (no email) 2006-09-18 06:06:21 PDT
Comment 1 Eric Seidel (no email) 2006-09-18 06:06:59 PDT
Created attachment 10626 [details] DRT seems to not be dumping fully, but this at least includes the full tests
Comment 2 Eric Seidel (no email) 2006-09-18 06:40:05 PDT
Created attachment 10627 [details] A complete version of the tests (with full results)
Comment 3 Eric Seidel (no email) 2006-09-18 06:40:52 PDT
One warning (which might actually prevent these from landing) is that these tests are quite slow to run. The html-names test takes almost 40 seconds iirc.
Comment 4 Eric Seidel (no email) 2006-09-18 15:50:31 PDT
We could/should probably change this to sort all the properties before printing, as well as print out the default values of most properties.
Comment 5 Eric Seidel (no email) 2006-09-22 01:35:04 PDT
22.05 secs: fast/js/html-properties.html 9.47 secs: fast/js/svg-properties.xhtml
Comment 6 Alexey Proskuryakov 2006-09-22 02:03:48 PDT
(In reply to comment #5) > 22.05 secs: fast/js/html-properties.html > 9.47 secs: fast/js/svg-properties.xhtml Assuming the results are from an MBP, that would translate into minutes on my development machine (G4), I guess.
Comment 7 Eric Seidel (no email) 2006-09-22 02:28:13 PDT
Comment 8 Eric Seidel (no email) 2006-09-22 04:51:16 PDT
Created attachment 10704 [details] Better version of the tests (actually includes results too) I've now removed window-properties.html, realizing that it was redundant (its content is covered by the svg-properties and html-properites tests already). I've also added printing of "default" values. (Since each of these dom elements is made new, all of its properties should hold the proper default values.) These tests run with the following timing on my machine: 27.17 secs: fast/js/html-properties.html 17.50 secs: fast/js/svg-properties.xhtml HTML unfortunately duplicates many, many properties on the elements themselves, instead of using prototypes, thus causing redundant printing.
Comment 9 Eric Seidel (no email) 2006-09-22 04:52:49 PDT
Created attachment 10705 [details] Just the new test files (much easier to read)
Comment 10 Eric Seidel (no email) 2006-09-22 04:55:27 PDT
I'm adding ggaren as a CC on this bug, as these tests could be very useful for comparing DOM implementations between Safari and other browsers.
Comment 11 David Kilzer (:ddkilzer) 2006-09-22 10:12:30 PDT
(In reply to comment #5) > 22.05 secs: fast/js/html-properties.html > 9.47 secs: fast/js/svg-properties.xhtml Has anyone profiled these tests with Shark?
Comment 12 Geoffrey Garen 2006-12-23 22:51:38 PST
Comment on attachment 10704 [details] Better version of the tests (actually includes results too) My main comment is that having a test like this is great, but I don't know if it should be part of the regular layout tests. Unlike the table tests, it only tells us if we've completely broken access to a certain property, not if the property works or not. Since it tells us what the DOM is, rather than whether the DOM works, this test seems more like a tool we should use periodically than a layout test. Comments about the code: You probably know this, but the test still doesn't cover things like events, collections, selection, and parts of the CSS dom. This output is a little confusing: +a.__proto__(HTMLAnchorElement).__proto__(HTMLElement) : object (HTMLElement) Is 'a' the HTMLAnchorElement, or a.__proto__? What does the colon mean? How does "(HTMLElement)" differ from "object (HTMLElement)?" Can't you replace isPropertyDefinedOnPrototype was just using the "in" operator on the prototype or testing for the existence of proptotype[property]? If you're trying to optimize by skipping to the Object prototype first, (a) I'd be surprised to learn that doing so was more efficient than a lookup inside the engine; (b) why not just test the Object prototype first, and then use the prototype chain? PrintProperties shoud be "printProperties," since it's not a constructor. Also, it's odd to have a verb for an object's name. "propertyPrinter" is a noun alternative. r=me I think this test belongs in WebKitTools.
Comment 13 Maciej Stachowiak 2007-01-24 20:34:16 PST
They could be useful as layout tests to detect cases where we've accidentally changed the DOM, but sounds like that benefit might not be worth the time in normal layout test runs. On the other hand, it might be just fine for the buildbot. It would sort of be an unintended DOM API change detector.
Comment 14 Mark Rowe (bdash) 2007-07-06 04:48:17 PDT
Are we going to land this change or not? It's been sitting in the commit queue for *nine months*.
Comment 15 Alexey Proskuryakov 2008-07-31 05:55:06 PDT
Judging from experience with other "dump everything" tests (e.g. window-properties.html), they turn into maintenance nightmare, and don't catch real bugs. So, I suggest to WONTFIX this.
Comment 16 David Kilzer (:ddkilzer) 2008-07-31 08:36:43 PDT
(In reply to comment #15) > Judging from experience with other "dump everything" tests (e.g. > window-properties.html), they turn into maintenance nightmare, and don't catch > real bugs. So, I suggest to WONTFIX this. I don't see window-properties.html so much as a maintenance nightmare as I do the "canary in the coal mine" that tells you when a property changed unexpectedly. What bugs will these new tests catch that the window-properties.html did not?
Comment 17 Alexey Proskuryakov 2008-07-31 10:01:49 PDT
Well, window-properties.html is broken on the buildbot quite often, and never for a good reason. Besides, it doesn't work well with features that can be turned on and off.
Comment 18 Eric Seidel (no email) 2008-07-31 10:50:09 PDT
Another way to solve this sort of "canary" test is to mark them as auto-updating. Such that the build bot auto-updates the results if they ever change. At least then it's easy to see the current state of things. Or better yet, we just make the bots auto-update and commit any results which don't exists. Then, to fix this particular test (or any test) when failing, you just svn rm the results). That still doesn't address the "fails for people who compile with different sets of flags" but I still like this kinda of canary test.