[webkit-dev] Adding window.layoutTestInspector

Hajime Morita morrita at google.com
Wed Jul 14 22:16:31 PDT 2010


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


More information about the webkit-dev mailing list