| Summary: | WebSocket events should be dispatched synchronously | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
| Component: | WebCore Misc. | Assignee: | Alexey Proskuryakov <ap> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ian, ukai, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
|
Description
Alexey Proskuryakov
2009-12-09 11:15:59 PST
(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. |