Hi there, Actually the open events might look broken but after looking carefully into W3C's spec, I have the feeling they aren't.
At point 5 of the WebSocket constructor it says "Return a new WebSocket<http://dev.w3.org/html5/websockets/#websocket> object, and continue these steps in the background (without blocking scripts)" which is followed by the connection procedure, and then later in the spec is says "When the *WebSocket connection is established*, the user agent must queue a task to first change". So, to my understanding, if a user instantiates a WebSocket, and then adds a listener to it, it will only be at the ent of the task that onopen could be firing (due to the queing mechanism employed before firing), so the user would not miss the event. Hope I am not adding to the confusion ... just my two cents Andi Mullaraj On Wed, Jun 30, 2010 at 9:56 PM, <[email protected]> wrote: > This isn't ready to submit yet, just wanted to show the changes I was > making based on discussions with Joel and JohnL about how the events > should work. > > I think the open events are broken as designed (please correct me if I > am wrong), and it would be pretty expensive for us to try and work > around it (we could add our own wrapper with its own callbacks, and when > we actually instantiate the underlying WebSocket object, we could check > if it changed to OPEN before the callbacks were registered and fake it > ourselves). > > > http://gwt-code-reviews.appspot.com/646803/show > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
