Multiple client(user) instances bug when user press browser's back button and re-login to room

[GoogleCodeExporter]

There is a bug when user click the browser's back button in room, and re-
login to room. The server will have two client's instances (previous one 
is inactive, but still in server's ClientList).

Test Scenario:

1. Login to the system.
2. Enter a room.
3. Press browser's Back button, this will load a page outside openmeetings.
4. Re-login to openmeetings with the same account.
5. You will see there is still a client instance (previous one) in the 
room.
6. Enter the room again, there will have two user's instance. The previous 
one will never be removed, until restart the Red5 server.

Original issue reported on code.google.com by yp.yean@gmail.com on 30 Jan 2008 at 9:51

[GoogleCodeExporter]

which version ofOpenMeetings are you using?

Original comment by seba.wag...@gmail.com on 30 Jan 2008 at 9:56

• Changed state: Accepted
• Added labels: Milestone-Release0.5

[GoogleCodeExporter]

source r909

Original comment by yp.yean@gmail.com on 30 Jan 2008 at 10:07

[GoogleCodeExporter]

I checked the server log file, there is no "logicalRoomLeave" method invoked.

It seems that when user click browser's Back button in the room directly will 
not 
fire the client's "ontabcontentleave" event.

Original comment by yp.yean@gmail.com on 30 Jan 2008 at 10:42

[GoogleCodeExporter]

My test environment :

Browser : IE7
Server host on Windows XP SP2
Use http://localhost:5080/openmeetings/main.lzx.lzr=swf8.swf load OpenMeetings 
directly.

Original comment by yp.yean@gmail.com on 30 Jan 2008 at 10:47

[GoogleCodeExporter]

no but if you leave the application a *roomLeave* event which has a similar 
effect
should be triggered.
If you just say *ontabcontentleave* a user will _not_ be removed from the 
ClientList.
But after leaveing the room he will reconnect and this will remove the client 
from
the list.
If you just leave the browser by back button or anything else a *roomLeave* 
event is
thrown on server side. This event should also remove the client from the 
ClientList
and remove the user from any conference-room

Original comment by seba.wag...@gmail.com on 30 Jan 2008 at 10:48

[GoogleCodeExporter]

I found the problem will occur only when you launch the OpenMeetings by load 
main.lzx.lzr=swf8.swf directly (will not use jsp to load it).

I just created three client instances on the demo site (http://inno02.fh-
pforzheim.de:8080/xmlcrm/main.lzx.lzr=swf8.swf) by click the browse's back 
button, 
and re-login again. :)

Original comment by yp.yean@gmail.com on 30 Jan 2008 at 11:15

[GoogleCodeExporter]

i cannot duplicate it, 
what do you mean by *browser-back-button* ?
Press *Back* and return to _any_ other website or?
When do you press the button? from inside a room? or at entering or at 
dashboard or
if you have entered a room completely?

Original comment by seba.wag...@gmail.com on 30 Jan 2008 at 10:10

[GoogleCodeExporter]

First you need to load OpenMeetings use swf file 
(http://localhost:5080/openmeetings/main.lzx.lzr=swf8.swf, if you use SWFObject 
to 
load swf file, it won't have the problem, it is stranger, but it shows there 
maybe a 
hole which may generate a server management issue).

Then, you login to OpenMeetings, and enter a room. When you are "in room", 
click 
back button to previous html like page (any other website page before you load 
main.lzx.lzr=swf8.swf), then relogin to OpenMeetings again, you can see the 
previous 
client session instance in server. :-)

Original comment by yp.yean@gmail.com on 31 Jan 2008 at 2:25

[GoogleCodeExporter]

I have encounter the same problem with a version of IE6, an other version 
slightly
newer has no problem

We have switch to IE7 and the problem is not reproducible anymore.

The problem happened with $ip/openmeetings

Original comment by cedric.c...@uperto.com on 3 Mar 2008 at 3:03

[GoogleCodeExporter]

@yp.yean:
Could you post here the version of IE7 you are using (full version).

You can find this in the "about" dialog.

This might be helpful to isolate this bug as a "some version of IE" issue.

For the record, we are using version 7.0.5730.13 of IE7, and are unable to 
reproduce
this bug (that we encountered with a specific version of IE6 and not with 
another one)

Original comment by mathieu....@uperto.com on 4 Mar 2008 at 10:26

[GoogleCodeExporter]

I must add that we are also using SVN rev 909 of OpenMeetings

Original comment by mathieu....@uperto.com on 4 Mar 2008 at 10:38

[GoogleCodeExporter]

I current has the same IE 7 version with you, but I don't know if there is any 
windows component updated for IE7 since I posted the bug before (maybe I have a 
previous IE7 when I found the bug).

I will try the bug later with current version of IE7, if there is still bug 
existing 
with IE7, I will post it here.

Original comment by yp.yean@gmail.com on 4 Mar 2008 at 11:24

[GoogleCodeExporter]

We do not succeed to reproduce this bug using ie 
6.0.2900.2180.xpsp_sp2_rtm.040803-2158. 

Is there any fix done concerning this issue ?

Original comment by antoine....@uperto.com on 21 Mar 2008 at 2:27

[GoogleCodeExporter]

not me, don't know, anybody else? lets shift this to 0.6 and test again?

Original comment by seba.wag...@gmail.com on 26 Mar 2008 at 10:17

[GoogleCodeExporter]

I suggest to shift this bug to 0.6 and continue to watch, the bug not always 
happens, but it could cause big server maintance issue if it occurs again.

Original comment by yp.yean@gmail.com on 27 Mar 2008 at 2:20

[GoogleCodeExporter]

It looks like we can't reproduce it either, even with the IE version we used to
reproduce it earlier...

I'm not sure, but the patch I submitted for issue334 might have corrected this.

I think it can be delayed to "no revision", and when we have more time, we can 
try
with this IE version, the svn revs before and after the patch.

Anyway, if this can't be reproduced anymore, it's no use to let it for a 
specific
milestone. Just let it open, remaining in some dark corner of the issue tracker 
:P

Original comment by mathieu....@uperto.com on 27 Mar 2008 at 11:30

[GoogleCodeExporter]

If you shift it to 0.6 and we can't reproduce it either for 0.6, what will we 
do ?
Shift it again to 0.7 ?

Better to just remove the milestone tag.

yp.yean, can you still reproduce it ? We really can't any more, even with the
absolutely same version of IE 6 that caused us this trouble. That's why we 
think it
might have been fixed by another patch.

Original comment by mathieu....@uperto.com on 27 Mar 2008 at 2:52

[GoogleCodeExporter]

I tested it in r1102, it not happened so far.

I agree with you. It can be left on "no version" stage. The problem may also 
cause 
by browser and OpenLaszlo (I don't quite sure, just guess).

If there is someone who still find the same problem, (s)he can post here.

Original comment by yp.yean@gmail.com on 27 Mar 2008 at 3:42

[GoogleCodeExporter]

The way I 'fixed' the problem of people clicking the back button accidentally:

In index.jsp (in the openmeetings root), change the body tag to read this:

<body align="center" valign="middle" align="center" onLoad="focusSWF()" 
onbeforeunload="return 'You will 
leave the meeting if you continue'">

the onbeforeunload will trigger a javascript question box that asks if you're 
sure you want to leave the meeting.

Original comment by guru...@gmail.com on 15 Apr 2008 at 2:28

[GoogleCodeExporter]

I've added this workaround in the index.jsp in r1315

Original comment by seba.wag...@gmail.com on 17 Apr 2008 at 3:20

• Changed state: Review

[GoogleCodeExporter]

I have a similar problem when using the soap services.

When I ahref the link:
http://localhost:5080/openmeetings/main.lzx.lzr=swf8.swf?roomid=1&sid=xxxxx

IE 7.0.5730.11 gives me the following error:
Line 2, Char 1, Invalid Character; URL: same as above
Line 1, Char 1, Object Expected, URL: same as above

Original comment by harris.w...@gmail.com on 4 Jun 2008 at 2:55