Geolocation data is wrong about confluence

[foolip]

I think this is probably caused by the interface object being found in Chrome via navigator.geolocation.constructor, and for example navigator.geolocation.constructor.prototype.clearWatch can be found via that object.

In Firefox, navigator.geolocation.constructor == Object. This is different from a similar case, navigator.permissions.constructor === Permissions.

In other words, it looks like in Chrome, [NoInterfaceObject] caused the interface object to not be exposed, where in Firefox there actually is no interface object, just the interface prototype object?

Starting from https://heycam.github.io/webidl/#NoInterfaceObject, I think step 12.3 of https://heycam.github.io/webidl/#interface-prototype-object is what accounts for Firefox's behavior, i.e. Firefox is correct.

Given that [NoInterfaceObject] is going away I doubt any engine is going to change, but what would a good workaround in Confluence be?

It's a bit odd IMHO to pick up any interface object however it is found, and I think this also explains why Chrome is claimed to support SpeechRecognition#start even though SpeechRecognition isn't exposed. webkitSpeechRecognition is, and I'm guessing the same mechanism explains this as why Geolocation#clearWatch appears to be supported in Chrome.

[foolip]

#200 is related to this, but the usual manifestation of [NoInterfaceObject] is that if we can't find an instance we just don't know about its support. For Geolocation, an instance is easily found at navigator.geolocation, but if we don't what kind of thing navigator.geolocation is, nothing ends up in the API catalog.

[bzbarsky]

I think this is probably caused by the interface object being found in Chrome via navigator.geolocation.constructor

Why not just find the proto (which is what you are really looking for here) via Object.getPrototypeOf(navigator.geolocation)?

i.e. Firefox is correct.

Yep. Safari also gets this right. Is there a Chrome bindings bug tracking this?

Given that [NoInterfaceObject] is going away

It is? That is, is there a concrete plan for it to go away for non-mixins where it's used without causing webcompat issues?

what would a good workaround in Confluence be?

Use Object.getPrototypeOf instead of looking at constructor.

For the general case of [NoInterfaceObject] and no instance, I agree that it's hard to do anything sane...