[webkit-dev] Adding window.layoutTestInspector

[Hajime Morita]

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 <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
>>
>
>


-- 
morita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100720/4a9eeee5/attachment.html>