[ 
https://issues.apache.org/jira/browse/CB-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Bowser resolved CB-1462.
----------------------------

    Resolution: Fixed

Fixed with this commit: 
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=commit;h=772aedc263aa695e94c8dcd99aec05525b96f907
                
> False logic for native watchPosition/clearWatch
> -----------------------------------------------
>
>                 Key: CB-1462
>                 URL: https://issues.apache.org/jira/browse/CB-1462
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android, CordovaJS
>    Affects Versions: 2.0.0
>            Reporter: Sean Nikolai Fridman
>            Assignee: Joe Bowser
>              Labels: clearwatch, geolocation, watchposition
>             Fix For: 2.2.0
>
>
> *Note:* This is a bug in Android's native geolocation implementation. I can't 
> speak to what happens on other platforms. However, I get the feeling that the 
> bug is symptomatic of the JS implementation so it might very well exist on 
> more platforms.
> *Description:* When watchPosition is called, it first calls 
> getCurrentLocation (resulting in a native call to getLocation), then makes a 
> native call to addWatch. In Android, addWatch callback ids and getLocation 
> callback ids are stored in separate data structures. The bug I'm seeing is, 
> when I call clearWatch before the watch operation's implicit 
> getCurrentLocation callback is invoked, the watch operation is 
> removed/stopped in native, but the corresponding getCurrentLocation operation 
> is not.  This is not compliant with the W3C spec, which states that that no 
> further callbacks for the watch operation should be invoked. Worse, this 
> causes a bug on Android where GPS is never shut off! clearWatch stops the 
> location listener *iff* {{callbacks.size + watches.size == 0}}, and so if the 
> callback hadn't been invoked yet...
> _(Actually, skimming back through the code, I'm not seeing anywhere where the 
> location listener is stopped after a getCurrentPosition. Which may be another 
> issue... not sure.)_
> *And the potential issue in Javascript is this:* if native has no knowledge 
> of which getCurrentLocation callbacks are part of a watch operation and which 
> are just normal independent ones, how can it possibly remove the callback id 
> for the implicit getCurrentLocation operation on clearWatch? And how can it 
> possibly know if it can really stop listening for location updates?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to