Re: [webkit-dev] Sharing WebKit mocks across platforms
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath <satish@google.com> wrote:
With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish
On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth <abarth@webkit.org> wrote:
Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable.
This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there.
Adam
On Wed, Jul 28, 2010 at 11:30 AM, Steve Block <steveblock@google.com> wrote:
I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock.
An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ...
mWebView.getDeviceOrientationClientMock().setOrientation(...);
To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.)
Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type.
If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling.
Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure?
You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603
I'd appreciate any feedback you may have.
Thanks, Steve
-- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. J On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth <abarth@webkit.org> wrote:
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions.
Adam
On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath <satish@google.com> wrote:
With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish
On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth <abarth@webkit.org> wrote:
Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable.
This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there.
Adam
On Wed, Jul 28, 2010 at 11:30 AM, Steve Block <steveblock@google.com> wrote:
I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock.
An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ...
mWebView.getDeviceOrientationClientMock().setOrientation(...);
To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.)
Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type.
If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling.
Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure?
You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603
I'd appreciate any feedback you may have.
Thanks, Steve
-- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
I suspect, originally, layoutTestController was more about poking DumpRenderTree than about poking WebCore. Adam On Fri, Jul 30, 2010 at 2:42 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today.
On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth <abarth@webkit.org> wrote:
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions.
On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath <satish@google.com> wrote:
With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish
On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth <abarth@webkit.org> wrote:
Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable.
This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there.
Adam
On Wed, Jul 28, 2010 at 11:30 AM, Steve Block <steveblock@google.com> wrote:
I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock.
An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ...
mWebView.getDeviceOrientationClientMock().setOrientation(...);
To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.)
Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type.
If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling.
Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure?
You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603
I'd appreciate any feedback you may have.
Thanks, Steve
-- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. J
The world was very different back then. :) - WebKit was only on one platform (Mac). - Much of what is now WebCore, was up in WebKit. - (As Adam also mentions) LayoutTestController was initially more about faking click events, etc. A lot has changed in 6, 7, 8.. whatever it is now... years. I agree, I think that a better modern solution would be to move huge chunks of DRT into WebCore itself, and have them compiled in Debug and Release builds and removed from Production builds (controlled by some flag). WebKit ports would just pipe another method "exposeTestObjectsToJavaScript" or similar up to the various DRT ports. We could get rid of a huge amount of boiler-plate DRT code (much of which deals with type conversions). -eric
On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth <abarth@webkit.org> wrote:
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions.
Adam
On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath <satish@google.com> wrote:
With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish
On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth <abarth@webkit.org> wrote:
Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable.
This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there.
Adam
On Wed, Jul 28, 2010 at 11:30 AM, Steve Block <steveblock@google.com> wrote:
I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock.
An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ...
mWebView.getDeviceOrientationClientMock().setOrientation(...);
To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.)
Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type.
If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling.
Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure?
You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603
I'd appreciate any feedback you may have.
Thanks, Steve
-- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Jul 30, 2010 at 7:55 PM, Eric Seidel <eric@webkit.org> wrote:
On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today.
The world was very different back then. :)
- WebKit was only on one platform (Mac). - Much of what is now WebCore, was up in WebKit. - (As Adam also mentions) LayoutTestController was initially more about faking click events, etc.
A lot has changed in 6, 7, 8.. whatever it is now... years.
I agree, I think that a better modern solution would be to move huge chunks of DRT into WebCore itself, and have them compiled in Debug and Release builds and removed from Production builds (controlled by some flag).
WebKit ports would just pipe another method "exposeTestObjectsToJavaScript" or similar up to the various DRT ports.
We could get rid of a huge amount of boiler-plate DRT code (much of which deals with type conversions).
Mr. Seidel, we might have found our next project. Adam
I'd be happy to help where I can too, and can migrate the existing Geolocation/DeviceOrientation/SpeechInput mocks to use the new pattern. Please CC me on any bugs you create. Steve
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. There might still be the need for some plumbing though. In the case of DeviceOrientation and SpeechInput, we're mocking a client which is provided by WebKit. Even though the mock implementation happens to live in WebCore, it's instantiated and owned by the WebKit layer. So in order for LayoutTestController to configure the mock (eg layoutTestController.setMockOrientation(...)), we need to route calls from the WebCore LayoutTestController up to WebKit. I guess you could use a new LayoutTestControllerClient. I think you're right though that this could be done without the need for type conversions, as none of this is exposed in the WebKit API.
Steve
On Fri, Jul 30, 2010 at 2:56 AM, Steve Block <steveblock@google.com> wrote:
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions.
There might still be the need for some plumbing though. In the case of DeviceOrientation and SpeechInput, we're mocking a client which is provided by WebKit. Even though the mock implementation happens to live in WebCore, it's instantiated and owned by the WebKit layer.
Why not instantiate and own the object in WebCore? In fact, perhaps the testController (or whatever we want to call the WebCore test helper object) so both instantiate and own the client.
So in order for LayoutTestController to configure the mock (eg layoutTestController.setMockOrientation(...)), we need to route calls from the WebCore LayoutTestController up to WebKit. I guess you could use a new LayoutTestControllerClient. I think you're right though that this could be done without the need for type conversions, as none of this is exposed in the WebKit API.
Yep. Adam
participants (5)
-
Adam Barth
-
Eric Seidel
-
Jeremy Orlow
-
Martin Robinson
-
Steve Block