Bug 178173 – [Geolocation] Expose Coordinates.floorLevel

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Chris Dumez]

Expose Coordinates.floorLevel via Geolocation API.

[Chris Dumez]

<rdar://problem/34918936>

[Chris Dumez]

Created attachment 323428 [details]
WIP Patch

[Chris Dumez]

Created attachment 323430 [details]
WIP Patch

[Chris Dumez]

Created attachment 323432 [details]
WIP Patch

[Ryosuke Niwa]

Comment on attachment 323432 [details]
WIP Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323432&action=review

> Source/WebCore/Modules/geolocation/Coordinates.idl:38
> +    readonly attribute unrestricted double? floorLevel;

Please hide this behind a runtime flag because we don't have floor level information on macOS (and other platforms like Windows).

[Chris Dumez]

(In reply to Ryosuke Niwa from comment #5)
> Comment on attachment 323432 [details]
> WIP Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=323432&action=review
> 
> > Source/WebCore/Modules/geolocation/Coordinates.idl:38
> > +    readonly attribute unrestricted double? floorLevel;
> 
> Please hide this behind a runtime flag because we don't have floor level
> information on macOS (and other platforms like Windows).

I'll add a Runtime flag but note that a lot of the coordinates attributes (heading / speed, ...) are optional and only provided on some specific platforms. This is the reason why those attributes are nullable, they are null if the platform does not support providing them.

[Chris Dumez]

Created attachment 323448 [details]
WIP Patch

[Chris Dumez]

Created attachment 323449 [details]
Patch

[Build Bot]

Comment on attachment 323449 [details]
Patch

Attachment 323449 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/4827509

New failing tests:
imported/w3c/web-platform-tests/XMLHttpRequest/open-url-worker-origin.htm

[Build Bot]

Created attachment 323460 [details]
Archive of layout-test-results from ews102 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-elcapitan  Platform: Mac OS X 10.11.6

[Chris Dumez]

(In reply to Build Bot from comment #9)
> Comment on attachment 323449 [details]
> Patch
> 
> Attachment 323449 [details] did not pass mac-ews (mac):
> Output: http://webkit-queues.webkit.org/results/4827509
> 
> New failing tests:
> imported/w3c/web-platform-tests/XMLHttpRequest/open-url-worker-origin.htm

This failure is unrelated.

[Chris Dumez]

Comment on attachment 323449 [details]
Patch

Clearing flags on attachment: 323449

Committed r223211: <https://trac.webkit.org/changeset/223211>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Chris Peterson]

In addition to setting floorLevel, this patch's GeolocationPosition class for iOS [1] initializes altitude, altitudeAccuracy, heading, and speed but the macOS GelocationPosition class [2] does not.

Is not supporting altitude, altitudeAccuracy, heading, and speed on macOS an intentional design decision or an oversight?

[1] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/geolocation/GeolocationPosition.h

[2] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/geolocation/ios/GeolocationPositionIOS.mm

[Chris Dumez]

(In reply to Chris Peterson from comment #14)
> In addition to setting floorLevel, this patch's GeolocationPosition class
> for iOS [1] initializes altitude, altitudeAccuracy, heading, and speed but
> the macOS GelocationPosition class [2] does not.
> 
> Is not supporting altitude, altitudeAccuracy, heading, and speed on macOS an
> intentional design decision or an oversight?
> 
> [1]
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/
> geolocation/GeolocationPosition.h
> 
> [2]
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/
> geolocation/ios/GeolocationPositionIOS.mm

I do not believe this is accurate, the following C API is available to the client application to provide the location on Mac:
WK_EXPORT WKGeolocationPositionRef WKGeolocationPositionCreate(double timestamp, double latitude, double longitude, double accuracy);
WK_EXPORT WKGeolocationPositionRef WKGeolocationPositionCreate_b(double timestamp, double latitude, double longitude, double accuracy, bool providesAltitude, double altitude, bool providesAltitudeAccuracy, double altitudeAccuracy, bool providesHeading, double heading, bool providesSpeed, double speed);
WK_EXPORT WKGeolocationPositionRef WKGeolocationPositionCreate_c(double timestamp, double latitude, double longitude, double accuracy, bool providesAltitude, double altitude, bool providesAltitudeAccuracy, double altitudeAccuracy, bool providesHeading, double heading, bool providesSpeed, double speed, bool providesFloorLevel, double floorLevel);

Notice that the last one can be used to provide heading / speed and altitude. The implementation looks like so:
WKGeolocationPositionRef WKGeolocationPositionCreate_c(double timestamp, double latitude, double longitude, double accuracy, bool providesAltitude, double altitude, bool providesAltitudeAccuracy, double altitudeAccuracy, bool providesHeading, double heading, bool providesSpeed, double speed, bool providesFloorLevel, double floorLevel)
{
    WebCore::GeolocationPosition corePosition { timestamp, latitude, longitude, accuracy };
    if (providesAltitude)
        corePosition.altitude = altitude;
    if (providesAltitudeAccuracy)
        corePosition.altitudeAccuracy = altitudeAccuracy;
    if (providesHeading)
        corePosition.heading = heading;
    if (providesSpeed)
        corePosition.speed = speed;
    if (providesFloorLevel)
        corePosition.floorLevel = floorLevel;

    auto position = WebGeolocationPosition::create(WTFMove(corePosition));
    return toAPI(&position.leakRef());
}

I think Safari may only provide timestamp / latitude / longitude / accuracy though. Is this your issue? If so, I would suggest filing a bug via https://developer.apple.com/bug-reporting/ since this would be a Safari issue, not a WebKit issue.

[Chris Peterson]

(In reply to Chris Dumez from comment #15)
> I think Safari may only provide timestamp / latitude / longitude / accuracy
> though. Is this your issue? If so, I would suggest filing a bug via
> https://developer.apple.com/bug-reporting/ since this would be a Safari
> issue, not a WebKit issue.

Yes, that's the issue that lead me here. I'll report a Safari issue. Thanks!