Hi Adam,
Hi Adam,
The proposal is to implement [3] which is a pure JS API and no new html
markup.
It will be implemented as a module as you suggested. The first patch in [4]
shows the first iteration of the implementation (
https://bugs.webkit.org/attachment.cgi?id=129679action=review ), though
Looks like it is stuck again, trying to land patch 62961 for the past 8
hours..
Is there any way to see the commit queue script output/console so we can
find out what is going wrong? At times it keeps retrying to land the same
patch multiple times and one of us removes the patch from the queue
is good or bad
(e.g., because the tree is broken or because it's checkout gets out of
date before it's able to actually commit).
Adam
On Wed, Aug 4, 2010 at 6:11 AM, Satish Sampath sat...@chromium.org
wrote:
Looks like it is stuck again, trying to land patch 62961 for the past 8
hours
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 a related note, there are a few features such as geolocation,
device orientation and speech which require input from hardware
devices. To test these using layout tests, we are considering passing
mock objects to WebCore and the mocks would either give fake device
data or just verify the
5 matches
Mail list logo
