Issues with OTR sessions

Description

There are a few issues with OTR sessions in Spark:

1) User1 starts an OTR session with User2 and one can see how lock icon locks on both sides. The option in OTR plugin is to "Close the session when chat windows is closed". If User1 closes the chat window, the OTR session is closed correctly and the lock icon unlocks for User2 and he gets a message that session has been closed. But if User2 instead closes the chat window, the session is NOT closed at both sides. And if then User1 sends a message to User2, the first message goes as gibberish and then all the other messages are readable. On the other hand if User2 closes the window and then OPENS the window again all messages goes readable.

The 1st problem is, that Spark can't reconnect to OTR session when chat window is not already opened and it receives a new message through already established OTR session. It's some racing condition bug which also causes not all GUI elements to load when receiving offline message at login (e.g. no emoticons bar).

The 2nd problem is that an option "Close OTR session when chat windows is closed" only works when OTR session starter closes his window. Which is confusing and should work from both sides if at least one user has this option enabled.

2) When "Close OTR session when contact goes offline" is selected. If User1 has OTR session with User2 and User2 goes offline, the session is correctly closed on the User1 side. The problem is it sends the message "OTR session closed. Messages are no longer encrypted" before it closes the OTR session. This message is encrypted too. And it sends it to both sides of the session. But the User2 is already offline, so this message is stored in his offline storage - encrypted. But User2 is not in OTR session anymore. So when User2 logins back, he gets a gibberish message. This should be handled more gracefully. Maybe it shouldn't send this message to both sides if one side is offline.

Environment

None

Activity

Show:
wroot
August 23, 2014, 10:17 AM

I have changed the description of this ticket. In general it is just another racing condition bug which Spark is filled with..

Assignee

Unassigned

Reporter

Jason Sipula

Labels

Expected Effort

None

Components

Affects versions

Priority

Minor
Configure