The test seems to hung when opcode=11 on chromium-win. I don't know why. Full output: CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 3 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 4 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 5 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 6 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 7 Tests whether WebSocket ignores frames with reserved opcode. On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". Opcode 3: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 4: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 5: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 6: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 7: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 11: Test started.
Marked as TIMEOUT for now. I'm trying to reproduce this.
Okay, I figured out the cause. This timeout happens on Win-Vista-Release and Win-7-Release. Mac and Linux seem unaffected. - The test opens a WebSocket connection using the hostname "localhost" (e.g. new WebSocket("ws://localhost:8880/...")) - Resolving "localhost" returns "::1" (IPv6 loopback address), but websocketserver doesn't listen on IPv6 address. - So connect fails, but it takes about one second to fall back to IPv4. :( - The test reserved-opcodes.html opens ten new connections, which means one-second block adds up and it will take 10+ seconds to complete the test. - For release builds, the test timeout is set to 6 seconds so the test timeouts. For debug builds, the test has 12 seconds which is somewhat enough to complete the test. Replacing "localhost:8880" with "127.0.0.1:8880" will fix the problem. Using this opportunity, I'd like to replace all the occurrences of "localhost" in WebSocket tests. This should cut the layout test execution time in Vista/7 bots.
Nice catch! > websocketserver doesn't listen on IPv6 address Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1.
(In reply to comment #3) > Nice catch! > > > websocketserver doesn't listen on IPv6 address > > Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1. I first thought this was easy, but I was wrong; pywebsocket standalone server currently does not provide dual-stack server support, and adding it seems to require unobvious amount of work. I'll ask pywebsocket folks about this, but I'm leaning towards the idea of using only "127.0.0.1:8880" and forgetting about IPv6... Maybe we could forbid the use of "localhost:8880" by adding some check to check-webkit-style.
Another idea is to bring up two instances of pywebsocket standalone server (one for IPv4, one for IPv6) in run-webkit-websocketserver. This is not obvious, either, and IMO the amount of work does not balance with the actual gain (what we really want to test is our WebSokcet implementation, not server's IPv4/v6 dual stackness).
We also need to test cross origin behavior, and the simple fact that we resolve host names.
Dual-stack support (listening at IPv4 and IPv6 addresses simultaneously) was added to pywebsocket recently. To make use of this feature, we have to give a command-line option "--server-host localhost" to standalone.py instead of "--server-host 127.0.0.1".
Created attachment 111603 [details] Patch
Comment on attachment 111603 [details] Patch We had better land the 127.0.0.1 -> localhost change without the test_expectations.txt change , see the layout test results for a while, and then apply the test_expectations.txt change.
Created attachment 111729 [details] Patch v2 (no expectation change)
Comment on attachment 111729 [details] Patch v2 (no expectation change) Clearing flags on attachment: 111729 Committed r98064: <http://trac.webkit.org/changeset/98064>
All reviewed patches have been landed. Closing bug.
Reverted r98064 for reason: Broke Mac bots. Committed r98068: <http://trac.webkit.org/changeset/98068>
Sounds like this is pywebsocket's problem; after newer version of pywebsocket is rolled into WebKit we will be safely land this patch again.
New pywebsocket (with a fix) has been landed; let me try this again.
Created attachment 112815 [details] Patch for landing
Comment on attachment 112815 [details] Patch for landing Clearing flags on attachment: 112815 Committed r98693: <http://trac.webkit.org/changeset/98693>