FMS apps which use onDisconnect not firing in IE6/7 with SWFObject 2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Embed a FMS application swf on a HTML page with SWFObject
2. Connect to the FMS application
3. Disconnect from the application
4. re-connect (multiple instances of the same user can/will appear on the 
user list

What is the expected output? What do you see instead?

Users should be removed from the FMS shared object when disconnecting, but 
instead since the onDisconnect event does not get fired/caught properly, 
multiple instances of the same users can appear in an FMS application.

What version of the product are you using? On what operating system?

2.0 / 2.1 under win XP/ Vista etc

Please provide any additional information below.

* Issue on arises when using IE6/7, not with any other browser.
* Issue does not appear with SWFObject 1.x

Read more about the issue here:
http://www.flashcomguru.com/index.cfm/2008/8/7/swfobject-problem-ie-fms

Specific app info will be privately available

Original issue reported on code.google.com by aran.rhee@gmail.com on 7 Aug 2008 at 11:50

[GoogleCodeExporter]

We will investigate this

Original comment by bobbyvandersluis on 8 Aug 2008 at 10:43

• Changed state: Accepted

[GoogleCodeExporter]

Also investigate this possible related issue:

http://groups.google.com/group/swfobject/browse_thread/thread/92b1a325850f43fa

Original comment by bobbyvandersluis on 12 Aug 2008 at 8:14

[GoogleCodeExporter]

The possibly related issue mentioned in comment 2 does not occur in SWFObject 
2.1 and
can therefore be closed.

Original comment by bobbyvandersluis on 13 Aug 2008 at 9:12

[GoogleCodeExporter]

Although the behavior is different between SWFObject 1 and 2, I doubt that this 
is a
pure SWFObject 2 issue.

Understanding existing issues with onDisconnect:
----
From: http://www.bulahema.com/en/fixing_flashcom_s_ondisconnect_problem

Sometimes it takes a while for the server to understand that the client 
disconnected.
That’s because the operating system holds on to the socket for a while. Macs, 
for
instance, take much longer than windows before they decide a connection is 
lost. This
might take a minute, maybe even longer.

If that’s too long for you, one thing you can do to make sure that a client 
is alive
is to make a server-to-client call to the client on a setInterval (maybe once 
every
10 seconds?), like this:

    application.checkForAlive = function(client) {
    var res = new Object();
    res.client = client;
    res.onResult = function(val) {
    trace(”client is ok”);
    }
    res.onStatus = function(info) {
    trace(”client didn’t respond”);
    application.disconnect(this.client);
    }
    var executed = client.call(”areYouOk”, res);
    if (executed == false) {
    trace(”Client is dead, disconnecting”);
    application.disconnect(client);
    }
    }

Then on the client:

    nc.areYouOk = function() { return true; }
----
http://www.flashcomguru.com/index.cfm/2008/8/7/swfobject-problem-ie-fms#c9D2A878
A-D611-38B6-1C53D9926296C46B

Another interesting thing I noticed in dealing with non-disconnects... tabbed
browsing in IE7 also plays a role. I've found that even when using SWFObject v1,
having multiple tabs open can also prevent FMS from seeing the client disconnect
(open the FMS app page in one tab, open google in another tab, close the FMS 
tab...
no disconnect). If find this to be the case with FMS 2 and 3.

In the end, I'm still using the old "heartbeat" connection checking method in 
any
application that relies on timely detection of clients leaving... seems that's 
the
only bulletproof way of doing it.

Also, I tend to do things to prevent duplicate entires in user lists to account 
for
the "fudge" time I allow in the hearbeat routine. I typically check the userlist
object for matches, and then disconnect the client associated with the old entry
before adding the new client to the list (sort of how Yahoo IM handles their
logins... new client bumps old client). Of course, this assumes that the 
application
requires registration of user names (most of mine do).
----

A possible solution is posted in the same thread this issue was posted: 
----
http://www.flashcomguru.com/index.cfm/2008/8/7/swfobject-problem-ie-fms#c9D67E03
1-D611-38B6-10F053812050EFE5

i have the same problem on some machines even without swfobject. the swfobject 
issue
is solved by manually closing connection on beforeunload event from the webpage
(unload event might not fire)
----

If it is not caused by one of the previous mentioned causes, a cause can be that
SWFObject 2 (dynamic publishing only) nullifies all functions on the embedded 
object
to avoid memory leaks in Internet Explorer, after which the object will be 
physically
removed. Any possible injected JavaScript functions on the object are cleared 
as well
(these are a main cause for memory leaks when using dynamic publishing, e.g. the
injected JavaScript code by External Interface), so any possible callback 
functions
on the object will automatically deleted. This would also explain why 
client-side
disconnecting onbeforeunload does work.

Also when using static publishing, there is no need to cleanup objects in IE (no
embedding via innerHTML/outerHTML), so using static publishing should avoid the 
issue
too.

Original comment by bobbyvandersluis on 13 Aug 2008 at 11:34

[GoogleCodeExporter]

Yes, static publishing may solve it. I haven't tested this, but even if that 
fixes
the problem it does not pose a solution since I would like to use dynamic 
publishing :-)

Heartbeat code: yes we regularly add this to our FMS apps but again it's not 
really a
solution for the problem here. The user would still show up twice until the 
heartbeat
code detects the disconnected user - the duration is dependent on your heartbeat
interval. In short, yes we can work around the problem using a combination of
heartbeat code plus pushing users out of the list onconnect, but this won't fix
SWFobject :-) (if it indeed has a bug).

Lastly, yes some OSes take longer to issue a disconnect, however I doubt this 
is the
cause here since 
a) the problem is browser specific, not OS specific
b) a simple browser refresh does not normally cause users to hang around without
onDisconnect being triggered. A missed onDisconnect normally occurs when a 
network
cable is unplugged or some other severe network failure occurs. 

Lastly, I do not understand enough of the JavaScript side of things to comment. 
But
to make it clear: my application does not explicitly rely on any JavaScript to 
work.
We make no calls from or to the SWF via JS (but SWFObject may, I don't know).
It sounds to me that the object cleanup routine may be at fault here, 
especially if
this is different to how SWFObject 1.5 handled it.

Regards,

Stefan

www.flashcomguru.com

Original comment by stefan.r...@gmail.com on 13 Aug 2008 at 1:05

[GoogleCodeExporter]

We are currently waiting for feedback from Adobe on this.

Original comment by bobbyvandersluis on 25 Aug 2008 at 3:27

[GoogleCodeExporter]

Resend the email to the Adobe guys, still haven't received a reply...

Interesting feedback is:
http://www.flashcomguru.com/index.cfm/2008/8/7/swfobject-problem-ie-fms#c42B7F8C
5-D611-38B6-130F9A14F5201E05

"swfobject.addDomLoadEvent( function(){ swfobject.removeSWF( my_div_id ); });
Does the trick for me (using SWFObject v2.1 beta7)."

To me it makes no sense to use this function in this way, however this function 
is
called as a part of our standard cleanup routine in IE. So we should also 
research if
the onunload handler that triggers the cleanup routine does actually fire when
reloading a page in IE.

Original comment by bobbyvandersluis on 11 Sep 2008 at 8:33

[GoogleCodeExporter]

I've just noticed that I now encounter the same issue in Firefox when using 
SWFObject
1.5 - something I previously thought was working ok. I'm trying SWFObject 2.1 
now,
and also see if the fix that the user posted to my blog helps at all.

Regards,

Stefan

Original comment by stefan.r...@gmail.com on 24 Sep 2008 at 8:51

[GoogleCodeExporter]

Cool. My message got forwarded to someone within the Adobe who should be able to
answer my questions, so I hope to get a reply on this soon. 

Original comment by bobbyvandersluis on 24 Sep 2008 at 12:20

[GoogleCodeExporter]

Eagerly awaiting this fix.

Original comment by mikemitt...@gmail.com on 27 Sep 2008 at 6:34

[GoogleCodeExporter]

This issue appeared to be NOT SWFObject related.

In the pas week Albert Chang from Adobe helped us setting up test cases to test 
FMS
functionality with SWFObject and to try to reproduce the reported issue. He 
concluded
that everything worked correctly and that he couldn't reproduce the issue. He 
also
confirmed that Adobe QA is testing all their new software with the latest 
version of
SWFObject, to make sure that everything works correct, which is great news.

We got in touch with Stefan Richter who originally reported the issue with the
question if he could provide a new test case. He responded that he had a hard 
time
reproducing the issue himself, and that he got convinced that the issue is not
SWFObject 2 related. He was unable to reproduce it in any of his applications 
EXCEPT
for one - the main difference on that application is that he uses the old 
Macromedia
Communication component framework. He is still looking into this.

Original comment by bobbyvandersluis on 8 Oct 2008 at 8:49

• Changed state: Invalid