I would like to raise an issue seeking some clarification on whether the API specification intends any synchronicity in how setSignals() applies the specified signal states to a serial port, and discuss potential disjunction between how a user may expect it to behave and how it actually behaves.

The nature of the setSignals() API method - taking a single dictionary argument containing one or more signal states - may be likely to lead a user to assume that the new states of multiple signals they specify in the argument are all applied synchronously. That is, an assumption that the change in state of all specified signals will occur at the exact same moment; because new signal states are specified all at once, ergo they are applied all at once, no?

However, reality does not meet this potential expectation, due to current implementations (i.e. Chromium-based browsers) performing signal state change operations only in a discrete sequential manner. For example, in Chrome and Edge, if one changes both dataTerminalReady and requestToSend in the same setSignals() call, the former is always toggled before the latter, with a delay of what can be several hundred microseconds or more between. This observed behaviour is also evidenced by the Chromium code for Windows and POSIX implementations, where it can be seen that they do indeed do things in a step-wise manner.

Such discrete sequencing and consequential inter-signal delays (which are not an inconsequential amount of time!) can sometimes lead to unintended behaviour from a connected serial device if not taken into account.

There is also the fact that such setSignals() behaviour is in juxtaposition to the behaviour of getSignals(), for which the specification does imply that the state of all relevant signals be captured synchronously, and which current implementations actually do.

When discussing how new setSignals() states are applied, the specification currently says:

Perform the following steps in parallel:

However, I understand that the "in parallel" statement refers only to how events occur within the browser itself, rather than the way the following steps occur. Is this correct? That, together with the use of the word "steps" and a numerical listing, seems to imply that the specification wants the states of each signal to be toggled in a specifically linear fashion - each as a discrete change, one after the other.

So, a question: is that the actual specific intention of the API specification for implementations of setSignals()?

If it is, I am wondering whether it is prudent to recommend implementers document how setSignals() behaves with regard to synchronicity (or lack thereof) for changes to multiple signal states.