The problem is, you can't set WebSocket.__swfLocation before you load
web_socket.js (because it creates the WebSocket global), but you also
can't reliably set WebSocket.__swfLocation after because if you are
doing dynamic script file includes then the onload (i.e.
WebSocket.__initialize) may fire before you have a chance to set
Websocket.__swfLocation.
Add message/state pollling in web-socket-js. Since Opera tends to drop
message events, we can dramatically increase performance by polling
every now for message event data.
Also, add more direct calls to update readyState so that it's not
missed when Opera drops events.
When using web-socket-js, the onopen event may happen inline so the
caller may not have time to set onopen before the event fires. In this
case set a short timeout and try again. In particular this affects
Opera most of the time.
Also, to get around Opera event droppings, always read the readyState
directly instead of relying on the local readyState variable to be
correct (which it isn't if stateChange event were dropped).
Instead of relying on FABridge AS -> JS event delivery, we just use
the events to notify JS of pending data. The message handler then
calls the AS readSocketData routine which sends back an array of
the pending WebSocket frames.
There is still a minor bug somewhere that happens after the first
connect where the web-socket-js throws an "INVALID_STATE_ERR: Web
Socket connection has not been established". But, Opera is now usable
and we should be able to drop the packet sequence numbering and
re-ordering code.
Another minor issue to better support Opera is to move JS script
includes to the <head> of the page instead of after the body.
Joel Martin
Joel Martin