Re: editor's draft updated

Hi Max,

Thanks for contributing the test suite. Some comments ...

> any field in the Position object from the specification
Note that latitude and longitude are not members of the Position
object - they are members of the Coords object, so the example call to
setupDevice above is inconsistent wit this statement.

> "x-empty": sets the device to simulate an error condition by reporting no data.
> "x-garbage": sets the device to simulate an error condition by reporting random corrupted data.
Perhaps we can clarify how these apply to implementations that don't
use a network request, or which use multiple sources of location
information.

> Test 00003: user denies access, check that no success callback is called, even if server returns a valid position
We should reword this to be agnostic to the source of location information

> Test 00011: call getCurrentPosition with null success callback, check if exception
The WebKit Geolocation implementation has a pretty comprehensive set
of tests for the parameter types which we could reuse here. See
http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Geolocation/argument-types-expected.txt

> Test 00020: user asked to approve, then asked to revoke, then check
> Test 00021: user asked to deny, then ask to change denial, then check
These should be optional and should ask the user to remember
permissions, as revocation is only required if permissions are
preserved beyond the lifetime of the current browsing context. This
means that they are identical to tests 00141 and 00142. Also, maybe
mention that a page reload is required

> Test 00129 (optional): trigger privacy prompt, then navigate away. Prompt should disappear
Is this a requirement? I don't think the spec mentions anything about this.

> Test 00030: call getCurrentPosition() with wrong type for third argument. Exception expected.
> Test 00133: call watchPosition() with wrong type for third argument. Exception expected.
I don't think that any type passed for the positionOptions argument
should cause an exception. The spec states that 'PositionOptions
objects are regular ECMAScript objects ...' and all of its properties
are optional. In JS, any type can be converted to a (perhaps empty)
object. The implementation should simply check for the presence of the
relevant properties, but never throw an exception. See the WebKit test
linked above.

> Test 00031: pass if getCurrentPosition returns withing 100ms
I'm not sure it's useful to test that the function returns within a
particular time limit, as the spec doesn't specify such a limit. I
think the important thing to check is that the callbacks are always
invoked asynchronously, rather than from within the function call.

> Test 00061: call watchPosition() with wrong type for third argument.
See above

> Test 00121: request cached value (timeout:0 and maximumAge not set) and check it is correct
> Test 00139: request cached value (timeout:0 and maximumAge set to a negative value) and check it is correct
If maximumAge is not set or set to a negative value, a default value
of 0 is used. This means that a cached position can never be returned,
so the implementation should fail with error TIMEOUT. See tests 00086
and 00088.

Thanks,
Steve

-- 
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Registered in England Number: 3977902

Received on Monday, 30 November 2009 18:04:16 UTC