← back to v154 · add-options-bag-to-websocket-constructor
conformance · v154
v154 · add-options-bag-to-websocket-constructor — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
websocket-constructor-exists |
The interface this feature extends. spec ↗ | typeof | … | |
constructor-reads-protocols-from-a-dictionary |
The feature itself: the constructor must read a `protocols` member off a dictionary passed as the second argument. A getter proves it was read, with no connection needed — before Chrome 154 the object was coerced to a subprotocol string instead. spec ↗ | script | … | |
positional-string-still-works |
The 2011 form must keep working: a single subprotocol string opens a connection and negotiates it. spec ↗ | script | … | |
positional-sequence-still-works |
So must the sequence form. The server prefers `echo` over `chat`, so offering both must negotiate `echo` — which also confirms the offer really reached the server. spec ↗ | script | … | |
no-subprotocol-opens-cleanly |
Offering nothing is not an error: the connection opens with an empty protocol. Most sockets do not use one. spec ↗ | script | … | |
duplicate-subprotocols-throw |
A repeated subprotocol is a SyntaxError at construction, before any network activity. This rule predates the feature and must survive it. spec ↗ | throws | … |