GeolocationCoordinates.toJSON() - Should the spec cover how to handle NaN headings? · Issue #171 · w3c/geolocation (original) (raw)

I noticed the new GeolocationCoordinates.toJSON() method was added and immediately wondered how it would handle this edge case where heading can have a NaN value:

| <li>Initialize |coord|'s {{GeolocationCoordinates/heading}} | | ---------------------------------------------------------------- | | attribute in degrees, or `null` if the implementation cannot | | provide heading information. If the hosting device is stationary | | (i.e., the value of the {{GeolocationCoordinates/speed}} | | attribute is 0), then initialize the | | {{GeolocationCoordinates/heading}} to `NaN`. | | </li> |

NaN can't be represented in JSON (JSON.stringify(NaN) gives "null"), and null already has a special meaning for the heading property (implementation cannot provide heading information), so I think the conversion to JSON will be lossy unless heading gets special treatment.

It's probably also the case that the current implementation of this (at least in Chromium) will return an object from GeolocationCoordinates.toJSON() that contains a NaN value for heading. I'm not sure how much of an issue that is, but it feels weird to have a method named toJSON() return a value that can't actually be represented in JSON.

I've been working on a testing fake of the Geolocation API, and this test shows how I'm speculating the API will behave currently in this edge case: https://github.com/ezzatron/fake-geolocation/blob/8b7a5f3fc24c9d4d4e2d6a9406a5f0ddc0978724/test/vitest/geolocation-coordinates.spec.ts#L80-L101

Relates to #145, #147