Open codembed opened 1 year ago
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:
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.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.
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?