ScreenDetails defines "currentScreens" getter steps

[reillyeon]

The currentScreens getter steps are currently defined as "return the ScreenDetailed object associated with the Window associated with this." This should be "currentScreen" to match the WebIDL and should be explicit that it returns the "current screen" of the Window object associated with this.

This raises the related question of whether the ScreenDetailed object returned by this attribute should be the same as one of the objects in the sequence returned by the screens attribute and whether these objects should be === comparable. This is something we do for APIs like navigator.serial.getPorts() and navigator.serial.onconnect so that it is easy to compare the objects involved to see whether the state has changed without having to rely on heuristics like comparing the screen geometry or labels. As implemented in Chromium it appears that this is the case for this API.

[quisquous]

This raises the related question of whether the ScreenDetailed object returned by this attribute should be the same as one of the objects in the sequence returned by the screens attribute and whether these objects should be === comparable

We had a discussion about this in #49 about whether currentScreen should be [SameObject] and decided against it partially so that we could have the property of currentScreen being === comparable to objects in screens. Is there a good way to specify that in the spec to have that as a stronger guarantee?

[reillyeon]

You're right, what I'm looking for here is something less strict than [SameObject] but more useful because making currentScreen === comparable to objects in screens seems like the most developer-friendly design. I think the way to accomplish that is by defining the getter steps explicitly and using internal slots to hold the exact object instances which should be returned by each accessor's getter steps.

In addition to documenting this behavior in the algorithms a note or example explaining the intent would be helpful to make this aspect of the design clear to implementers.

[michaelwasserman]

I attempted to define this a bit better and add a couple notes in #87, but I'm not exactly sure how to use internal slots to define an array and specify which exact {{ScreenDetailed}} object in {{ScreenDetails/screens}} represents the [=/current screen=] of a {{Window}}. I hope this might be sufficient for now, and that we can refine this further at a later date.

[reillyeon]

Your PR is a good starting point. You can probably hand-wave the necessary behavior by adding a note in the algorithm that if a ScreenDetailed instance already exists to represent the screen that should be used. You can formalize this by explicitly declaring when new ScreenDetailed instances get created and added to a [[screens]] internal slot when a screen is connected and removed from the internal slot when they are disconnected.