Bug 309146

Summary:	'Audio Call' button opens call-ui although the call-ui-window is already open
Product:	[Unmaintained] telepathy	Reporter:	Lukas Schneiderbauer <lukas.schneiderbauer>
Component:	call-ui	Assignee:	Telepathy Bugs <kde-telepathy-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	heri+kde, kde, mayank25080562
Priority:	NOR
Version:	0.5.0
Target Milestone:	Future
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:	http://commits.kde.org/telepathy-call-ui/70c319c79aee4c4829587cfa7a53a3e1518378f6	Version Fixed In:	0.8.1
Sentry Crash Report:

Description Lukas Schneiderbauer 2012-10-28 13:59:27 UTC

The 'Audio Call' button opens call-ui despite the fact that it is already openend. This results in weird behaviour. For example if an active call is going on and you press the 'Audio Call'-button again (for whatever reasons) a second window opens and one is tempted to close it again because it shows the exact same information the other call-ui window does. But with closing the window the active call-connection gets closed as well. This is likely not what the user intended to do.

Reproducible: Always

Steps to Reproduce:
1. Open chat-ui 
2. Click 'Audio Call'
3. Click 'Audio Call' again
Actual Results:  
A second call-ui window appears.

Expected Results:  
Maybe a focus-switch to the existing window would be a solution. (?)

Comment 1 David Edmundson 2013-01-20 13:50:00 UTC

Confirmed bug in Call-UI. 

It is always up to a handler when told to handleChanenls to check if it is already handling the channel.

Current code does not.

Comment 2 Dennis Schridde 2013-04-06 10:18:08 UTC

Does this persist in 0.6.0?

Comment 3 David Edmundson 2013-04-06 10:20:04 UTC

Yes.

Comment 4 mayank 2014-02-28 18:31:48 UTC

This also happens with the "Video Call" button. Can this be solved, by disabling the button soon the button is clicked, and then re-enabling it once the call-ui is closed ?

Comment 5 David Edmundson 2014-02-28 18:33:12 UTC

>Can this be solved, by disabling the button soon the button is clicked, a

What would happen then if you opened a video call from the contact list, and then opened a text chat?

>and then re-enabling it once the call-ui is closed ?

how will you know when this happens?

Comment 6 mayank 2014-02-28 18:41:13 UTC

We could make use of chat logger, logging in a message once you start a video call, and logging again when you hangup, thus knowing when to disable and when to re-enable again ?

Comment 7 David Edmundson 2014-02-28 18:43:54 UTC

No that's a massive hack. 

The simplest approach is for the call-ui to see if it's already handling a call when it's told to handle the second one. It's all in the same process.
See #1

Comment 8 mayank 2014-02-28 18:52:30 UTC

Yeah right! I was inspired to do this, as in gmail chat, you get to see when you started a call, and when it ended. But to check whether it is handling a call, one would be needing a global parameter to check for, right ?

Comment 9 mayank 2014-03-05 22:46:59 UTC

https://git.reviewboard.kde.org/r/116623/

Comment 10 Martin Klapetek 2014-03-18 15:23:27 UTC

Git commit b4626ae5b866464d9abfa2762b979224dbb4b589 by Martin Klapetek, on behalf of mayank jha.
Committed on 18/03/2014 at 15:22.
Pushed by mklapetek into branch 'kde-telepathy-0.8'.

Removes duplication of call-ui window for a single channel
REVIEW: 116623
FIXED-IN: 0.8.1

M  +5    -3    src/call-handler.cpp
M  +2    -0    src/call-handler.h

http://commits.kde.org/telepathy-call-ui/b4626ae5b866464d9abfa2762b979224dbb4b589

Comment 11 David Edmundson 2014-05-15 15:10:04 UTC

Git commit 70c319c79aee4c4829587cfa7a53a3e1518378f6 by David Edmundson, on behalf of Vadim A. Misbakh-Soloviov.
Committed on 15/05/2014 at 15:10.
Pushed by davidedmundson into branch 'kde-telepathy-0.8'.

Properly removes duplication of call-ui window for a single channel.

Fixes issue, made by b4626ae5b866464d9abfa2762b979224dbb4b589,
where call-ui dont make call at all, due to the typo in condition.

REVIEW: 118151

M  +1    -1    src/call-handler.cpp

http://commits.kde.org/telepathy-call-ui/70c319c79aee4c4829587cfa7a53a3e1518378f6