| 00:29 | <Nikola Abkniky> | LOGO |
| 12:20 | <nicolo-ribaudo> | Hi! I recently joined a company that already signed the participation agreement - How do I make https://participate.whatwg.org/agreement-status?user=nicolo-ribaudo&repo=html pick it up, rather than being stuck on a non-verified signature I submitted last year? |
| 12:21 | <Luca Casonato> | nicolo-ribaudo: the reviewer of your first PR should verify it |
| 12:22 | <nicolo-ribaudo> | Ok thanks! I'll wait until my PR is non-draft before worrying about it |
| 14:53 | <zcorpan> | annevk: is there anything in the websocket spec that still requires what this test is testing? http://wpt.live/websockets/constructor/014.html (i.e. to wait with establishing another websocket connection to the same host while the previous is still connecting, as a DOS prevention mechanism) |
| 14:57 | <Yutaka Hirano> | zcorpan: https://datatracker.ietf.org/doc/html/rfc6455#section-4.1 |
| 14:57 | <Yutaka Hirano> | If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. |
| 14:57 | <Yutaka Hirano> | Maybe this? |
| 14:58 | <zcorpan> | Yutaka Hirano: Thanks! Yes. I thought it was defined in the API rather than the protocol |
| 14:59 | <zcorpan> | It shouldn't delay the first connection though, but maybe browsers have to wait a microtask or a task to avoid race conditions? |
| 14:59 | <zcorpan> | Context: https://github.com/whatwg/html/issues/8037 |
| 15:05 | <Yutaka Hirano> | zcorpan: Interesting! As long as the connection establishment is fast enough, subsequent WebSocket connections will not be suffered, right? |
| 15:07 | <zcorpan> | Yutaka Hirano: The delaying while connecting applies equally for all subsequent connections |
| 15:09 | <zcorpan> | Yutaka Hirano: but I mean, for the first connection, there is no prior connection, so no reason for the browser to wait. But how does the browser know for sure that a connection is the first one, without incurring any delay for the first connection? The "establish a WebSocket connection" steps are defined to be in parallel |
| 15:09 | <zcorpan> | Also with the guarantee to never violate the requirement |
| 15:12 | <Yutaka Hirano> | @zcorpan: Our implementation runs all the websocket network activities on the same sequence, though It is different from the scripting sequence. |
| 15:13 | <Yutaka Hirano> | zcorpan: Thus it is easy for us to distinguish the "first" request (for a server). |
| 15:15 | <zcorpan> | Yutaka Hirano: is strelec's claim "I think that the remainder of the main thread execution delays the connection to the socket (if not according to the spec, then by browser implementations)" true in chromium? That is, does the script that calls the WebSocket constructor need to complete before the network connection is started? |
| 15:18 | <Yutaka Hirano> | zcorpan: Sorry, what do you mean by "complete"? |
| 15:19 | <Yutaka Hirano> | Due to "in parallel", new WebSocket(...) returns immediately. The network connection will be done later. |
| 15:22 | <zcorpan> | Yutaka Hirano: the sync part of the script is run, e.g. in <script>const ws = new WebSocket(url); ws.onopen = handleOpen; await new Promise(resolve => resolve())</script> after the onopen handler is registered but before the promise has resolved |
| 15:23 | <zcorpan> | The question is how much later, and does it depend on when the "script" is done? |
| 15:25 | <Yutaka Hirano> | zcorpan: In our implentation, the script completes immediately. The WebSocket constructor kicks the connection procedure in another sequence ("the network thread"). The waiting behavior is implemented in the network thread. Does this answer your question? |
| 15:27 | <zcorpan> | Yutaka Hirano: I think so. It sounds like strelec's claim is then not correct (for chromium). To verify, I could do alert(true) {} right after the WebSocket constructor, and the browser would still open a connection from the network thread while the main thread is busy running the infinite loop? |
| 15:29 | <Yutaka Hirano> | zcorpan: Yes, the connection will be established, but the script wouldn't be able to know that because the onopen handler is blocked by the busy loop. |
| 15:29 | <zcorpan> | Yutaka Hirano: right. Thanks! |
| 15:30 | <Yutaka Hirano> | zcorpan: You're welcome! |
| 18:08 | <The Freelancer> | zcorpan: Hello, once again. |
| 18:11 | <The Freelancer> | I wanted to ask one question regarding the DOM, which has been confusing me for a while... |
| 18:15 | <The Freelancer> | Why does querySelectorAll() return a NodeList and not an HTMLCollection instance? |
| 18:16 | <The Freelancer> | The reasoning I have here is that querySelectorAll() is meant to select elements only, and the HTMLCollection interface suits this notion more than NodeList... |
| 18:17 | <The Freelancer> | NodeList, as the documentation says, is a collection of nodes. For example, for the childNodes property of an element, it makes perfect sense, as it will contain element nodes, text nodes, maybe even comment nodes. |
| 18:18 | <The Freelancer> | But for querySelectorAll(), using NodeList doesn't make sense, as far as I see it. Clearly, there is some story related to using NodeList for querySelectorAll()... |
| 21:40 | <zcorpan> | zcorpan: Hello, once again. |
| 21:40 | <zcorpan> | As for making sense, please see the topic :) |
| 21:41 | <zcorpan> | Both kinds of collections are legacy now, see https://dom.spec.whatwg.org/#old-style-collections |
| 21:43 | <zcorpan> | and the note in https://dom.spec.whatwg.org/#interface-htmlcollection |
| 21:45 | <zcorpan> | (The thread wasn't about querySelectorAll actually, I see now) |
| 21:56 | <zcorpan> | The first Working Draft of Selectors API defined the return value to be StaticNodeList rather than NodeList because NodeLists were defined to be live in DOM 3 Core. https://www.w3.org/TR/2006/WD-selectors-api-20060525/#staticnodelist |