Hi Ojan, thank you for the response! Let me summarize to make sure I understand the proposal: Expose a new object > to layout tests that is entirely in WebCore instead of in the DRT layer. > Then, only put things in layoutTestController that need to be at the WebKit > layer, e.g. notifyDone, waitUntilDone, etc. APIs that only need to touch > WebCore can live in WebCore. > > Exactly. I'd like to note that I have no intention to remove existing LayoutTestController APIs.
Overall, I like the idea of making it easier to add bits exposed just for > the sake of testing. Right now, it's really difficult to make simple > extensions to layoutTestController because they need to be made many times > over for each platform and there are many bits in layoutTestController that > only need to touch WebCore. Spelling/grammer markers is a good example. > setEditingBehavior is another good one. > Agreed. Exposing setEditingBehavior will be good for testing around editing selection. Re-defining enum on the WebKit layer is essentially redundant, and nice to avoid. I filed the bug for this: https://bugs.webkit.org/show_bug.cgi?id=42612 A patch will come shortly. -- morita > Ojan > > On Wed, Jul 14, 2010 at 10:16 PM, Hajime Morita <morr...@google.com>wrote: > >> Hi WebKit folks, >> >> I'm planning to add "window.layoutTestInspector" or something like that to >> DRT. >> And I'd like to hear your opinions. >> >> Background: >> >> Adding new method to LayoutTestController is hard. It >> - requires to add new WebKit API to each ports, when the method is to >> access WebCore. >> - requires to export extra WebCore symbols to access it from WebKit >> API implementation. >> - cannot use WebIDL so we need to write binding code manually. >> >> In some case, these steps are unavoidable. >> But in some other case, especially when we just want to access WebCore >> from the test, we might be able to skip these steps. >> >> A concrete example (my first motivation) is to test DocumentMarker >> for http://webkit.org/b/41423. >> DocumentMarker is WebCore's internal state and cannot access neither >> from DOM nor LayoutTestController. >> >> To test it, >> - the first idea is to use a pixel test. >> But it has some shortcomings as you know well. >> - The second idea is to extend render tree's dump format to >> include markers. But it is also platform-specific, >> and hard to interpret for humans. >> - The third idea is to add an API to LayoutTestController. >> But it is hard as I mentioned above. >> >> Is there another way? DocumentMarker is >> - WebCore's internal state, >> - so we don't need to inspect it except for testing purpose, >> - so it's better to avoid an extra WebKit API for that. >> >> I think there are similar demands other than for DocumentMarker, >> and it might be worth to invest a common way to handle them. >> >> Plans: >> >> To deal with such cases, we can add a test-specific object named >> LayoutTestInspector to window object. (The name is tentative.) >> With this object, We'll be able to write a LayoutTest like: >> >> if (window.layoutTestInspector) { >> var target = document.getElementById("target") >> var markerStr = layoutTestInspector.nodeMarkerString(target); >> if (markerStr == "Spelling:0:6") >> log("PASS"); >> else >> log("FAIL"); >> } >> >> Here is a plan to do this: >> >> - LayoutTestInspector will be defined in WebCore, >> and implemented as a usual DOM object using WebIDL. >> (placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp}) >> - window object will expose a non-enumerable >> windows.layoutTestInspector property >> for that. >> - Settings::m_enableLayoutTestInspector will control >> windows.layoutTestInspector >> availability. This flag should be true only on DRT. >> >> Tests with LayoutTestInspector would have several advantages: >> >> - Compared to LayoutTestController, >> we don't need to add new APIs to WebKit layer for test purpose. >> - Compared to LayoutTestController, >> we don't need to export extra WebCore APIs to WebKit layer. >> - Compared to Render-tree dump, >> the test can be more portable, focused and understandable. >> >> But there are some concerns: >> >> - WebCore need to have a test-specific code, that might be a waste of >> space. >> Test-specific WebKit APIs would have a same problem, though. >> - LayoutTestInspector may introduce some potential security risks. >> I have no idea about this area. >> >> Do you have any other use-cases or better approaches? >> Are there concerns I've missed? Do we have similar discussions in the >> past? >> Any ideas/suggestions are welcome. >> If there are no strong objections, I'll start to work on this. >> >> Regards. >> >> -- >> morita >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > -- morita
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev