On Thu, 26 Mar 2015 18:24:22 +0100, Boris Zbarsky <bzbar...@mit.edu> wrote:
On 3/26/15 10:51 AM, Arthur Barstow wrote:
If anyone is willing to help with the failure analysis, that would be
very much appreciated.
Taking a brief look at some of the failures in Firefox, in addition to
the ones Olli already posted about:
http://www.w3c-test.org/websockets/keeping-connection-open/001.html --
the test is wrong. Passing undefined means the argument is not present
per Web IDL, so this should not throw.
I assume you mean some other test since that test doesn't use undefined.
(I'll have a look and fix ones that use undefined.)
http://www.w3c-test.org/websockets/cookies/001.html seems racy to me: it
kicks off an async test and then immediately removes the cookie, so it's
not obvious to me why it expects that cookie to be present in the
websocket connection; the cookie may well be removed before the
connection is set up.
I agree. The spec says to return from the constructor and establish the
connection in parallel, so it is not guaranteed which cookies to include.
Fix: https://github.com/w3c/web-platform-tests/pull/1701
But arguably that is a spec bug. It would be nice if it was deterministic.
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28393
http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html
looks wrong to me: the value it should get is in fact undefined, since
the property got deleted from the prototype.
(Will have a look.)
--
Simon Pieters
Opera Software
