On Fri, Jul 13, 2012 at 2:24 PM, Adam Barth <[email protected]> wrote:
> On Fri, Jul 13, 2012 at 2:15 PM, Darin Fisher <[email protected]> wrote: > >> On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth <[email protected]> wrote: >> >>> Yeah, EventSender is likely a good place to start. Here are some more >>> details about what I had in mind: >>> >>> 1) We'll need to create a new target that builds a TestRunner.a (or >>> LayoutTestController.a, whatever name is currently in fashion). This >>> target is allowed to depend on WTF, WebKit (via the WebKit API), and >>> probably webkit_support. >>> >>> 2) This target will contain LayoutTestController.cpp, EventSender.cpp, >>> and all the other code that's needed to support the objects we inject when >>> running LayoutTests. >>> >>> 3) To move code into this target, we'll need to abstract any >>> dependencies on the rest of DumpRenderTree into a delegate interface. For >>> example, EventSender has a #include "TestShell.h", which we'll need to >>> remove. Today, EventSender gets the WebView is by asking m_shell for it. >>> Instead, it will need to ask the delegate. >>> >>> One of the trickier things in this project will be WebViewHost. >>> TestRunner.a will need some object like that to subclass a bunch of WebKit >>> API clients, but the design might need to change a bit. I haven't studied >>> it carefully yet. >>> >> >> TestRunner.a could just provide the WebViewClient and WebFrameClient >> implementations. The delegate you mention could just be a createWebView >> function. >> >> When Jochen and I discussed this topic before, I suggested just adding >> CreateWebView to webkit_support, but as a delegate function seems even >> better. We'd probably like to minimize dependencies on webkit_support >> since that is Chromium specific. >> > > In addition to functions that talk with the WebKit API, there are also > functions that are more about controlling the test harness. For example, > dumpAsText and waitUntilDone will need some pathway for communicating with > the outside world besides WebKit API. > > Currently, this information is "pulled" by TestShell.cpp, so maybe we > don't need the delegate and can just have both DumpRenderTree and > ContentShell pull this information out of TestRunner.a via some interface. > I've created a meta bug to track this work: https://bugs.webkit.org/show_bug.cgi?id=91308 Adam > Once this is done, but DumpRenderTree and ContentShell can link >>> in TestRunner.a and implement the delegate. Hopefully the bulk of the >>> interactions will be between TestRunner.a and the WebKit API so that the >>> delegate will mostly be able providing the WebView and getting out of the >>> way. >>> >>> Adam >>> >>> >>> On Fri, Jul 13, 2012 at 1:56 PM, Jochen Eisinger <[email protected]>wrote: >>> >>>> What about keeping the discussion here, so others that might want to >>>> join the effort later can read it up? >>>> >>>> In general, I agree with your proposal. I guess starting with something >>>> small like EventSender might be a good first step. >>>> >>>> best >>>> -jochen >>>> >>>> >>>> On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth <[email protected]> wrote: >>>> >>>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger >>>>> <[email protected]>wrote: >>>>> >>>>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa <[email protected]>wrote: >>>>>> >>>>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I wanted to share some updates about content_shell (a >>>>>>>> multi-processed version of chromium's test shell): meanwhile, it is >>>>>>>> possible to generate pixel results. >>>>>>>> >>>>>>>> Out of 31431 tests that are executed on chromium-linux, 6234 did >>>>>>>> not match the expected results using content_shell, all others passed >>>>>>>> (80.17%)! >>>>>>>> >>>>>>> >>>>>>> This is a great news! Thanks a lot for working on this effort. Let >>>>>>> us know if you needed a help in implementing testRunner methods. >>>>>>> >>>>>> >>>>>> At this point, there are two things I could use help with: in >>>>>> general, moving methods to window.internals (and addressing the current >>>>>> shortcomings of that approach) helps a lot, as I can just instantiate >>>>>> this >>>>>> object in content_shell. >>>>>> >>>>>> The other thing is to work towards making layoutTestController (of >>>>>> chromium's DRT) a library. >>>>>> >>>>>> Adam mentioned a while ago that he'd be interested with helping with >>>>>> the latter as well >>>>>> >>>>> >>>>> Yes. The idea is to implement LayoutTestController in terms of the >>>>> WebKit API and a (hopefully simple) delegate. >>>>> Currently LayoutTestController knows too much about DumpRenderTree. That >>>>> will let us share the implementation of LayoutTestController and avoid >>>>> having to maintain yet another copy. >>>>> >>>>> Upstreaming the chromium-android port is at the top of >>>>> my priority list, but I should be able to help out with this work as well. >>>>> Should we talk off-list about how to approach this work? >>>>> >>>>> Adam >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
