Include accuracy property in 'locationfound' events.

[k-anon]

I am submitting a patch adding back the accuracy property to locationfound events originating from Map.Geolocation. I believe it is desirable that a plugin bolstering Leaflet's geolocation wrapper, such as the otherwise currently broken domoritz/leaflet-locatecontrol, would have access to this property in some way.

[tmcw]

Why the parseFloat here? In the spec this should be a numeric just like the rest. Is there some implementation that diverges?

[mourner]

Yeah, if it's really a number, it should have been fixed here #1755

[radicalbiscuit]

In Chrome 31.0.1650.57 on Windows 7, I'm encountering a pos.coords.accuracy whose type is string.

This might be due to the Chrome extension Manual Geolocation, which I'm using to test. It should also be noted that I'm using this with leaflet-locatecontrol.

At any rate, I place a breakpoint in _handleGeolocationResponse so I can inspect pos on each handling of geolocation. They're all numeric until I use Manual Geolocation to change the coordinates. All subsequent events then use a string pos.coords.accuracy. What's more, the latitude and longitude are also strings.

So, once again, I believe this to be related to Manual Geolocation, but it's worth noting that there is at least one implementation that allows non-numeric geolocation properties, and if that's the case, perhaps it might be warranted to explicitly include accuracy parsed or otherwise (as in #584), or do a wholesale inclusion of the geolocation properties.

[danzel]

Sounds more like a bug in manual geolocation.