14331 2011-09-29 10:00:19 +0000 EventSource can end up in the wrong state due to race conditions (see comment 12 paragraph 2) 2011-10-27 20:31:38 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Server-Sent Events (editor: Ian Hickson) unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian annevk art.barstow ian jonas mike public-webapps vic99999 public-webapps-bugzilla oldest_to_newest 57500 0 contributor 2011-09-29 10:00:19 +0000 Specification: http://dev.w3.org/html5/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hello! Why tasks that are queued by EventSource doesnot removed from task queues with "close" method? Thanks! Posted from: 217.19.114.226 User agent: Opera/9.80 (Windows NT 6.0; U; Edition Next; ru) Presto/2.9.205 Version/12.00 57640 1 ian 2011-10-02 16:39:36 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Why would they be? 57656 2 vic99999 2011-10-02 17:14:16 +0000 "message" and "open" events will fire even after calling "eventSource.close()" 57657 3 vic99999 2011-10-02 17:16:31 +0000 XMLHttpRequest#abort(), opposite, clears task in tasks queue to fire "readystatechange" 57706 4 ian 2011-10-03 16:08:48 +0000 I guess we can clear them, but that just means we're discarding events that were received before the close() method was called (even though they're being fired after). 57712 5 jonas 2011-10-03 17:02:20 +0000 Indeed, I think firing messages after .close() is called is much more likely to cause bugs than provide value. I don't think most authors think about these things in terms of several threads sending asynchronous messages to each other, and more in the terms of a single thread where everything is happening. 57724 6 ian 2011-10-03 22:24:09 +0000 Fair enough. Will do. 57758 7 vic99999 2011-10-04 06:55:43 +0000 anyway, calling stop() while event dispatching will not prevent other event handlers calling but i think, that it's better to make "close()" behavior to be more similar to XMLHttpRequest#abort() and WebSockets#close() 58260 8 ian 2011-10-14 22:34:44 +0000 Note that WebSocket.close() doesn't do this either. Changing that would contradict the protocol spec: WebSockets is explicitly designed to allow you to close the connection before you've finished receiving everything you're going to get; there's a clearly defined end handshake. I've fixed this for EventSource though. 58261 9 contributor 2011-10-14 22:35:02 +0000 Checked in as WHATWG revision r6688. Check-in comment: Make EventSource.close() cause the events to stop firing even if they're already queued. http://html5.org/tools/web-apps-tracker?from=6687&to=6688 58267 10 vic99999 2011-10-15 04:40:51 +0000 what about "open" and "error" events? It seems, they should also be dropped... 58268 11 annevk 2011-10-15 04:47:56 +0000 Seems easier to just empty the "remote event task source". 58369 12 ian 2011-10-18 20:06:37 +0000 Emptying the task source is a bit dodgy because you'd have to make sure to only empty the tasks that were fired for this specific EventSource object. You also have to make sure that no new tasks get queued. Agreed that 'open' events shouldn't fire, though. In particular, as specced, if you call close() between the connection being open and the 'open' event firing, the object will end up in the wrong state. A similar problem exists for 'error', but it's actually worse; if the connection closes just before you call close(), per spec, the connection will actually be reopened! I'll fix that. 58410 13 annevk 2011-10-19 03:27:15 +0000 That is what XMLHttpRequest does and HTML media elements do. E.g. from HTML: "If there are any tasks from the media element's media element event task source in one of the task queues, then remove those tasks." I used that language for XMLHttpRequest. 58831 14 ian 2011-10-25 02:55:26 +0000 It works for media elements because each one has its own task source. 58847 15 annevk 2011-10-25 03:35:33 +0000 Oh I see, it seems it would be simple to do the same for EventSource. I should update XMLHttpRequest to say the task source is per object. 59095 16 ian 2011-10-27 20:29:58 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 59096 17 contributor 2011-10-27 20:31:38 +0000 Checked in as WHATWG revision r6772. Check-in comment: Make sure once you call closed() that EventSource objects stay down. http://html5.org/tools/web-apps-tracker?from=6771&to=6772