[Webkit-unassigned] [Bug 39589] Add LayoutTestController methods to test DeviceOrientation

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 27 10:59:31 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=39589





--- Comment #21 from Steve Block <steveblock at google.com>  2010-07-27 10:59:30 PST ---
> To handle the Webcore client methods startUpdating() etc, you'd need to add
> more methods to WebDeviceOrientationClient or define a new interface which
> needs to be implemented by the WebKit embedder.
Exactly. My intent was the latter. Each platform would provide a WebDeviceOrientationClientFoo class for the 'real' client that implements WebDeviceOrientationClient. This is exactly the same as each platform does for other types that it exposes in its WebKit API. The only difference is that because both the 'real' implementation and the mock both implement WebDeviceOrientationClient, the mock can be switched in for testing.

> To simplify things, how about making DRT set a flag in WebKit to create mock
> objects instead of real ones? That way the embedder doesn't need to know the
> implementation (real or mock) of these objects. Access to the mock objects can
> be via an exported/public interface in WebKit and layoutTestController could
> call WebView after initialization to get a struct filled with all the mock
> object pointers.
Yes, you could do this. But as you point out, DRT still needs to get at the mock implementation to configure it, so each platform's WebKit layer would have to expose an interface for this mock. Also, it puts testing logic in the WebView layer, rather than keeping it in DRT. With my proposal, although the mock is exposed by the WebKit layer for use by the embedder, it doesn't add the need for any test logic to WebKit.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list