[
https://issues.apache.org/jira/browse/CB-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj reassigned CB-1462:
-----------------------------
Assignee: Joe Bowser (was: Filip Maj)
Assigning to Joe to resolve the native Android bits, if applicable.
> 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
