javascript websockets - control initial connection/when does onOpen get bound

Question

Two related questions that may be more rooted in my lack of knowledge of how/if browsers pre-parse javascript:

var ws = new WebSocket(\"ws://ws.my.url.com\")         


        

Answer 1

TL;DR - The standard states that the connection can be opened "while the [JS] event loop is running" (e.g. by the browser's C++ code), but that firing the open event must be queued to the JS event loop, meaning any onOpen callback registered in the same execution block as new WebSocket(...) is guaranteed to be executed, even if the connection gets opened while the current execution block is still executing.

---

According to The WebSocket Interface specification in the HTML Standard (emphasis mine):

The WebSocket(url, protocols) constructor, when invoked, must run these steps:

1. Let urlRecord be the result of applying the URL parser to url.
2. If urlRecord is failure, then throw a "SyntaxError" DOMException.
3. If urlRecord's scheme is not "ws" or "wss", then throw a "SyntaxError" DOMException.
4. If urlRecord's fragment is non-null, then throw a "SyntaxError" DOMException.
5. If protocols is a string, set protocols to a sequence consisting of just that string.
6. If any of the values in protocols occur more than once or otherwise fail to match the requirements for elements that comprise the value of Sec-WebSocket-Protocol fields as defined by The WebSocket protocol, then throw a "SyntaxError" DOMException.

7. Run this step in parallel:

   1. Establish a WebSocket connection given urlRecord, protocols, and the entry settings object. [FETCH]

   NOTE If the establish a WebSocket connection algorithm fails, it triggers the fail the WebSocket connection algorithm, which then invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

8. Return a new WebSocket object whose url is urlRecord.

Note the establishment of the connection is run 'in parallel', and the specification further states that "...in parallel means those steps are to be run, one after another, at the same time as other logic in the standard (e.g., at the same time as the event loop). This standard does not define the precise mechanism by which this is achieved, be it time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads, cores, CPUs, machines, etc."

Meaning that the connection can theoretically be opened before onOpen registration, even if onOpen(...) is the next statement after the constructor call.

However... the standard goes on to state under Feedback from the protocol:

When the WebSocket connection is established, the user agent must queue a task to run these steps:

1. Change the readyState attribute's value to OPEN (1).
2. Change the extensions attribute's value to the extensions in use, if it is not the null value. [WSP]
3. Change the protocol attribute's value to the subprotocol in use, if it is not the null value. [WSP]
4. Fire an event named open at the WebSocket object.

NOTE Since the algorithm above is queued as a task, there is no race condition between the WebSocket connection being established and the script setting up an event listener for the open event.

So in a browser or or library that adheres to the HTML Standard, a callback registered to WebSocket.onOpen(...) is guaranteed to execute, if it is registered before the end of the execution block in which the constructor is called, and before any subsequent statement in the same block that releases the event loop (e.g. await).