- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 02 Apr 2015 14:15:10 +0200
- To: "Arthur Barstow" <art.barstow@gmail.com>, public-webapps <public-webapps@w3.org>, "Boris Zbarsky" <bzbarsky@mit.edu>
On Thu, 26 Mar 2015 18:24:22 +0100, Boris Zbarsky <bzbarsky@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
Received on Thursday, 2 April 2015 12:15:42 UTC