Bug 265483 - Close the channel when the tab is closed
Summary: Close the channel when the tab is closed
Status: RESOLVED FIXED
Alias: None
Product: telepathy
Classification: Unmaintained
Component: text-ui (show other bugs)
Version: git-latest
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: 0.4.0
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-05 03:24 UTC by Dominik Schmidt
Modified: 2012-07-06 12:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Makes sure the channel is closed (365 bytes, patch)
2011-03-03 16:22 UTC, Lasse Liehu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Schmidt 2011-02-05 03:24:54 UTC
Version:           svn-playground
OS:                Linux

I'm not quite sure if this is correct but it seems to me at first sight.

There should be no difference whether i close a tab or the window (wrt to ending the session)

Reproducible: Didn't try
Comment 1 Lasse Liehu 2011-03-03 14:05:56 UTC
I think I did this with https://git.reviewboard.kde.org/r/100793/ / commit 4b9c8d5c74c9b4c9cbdb71af4db9ad1e8f4a22dc .
Comment 2 David Edmundson 2011-03-03 14:08:54 UTC
I think so too. Would it be possible for you to test it?

Start a chat with KDE Telepathy and another client.
Close the KDE Tp one, make sure the other client shows
"Other User has left the chat" (or some other applicable message)
Comment 3 Lasse Liehu 2011-03-03 16:22:36 UTC
Created attachment 57643 [details]
Makes sure the channel is closed

Tested and it didn't close the channel. I think we could also want to call Tp::Channel::requestLeave somewhere before this destructor, but this at least makes sure it is always closed.
Comment 4 David Edmundson 2011-03-07 16:33:24 UTC
I'm slightly worried about starting an async method on the channel object, and then immediately deleting it before we know it's finished. Potentially that will result in something that doesn't always close or worse crashes.

We quite possibly want to wait for the requestClose/requestLeave to finish before we delete it.

Will check the source code for Tp-Qt4 tonight, and then see what's safe.
Comment 5 David Edmundson 2011-03-07 16:39:51 UTC
From Olli:

It's always perfectly safe to do this in tp-qt4-0.5! We identified
calling some operation and then just forgetting about the object as a
very frequently recurring pitfall in pre-0.5, so we made every
PendingOperation ref the "context" object they need (in the case of
requestClose, that is the Channel) until they finish.

--

In that case - ship it!