We have bug 5060 for implementing full multi-session handling in the HTML client. But until then it should behave better than it does now when there are multiple sessions on the server. It should really implement the old "do_login" behaviour. Basically it is the auto reconnect policy of the native client. Currently it is impossible to have multiple session with the HTML client. With this change it would be fully possibly, only slightly annoying if you have multiple _disconnected_ sessions. Pairing it with a MaxDisconnectTime would be a very useful scenario though.
Tester needs to verify at least: - That new sessions are created if all existing ones are connected - That disconnected sessions are chosen for reconnect if available - That connected sessions are chosen for reconnect if there are no disconnected and new sessions aren't allowed - That it warns if there is more than one disconnected/connected session in the above two scenarios - That you get an error if there is no session to reconnect to, and no new sessions are allowed (all existing sessions have a start command)
(In reply to comment #2) > Tester needs to verify at least: > > - That new sessions are created if all existing ones are connected Works as expected > - That disconnected sessions are chosen for reconnect if available Works as expected > - That connected sessions are chosen for reconnect if there are no > disconnected and new sessions aren't allowed Works as expected > - That it warns if there is more than one disconnected/connected session in > the above two scenarios Works as expected > - That you get an error if there is no session to reconnect to, and no new > sessions are allowed (all existing sessions have a start command) Works as expected
Tested with build 4888.
