talk-android icon indicating copy to clipboard operation
talk-android copied to clipboard

Conversation title often shows different recent conversation

Open jancborchardt opened this issue 2 years ago β€’ 10 comments

Steps to reproduce

No specific steps to reproduce, but this happens often here in regular use of the app, closing again, using multiple channels.

Expected behaviour

The title in the header is always the one of the conversation shown.

Actual behaviour

Sometimes it glitches out and shows a title which does not match the conversation being shown. (The conversation is always the correct one as tapped.) As shown here, the conversation is with Nimisha, but the title is from the Groupware team. This creates uncertainty and possible privacy issues as it’s unclear where the message will be sent: Talk header

Device information

Device: Fairphone 3+

Android version: 10

Talk version: 14.0.2

Server information

All current cloud.nextcloud.com

jancborchardt avatar Jun 30 '22 12:06 jancborchardt

Also experienced this in the past sometimes, the glitch is that some data in the toolbar is from the last conversation opened before the current one, but is is just the toolbar, usually the avatar of a 1on1 conversation but I don't have a reproducible step-by-step guide for it.

AndyScherzinger avatar Jun 30 '22 12:06 AndyScherzinger

My impression is that using the "internal back function" of android (instead of the "back arrow" on the upper left of a chat room) does trigger this issue. I cannot completely reproduce, but the following steps result quite often in this issue:

  1. open a chat and leave it open or minimize talk
  2. receive a notification message (from another chat/person)
  3. open new chat by tapping on notification
  4. switch back with internal android function (swype left on my device, not the back button on the upper left!!!)
  5. Talk switches back the the previous chat mentioned under step 1 (not the main chat overview, which would be the case if the back button on the upper left would have been pressed).
  6. most of the times, the title of the chat at least flickers for a moment... other times, it just shows the wrong title/avatar... even going back to the chat overview and the chat again does not solve this issue and the wrong title/avatar is shown or switches back and forth.

I got already some shocking moments when I wasn't sure to whom I just wrote a personal message 😁.

EDIT: I'm also using multiple accounts with talk. Not sure whether this could affect this issue somehow.

XueSheng-GIT avatar Jul 01 '22 11:07 XueSheng-GIT

Thanks @XueSheng-GIT for the detailed guide and analysis! @mahibi my guess is that it is related to the life cycle, like when the data is set, if on create then this might be a pointer where it should the. Be checked to put it in on resume.

AndyScherzinger avatar Jul 02 '22 07:07 AndyScherzinger

the problem seems to be that leaveRoom() is not executed successfully when pressing the back button (and other "leave" scenarios?), which results in multiple calls of getRoomInfo() (because of it recursive call) with different roomTokens. will have a closer look in the evening

mahibi avatar Jul 13 '22 13:07 mahibi

There must be multiple scenarios why this can happen.

Yesterday while developing, this issue occurred extremely often. This is because of PR https://github.com/nextcloud/talk-android/pull/2176 (which was merged after the creation of this issue, so it's not the reason of this issue but has the same effect).

In onDestroy() the disposables were not disposed. Instead this was "only" done in onComplete() of leaveRoom(). See https://github.com/nextcloud/talk-android/commit/a24f49c73785d5b618726bc7822831ef7a4a742e#diff-6b47d0e9875a7f7d5c1e6b80feab998e92d29b0cda8ac9bbf427aab99e56d209R1827 Because it is now executed in onDestroy() , the leaveRoom() method is not executed successfully because it's destroyed too early. This results in multiple calls of getRoomInfo() with different roomTokens.

To reproduce, just switch between 2 different conversations..

As onDetach() already executes leaveRoom() which then should execute disposables.dispose() in onComplete() , this should do the job, but as there are some conditions here, this might be the reason why this failed also in the past sometimes..

So asking @AlvaroBrey and @AndyScherzinger if we should just revert to dispose the disposables in onDestroy() or if this should be improved architecture wise. And if you have ideas why this failed also in the past sometimes..

mahibi avatar Jul 14 '22 07:07 mahibi

With https://github.com/nextcloud/talk-android/pull/2215 the recent change (disposables disposed in onDestroy) is reverted which caused that this bug occurred even more often.

Other scenarios still need to be analyzed and fixed, so the issue will remain open also when https://github.com/nextcloud/talk-android/pull/2215 is merged

mahibi avatar Jul 14 '22 08:07 mahibi

does this still happen for anyone with versions >= 14.2.0?

mahibi avatar Sep 12 '22 07:09 mahibi

Issue still persists with 14.2.0! I have it regularly, still as described here https://github.com/nextcloud/talk-android/issues/2181#issuecomment-1172224102

XueSheng-GIT avatar Sep 12 '22 08:09 XueSheng-GIT

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

github-actions[bot] avatar Oct 11 '22 01:10 github-actions[bot]

Yes, mentioned by various people at the conf too

AndyScherzinger avatar Oct 11 '22 11:10 AndyScherzinger

Just happened to me again with latest version too:

  • I had a conversation open with Person A, went do do something else (I think Android just went to sleep)
  • When opening it back up, the conversation and name of Person A was correct, but the avatar shown was of Person B, who I previously wrote with.

jancborchardt avatar Nov 17 '22 11:11 jancborchardt

the title flips through the last opened rooms, so it is not simply using "the former/wrong" one but it seems to be some stack that gets looped.

AndyScherzinger avatar Nov 25 '22 16:11 AndyScherzinger

I suggest to start setting a breakpoint in setTitle() in the BaseController und hit it with the debugger looking at the call stack where the overwritting calls come from

AndyScherzinger avatar Nov 25 '22 16:11 AndyScherzinger