Deprecate 4.1 SerialPort connect attribute/event

[codembed]

I have never observed this event handler being called. Certainly, the encompassing 3.3 navigator.serial one is, but not for a specific SerialPort.

I presume this handler is only ever triggered before there is any opportunity to attach a listener to it.

As per #128 and #156, it is difficult or impossible to identify a temporarily disconnected port, even within a single browser session. I understand there is ongoing work to move towards some kind of unique identifier in the future, (even the COM number would be handy) that persists for (at least) the current session. I look forward to seeing this!

In any case, should this attribute/handler (4.1) be deprecated or marked as 'not intended for use' in the specification?

[reillyeon]

Right now, given how the SerialPort interface is implemented in Chromium, when a port is disconnected and reconnects a new instance of the SerialPort interface is always created. As you point out, this means that there's never a chance for the connect event to be observed firing on a SerialPort instance, only when the event bubbles up to the navigator.serial object.

Two thoughts:

• For symmetry with the disconnect event it's important that the event is fired at the SerialPort instance and then bubbles to the navigator.serial object so that its target attribute is correct. A side effect of that is that the connect event handler attribute is exposed on the SerialPort interface even though it isn't strictly useful.
• It would likely be an improvement over the current implementation if reconnecting a serial port (acknowledging the issue you link to about port identification) reused the existing SerialPort instance, in which case the connect event would be observable on reconnect.

I think a note on the connect event handler attribute warning developers that it is not observable (they need to register events on navigator.serial) would probably avoid confusion.