Re: revoking permission after granting permission

On Thu, 10 Nov 2011 11:46:54 +0100, Steve Block <steveblock@google.com>  
wrote:

> Hi Simon,
>
> Thanks for the comment. I think you might be misinterpreting the spec.
>
>> I think getCurrentPosition should only invoke at most one callback,  
>> either
>> success or error.
> That is already the case.

Not if the user first allows and then changes his mind and denies. The  
text in the spec clearly says that if the user denies, the error callback  
must be invoked. If you intend it to not be invoked in this case, the spec  
needs to say so.

> The text you quote means that if the user
> denies permission, the error callback must be called with code
> PERMISSION_DENIED, as opposed to with any other error code, even if
> other errors were encountered during the algorithm above. In all
> cases, the error callback is invoked at most once. The text is
> 'overriding' the algorithm, because we don't include the permission
> acquisition process in the algorithm itself.
>
> For both getCurrentPosition() and watchPosition(), the spec considers
> the acquisition of permission to be a one-time, single event, per
> method call. Any caching of user permissions is left up to the UA.
>
> You're right that the spec does not say anything about what to do if a
> permission is cached by the UA but then changed by the user while a
> call to getcurrentPosition() or watchPosition() is in progress. Your
> suggestion of stopping a watch seems reasonable, but I don't think
> it's necessary to include this in the spec.

I think it would be helpful for implementors if it was in the spec.

> Thanks,
> Steve


-- 
Simon Pieters
Opera Software

Received on Thursday, 10 November 2011 11:33:03 UTC