These two tests are failing after r270882: - http/tests/security/mixedContent/websocket/insecure-websocket-in-iframe.html [ Failure ] - http/tests/security/mixedContent/websocket/insecure-websocket-in-main-frame.html [ Failure ] On the other hand, there are two WebSocket tests that are now passing after r270882 but there are error messages in stderr. Those tests are: - http/tests/websocket/tests/hybi/close-code-and-reason.html - http/tests/websocket/tests/hybi/workers/close-code-and-reason.html STDERR for http/tests/websocket/tests/hybi/close-code-and-reason.html is: CONSOLE MESSAGE: WebSocket connection to 'ws://127.0.0.1:8880/websocket/tests/hybi/echo' failed: WebSocket is closed before the connection is established. CONSOLE MESSAGE: WebSocket connection to 'ws://127.0.0.1:8880/websocket/tests/hybi/close-code-and-reason' failed: Received invalid WebSocket response from the server CONSOLE MESSAGE: WebSocket connection to 'ws://127.0.0.1:8880/websocket/tests/hybi/close-code-and-reason' failed: Received invalid WebSocket response from the server CONSOLE MESSAGE: WebSocket connection to 'ws://127.0.0.1:8880/websocket/tests/hybi/close-code-and-reason' failed: Received invalid WebSocket response from the server I paste below diffs for insecure-websocket-in-iframe.html and insecure-websocket-in-main-frame.html: Diff: https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r270907%20(17510)/http/tests/security/mixedContent/websocket/insecure-websocket-in-iframe-diff.txt --- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/http/tests/security/mixedContent/websocket/insecure-websocket-in-iframe-expected.txt +++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/http/tests/security/mixedContent/websocket/insecure-websocket-in-iframe-actual.txt @@ -2,6 +2,7 @@ ALERT: WebSocket connection failed. CONSOLE MESSAGE: WebSocket connection failed: WebSocket is closed before the connection is established. +ALERT: WebSocket closed. This test loads an iframe that creates an insecure WebSocket connection. We should block the connection and trigger a mixed content callback because the main frame is HTTPS, but the data sent over the socket could be recorded or controlled by an attacker. Diff: https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r270907%20(17510)/http/tests/security/mixedContent/websocket/insecure-websocket-in-main-frame-diff.txt --- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/http/tests/security/mixedContent/websocket/insecure-websocket-in-main-frame-expected.txt +++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/http/tests/security/mixedContent/websocket/insecure-websocket-in-main-frame-actual.txt @@ -2,4 +2,5 @@ ALERT: WebSocket connection failed. CONSOLE MESSAGE: WebSocket connection failed: WebSocket is closed before the connection is established. +ALERT: WebSocket closed. This test opens a window that connects to an insecure ws:// WebSocket. We should block the connection and trigger a mixed content callback because the main frame is HTTPS, but the data sent over the socket could be recorded or controlled by an attacker.
Failures gardened in r270926.
Looking at the diff, I think it would be ok to just rebaseline the tests instead of marking them as failures. The difference is probably because apple is not using the new web sockets code path in tests yet.
(In reply to Carlos Garcia Campos from comment #2) > Looking at the diff, I think it would be ok to just rebaseline the tests > instead of marking them as failures. The difference is probably because > apple is not using the new web sockets code path in tests yet. Right, we have not yet enabled this code path. Overall, when looking at the results from both code paths, there are clear differences. These differences are also where compat with Chrome and/or Firefox is weak. Additional CONSOLE MESSAGE is probably fine, I am less sure about the new ALERT though. Note that the new code path puts more burden on the network stack to be compat with other implementations. I would tend to do the exercise of comparing GTK results with Safari, Chrome and Firefox. If GTK is the only one that differs, I would tend to file an issue on the GTK websocket backend.
<rdar://problem/72642317>
This appears to have been fixed by r284472.