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

Reply via email to