What is the purpose of isConnected and do we need it?

[ddorwin]

Currently:

• The definition of isConnected is:

  The isConnected attribute MUST return the VRDisplay's connected state.

• Connected state does not appear to be defined.

What is the connected state and how are applications supposed to use this attribute?

• Is this only intended to report the loss of connection (vs., for example, allow advertising devices that are supported/configured but not connected)?
• Is reconnection of a lost connection possible?
• Are apps expected to check this or respond to it?

Regardless of whether there is such a property, the behavior of all APIs on the object upon disconnection must be defined. That might make this attribute unnecessary.

Depending on the answers, it may make sense to replace or remove this attribute. If some type of notification is useful, a One-Time "Event" promise may be appropriate.

[RafaelCintron]

For Edge, the implementation will be as follows:

So long as an HMD is plugged in, we will return true for isConnected

If an HMD is unplugged, isConnected will return false for the rest of the lifetime of the VRDisplay instance. onvrdisplaydisconnect will be raised with the VRDisplay instance as the event target. While in a disconnected state. the VRDisplay will reject all promises returned to requestPresent and exitPresent. submitFrame will throw a security exception. requestAnimationFrame will succeed but no callback will ever be called. getFrameData will return false. All of the other informational attributes (displayName, depthNear/Far, etc) will continue to return the same values as before.

If the exact same HMD is subsequently plugged in, we will create a brand VRDisplay instance and raise the onvrdisplayconnect event with the new VRDisplay instance as the event target. isConnected will return true so long as the display is plugged in.

So, in summary, isConnected returns whether the HMD is plugged into the computer. The web developer can get the same information by hooking the events. Apps will definitely need to respond to device disconnection and cease interaction with the VRDisplay instance. Up to developer whether they poll isConnected or hook onvrdisplaydisconnect.

[ddorwin]

Thanks. We should make sure such behavior is documented in algorithms so it is predictable across implementations. Should we discuss* that in this issue or a separate one? I think whether we need to expose isConnected remains an open question. Note that specs can track and reference an internal is connected state variable without actually exposing an attribute.

• One specific question I have for this discussion is why submitFrame would throw a security exception (do you mean "SecurityError"?). Would "InvalidStateError" or "AbortError" make more sense?

[AlbertoElias]

I think if Edge will be working around events, and just implement isConnected because it's in the spec, and the events are stable, it makes isConnected redundant and less useful.

[RafaelCintron]

Re: submitFrame exception. Yes, I meant SecurityError, but I do not feel strongly about the choice. How about we go with invalidModification?

Re: Should we delete isConnected.. I do not feel strongly about having this redundancy. If we had to pick one, I'd prefer that we keep the event over the function.

[cvan]

I'd ask folks to refer to and participate in the discussion in #116; the conversation around the events and naming is quite related to this issue.

[toji]

Update: isConnected is not planned for 2.0 but connected and disconnected events are.

[cvan]

@toji: for 2.0, does the connected event always fire on document load, even if the VR Display was already connected (i.e., not reconnected)?

[toji]

I believe that we should spec it that way, yes.