[webkit-dev] Adding window.layoutTestInspector

[Ojan Vafai]

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.

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.

Ojan

On Wed, Jul 14, 2010 at 10:16 PM, Hajime Morita <morrita at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100719/29f7538a/attachment.html>