Re: [webkit-dev] Updates on Chromium's content_shell
On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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. I think these are two separate issues: one is reusing the bindings for the test objects. This is what creating a TestRunner library would achieve. The other is to create the webkit objects without too egregious layering violations. This is a yet to solve problem :) -jochen -Darin 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 joc...@chromium.orgwrote: 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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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. I think these are two separate issues: one is reusing the bindings for the test objects. This is what creating a TestRunner library would achieve. The other is to create the webkit objects without too egregious layering violations. This is a yet to solve problem :) Agreed. -Darin 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 joc...@chromium.orgwrote: 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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Mon, Jul 16, 2012 at 9:25 AM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.orgwrote: On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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. I think these are two separate issues: one is reusing the bindings for the test objects. This is what creating a TestRunner library would achieve. The other is to create the webkit objects without too egregious layering violations. This is a yet to solve problem :) Agreed. Of more immediate concern is what to do about WebViewHost: http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/chromium/WebViewHost.h Do we want to share this code between DumpRenderTree and ContentShell? It looks like it might be necessary (especially for tests that dump callbacks of various sorts), but it wants to drag in things like TestNavigationController... 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 joc...@chromium.orgwrote: 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 aba...@webkit.orgwrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.org wrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev
[webkit-dev] Updates on Chromium's content_shell
Hey, 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%)! The biggest issue is that almost all testController methods are not yet implemented. If you're interested in running content_shell tests yourself, I've put together a small description here: http://dev.chromium.org/developers/testing/webkit-layout-tests/content-shell The next step will be to put an API between the test controllers defined for chromium's DRT, so content_shell can reuse those. best -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote: 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. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote: 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 -jochen - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote: 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
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. 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 joc...@chromium.orgwrote: 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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote: 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Fri, Jul 13, 2012 at 2:15 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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. 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 joc...@chromium.orgwrote: 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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updates on Chromium's content_shell
On Fri, Jul 13, 2012 at 2:24 PM, Adam Barth aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 2:15 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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 joc...@chromium.orgwrote: 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 aba...@webkit.org wrote: On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
