Intent to Implement and Ship: Remove [NoInterfaceObject] from Geolocation API interfaces

72 views
Skip to first unread message

Reilly Grant

unread,
Feb 13, 2019, 4:46:18 PM2/13/19
to blink-dev
rei...@chromium.org http://w3c.github.io/geolocation-api/ The [NoInterfaceObject] annotation is being removed from WebIDL. The Geolocation API specification has been updated to remove this annotation from all interfaces and perform the following renames to avoid polluting the global namespace with generic interface names, Geolocation -> NavigatorGeolocation Coordinates -> NavigatorGeolocationCoordinates Position -> NavigatorGeolocationPosition PositionError -> NavigatorGeolocationPositionError See heycam/webidl#430 for discussion of this change to WebIDL. Firefox: Public support Edge: No public signals Safari: No public signals Web developers: No signals Low, the interfaces were not previously exposed and the new names are specified to avoid collisions with existing code and specifications. None. Yes.
https://bugs.chromium.org/p/chromium/issues/detail?id=931847 https://www.chromestatus.com/features/5172722929762304 Yes.

Mike West

unread,
Feb 14, 2019, 3:37:19 AM2/14/19
to Reilly Grant, blink-dev
LGTM1, with the same note as the previous intent. We limit usage of the Geolocation API to secure contexts. While we don't mark `navigator.geolocation` as `[SecureContext]`, it seems reasonable to mark these new interfaces as such. Is that a change we could bring into the spec?

-mike


On Wed, Feb 13, 2019 at 10:46 PM Reilly Grant <rei...@chromium.org> wrote:
rei...@chromium.org http://w3c.github.io/geolocation-api/ The [NoInterfaceObject] annotation is being removed from WebIDL. The Geolocation API specification has been updated to remove this annotation from all interfaces and perform the following renames to avoid polluting the global namespace with generic interface names, Geolocation -> NavigatorGeolocation Coordinates -> NavigatorGeolocationCoordinates Position -> NavigatorGeolocationPosition PositionError -> NavigatorGeolocationPositionError See heycam/webidl#430 for discussion of this change to WebIDL. Firefox: Public support Edge: No public signals Safari: No public signals Web developers: No signals Low, the interfaces were not previously exposed and the new names are specified to avoid collisions with existing code and specifications. None. Yes.
https://bugs.chromium.org/p/chromium/issues/detail?id=931847 https://www.chromestatus.com/features/5172722929762304 Yes.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMbxgT25Q2w7PapuS%2BLGNRsFa0XOTRJT8CcKhoKpn1MqOQ%40mail.gmail.com.

TAMURA, Kent

unread,
Feb 14, 2019, 3:48:13 AM2/14/19
to Mike West, Reilly Grant, blink-dev
LGTM2.


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3De%2B97UJxX%2BRO2w%3DYRQ69T8NYiwQpfJKkzFBU2fQG0oM%2BA%40mail.gmail.com.


--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Feb 14, 2019, 5:50:41 AM2/14/19
to TAMURA, Kent, Mike West, Reilly Grant, blink-dev
LGTM3 with a few nits.

I filed https://github.com/w3c/geolocation-api/issues/25 for Mike's issue, not sure how to resolve it but I would consider some resolution blocking shipping this.

With owners hat off I sent https://github.com/w3c/geolocation-api/pull/23 to rename the interfaces while there's still a chance, but if the spec editors don't like it that's OK.


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEcJuo8S3EnKMbAHt6TD5qO6t8eextgODxaeMTNhgU%2BrQ%40mail.gmail.com.

Reilly Grant

unread,
Mar 21, 2019, 12:29:55 PM3/21/19
to Philip Jägenstedt, TAMURA, Kent, Mike West, blink-dev
As an update, w3c/geolocation-api#23 has been merged and so the change in interface names is now:

  Coordinates   -> GeolocationCoordinates
  Position      -> GeolocationPosition
  PositionError -> GeolocationPositionError

Philip, do you still want to block this change on introducing [SecureContext] in the Geolocation API spec or can that be handled separately?
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

Philip Jägenstedt

unread,
Mar 22, 2019, 8:10:12 AM3/22/19
to Reilly Grant, TAMURA, Kent, Mike West, blink-dev
Whether [SecureContext] is used determines what new interfaces objects are going to be exposed, and in particular first shipping them on non-secure contexts and then removing them seems unfortunate.

Is there more input needed on https://github.com/w3c/geolocation-api/issues/25, or just a matter of matter of the spec editor making a decision? It doesn't matter that much what is decided, so just rejecting the suggestion would be fine.
Reply all
Reply to author
Forward
0 new messages