As per recent WhatWG discussion, everywhere the spec says "queue a task to dispatch an event", it actually means "dispatch the event synchronously". We should update the code accordingly, and make readyState checks in websocket/tests/simple test strict again.
(In reply to comment #0) > As per recent WhatWG discussion, everywhere the spec says "queue a task to > dispatch an event", it actually means "dispatch the event synchronously". That's only true if the code that would be queueing the task is itself a task that was queued. In which case, the task in question is simply the task that was queued. (In other words, it's not the case if the code that would be dispatching the event is actually running on another thread.) That is, where the spec says: On another thread, if X, queue a task on the main thread that does Y and Z. ...it is fine to implement this as: Queue a task on the main thread that, if X, does Y and Z. ...but it's not fine to implement it as: On another thread, if X, do Y and Z. The spec has changed to make the readyState attribute change at the same time as the events are dispatched (as part of the same task).
In WebKit, all code that handles events from network layer is "a task that was queued". I suspect that's true of most/all other browser engines.
Created attachment 44560 [details] proposed patch Ian, do the ChangeLog comment and test changes look right?
style-queue ran check-webkit-style on attachment 44560 [details] without any errors.
Committed revision 51935.