What does basic support for a no-constructor or non-exposed interface mean?

[foolip]

Many interfaces have no constructor and instances can only be created by the browser itself, from trivial to complicated:

• Navigator: window.navigator is the way to get an object
• Selection: document.getSelection() and some other APIs return instances
• PerformanceEntry: performance.getEntries() returns an array of instances of some inheriting interface, like PerformanceResourceTiming

Historically many interface objects for interfaces like these haven't been exposed, or not exposed at the same time as the related API. For example, performance.webkitGetEntries() was added in
Chrome 25, performance.getEntries() was added in Chrome 28, but the PerformanceEntry interface object was only exposed in Chrome 29. What then, should the basic support statement for this interface in Chrome be? Two separate concerns:

• If the only API that could return an instance was prefixed, should the interface be marked somehow? api/PerformanceEntry.json now uses prefix in a few places but this is not really right.
• If the interface object wasn't exposed but it doesn't matter in the way that API is normally used, should it be flagged somehow? Adding notes for all cases like this will make the data more accurate, but likely also harder to understand.

[jpmedley]

Is this another argument for removing basic support? My inner windshield is fogging over just reading that.

[foolip]

I don't have enough experience with the breadth of data in BCD to have an opinion about that, but if removed one would be left with some interfaces that have no own methods and no constructor, like https://developer.mozilla.org/en-US/docs/Web/API/HTMLUnknownElement.

One could add "interface object exposed" to always have something, but I fear that information is meaningless in many cases, PerformanceEntry being a good example.

[jpmedley]

You should probably copy that comment to the basic support discussion.

[Elchi3]

window.navigator is a property and installed as "api.Window.navigator" in BCD it returns an object which is navigator and that is installed as "api.Navigator" in BCD.

What can happen here? Well, the property could be prefixed. So, the compat data "api.Window.navigator.__compat" should say that it is "window.weirdNavigator" instead. Further, the object that is returned by this property could also appear as "weirdNavigator", so that would need to be reflected in "api.Navigator.__compat". I guess this has happened in the webplatform, but if this has never happened, I could imagine to not have "api.Navigator.__compat", but only "api.Navigator.property", "api.Navigator.method", etc. So, that we only describe members of this not directly exposed interface and not the interface itself. Would this make sense?

I think "Selection: document.getSelection() and some other APIs return instances" is the same story as window.navigator, but correct me if I'm wrong.

For example, performance.webkitGetEntries() was added in
Chrome 25, performance.getEntries() was added in Chrome 28, but the PerformanceEntry interface object was only exposed in Chrome 29. What then, should the basic support statement for this interface in Chrome be?

Ugh, this sounds like a super confusing situation to me and I'm not sure I follow what you're saying. I might need to dig deeper into the Performance APIs to understand the context here.

If the only API that could return an instance was prefixed, should the interface be marked somehow? api/PerformanceEntry.json now uses prefix in a few places but this is not really right.

Yes. so if the object wasn't "webkitPerformanceEntry" then I think "prefix" is wrong in PerformanceEntry.json. If the property "performance.webkitGetEntries" was there, then this would be in Performance.json where the property "getEntries" has the prefix.

If the interface object wasn't exposed but it doesn't matter in the way that API is normally used, should it be flagged somehow? Adding notes for all cases like this will make the data more accurate, but likely also harder to understand.

It sounds like this won't be useful to anyone. Maybe dealing with more data will tell.

some interfaces that have no own methods and no constructor, like https://developer.mozilla.org/en-US/docs/Web/API/HTMLUnknownElement.

yeah, so this is currently "api.HTMLUnknownElement.__compat" and basically means "interface object exposed" (and exposed per standard way, or behind pref, or with prefix, etc).

I fear that information is meaningless in many cases, PerformanceEntry being a good example.

Again, maybe, we could omit "api.PerformanceEntry.__compat" and only have "api.PerformanceEntry.toJSON" and friends for these types of interfaces that aren't directly exposed and we don't care under which name they appear.

[foolip]

@vinyldarkscratch FYI this is a question that you may run into as well. Ideas?

[foolip]

I guess this has happened in the webplatform, but if this has never happened, I could imagine to not have "api.Navigator.__compat", but only "api.Navigator.property", "api.Navigator.method", etc. So, that we only describe members of this not directly exposed interface and not the interface itself. Would this make sense?

@Elchi3 funny enough, window.navigator actually does have a legacy alias in Chrome, Edge and Safari, where clientInformation===navigator is true. That's not a case of a "no-constructor or non-exposed interface" however, the Navigator interface is exposed. Representing this in BCD would be pretty straightforward if we wanted to: just add alternative_name entries in the support statements for api.Window.navigator. (It's the same interface, so nothing needs to be done for api.Navigator.)

I didn't give a good example of "non-exposed interface" in the issue. DOMRectList is such a case, it was originally decorated with [NoInterfaceObject] in Web IDL, but is now exposed. It doesn't have a constructor, but it's the return value of element.getClientRects(). It's been called ClientRectList in some engines, and is still exposed with that name in Edge 18.

In this case, I would argue that DOMRectList should be considered supported if element.getClientRects() is, regardless of what the name of the interface or if it is exposed. WDYT, does that make sense?

[foolip]

There was a real case in #3658 (comment).

There I argued that the non-exposed interface should be marked as supported, but with a note that the interface objected isn't exposed.

[Elchi3]

I'm closing this stalled issue. I think we found a handle on this topic. Feel free to re-open if this still present a problem.