ladybird/Tests/LibWeb/Text/input/WebSocket/echo.html

<!DOCTYPE html>
<script src="../include.js"></script>
<script>
    asyncTest((done) => {
        const ws = new WebSocket(`ws://localhost:${internals.getEchoServerPort()}/`);

        let messageCount = 0;

        ws.onopen = function (ev) {
            println(ev.type);
            ws.send(`WellHelloFriends${messageCount}`);

            ws.onclose = function (ev) {
                println(ev.type);
                done();
            }
            ws.onerror = function (ev) {
                println(ev.type);
                done();
            }
        };
        ws.onmessage = function (ev) {
            println(`${ev.type} ${ev.data}`);
            if (++messageCount === 5) {
                ws.close();
                return;
            }
            ws.send(`WellHelloFriends${messageCount}`);
        }
        ws.onerror = function (ev) {
            println(ev.type);
            done();
        }
    });
</script>
Meta: Add DOCTYPEs to most text tests 2025-03-18 15:28:35 -03:00			`<!DOCTYPE html>`
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00			`<script src="../include.js"></script>`
			`<script>`
			`asyncTest((done) => {`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			const ws = new WebSocket(`ws://localhost:${internals.getEchoServerPort()}/`);
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00
			`let messageCount = 0;`

			`ws.onopen = function (ev) {`
			`println(ev.type);`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			ws.send(`WellHelloFriends${messageCount}`);
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00
			`ws.onclose = function (ev) {`
			`println(ev.type);`
			`done();`
			`}`
			`ws.onerror = function (ev) {`
			`println(ev.type);`
			`done();`
			`}`
			`};`
			`ws.onmessage = function (ev) {`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			println(`${ev.type} ${ev.data}`);
			`if (++messageCount === 5) {`
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00			`ws.close();`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			`return;`
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00			`}`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			ws.send(`WellHelloFriends${messageCount}`);
LibWeb: Add simple in-tree WebSocket test 2025-02-14 07:07:13 -03:00			`}`
			`ws.onerror = function (ev) {`
			`println(ev.type);`
			`done();`
			`}`
			`});`
Tests: Run a local WebSocket echo server in place of the hosted one Problem: Our WebSocket tests were connecting to an externally-hosted echo server — so they depended on network reachability from our CI runners. Any network hiccups between a runner and that server timed the tests out — and that’s been a relatively-frequent source of CI flakes. Fix: Teach our existing in-tree echo server to also speak WebSocket. It performs the RFC 6455 handshake, and echoes every text or binary frame back — on the same OS-assigned port already exposed to tests. Updated our tests to connect to that local server, not the remote one. Also, updated our WebSocket echo.html to drive the exchange from its onopen handler — rather than waiting for a server-initiated greeting. That’s because: A frame the server sends in the moment right after the handshake — before the client has sent anything — is currently delivered unreliably by our (curl-backed) WebSocket client. See issue #9776. 2026-05-31 04:06:22 -03:00			`</script>`