Summary: | Close the channel when the tab is closed | ||
---|---|---|---|
Product: | [Unmaintained] telepathy | Reporter: | Dominik Schmidt <kde> |
Component: | text-ui | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde |
Priority: | NOR | ||
Version: | git-latest | ||
Target Milestone: | 0.4.0 | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Makes sure the channel is closed |
Description
Dominik Schmidt
2011-02-05 03:24:54 UTC
I think I did this with https://git.reviewboard.kde.org/r/100793/ / commit 4b9c8d5c74c9b4c9cbdb71af4db9ad1e8f4a22dc . 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) 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.
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. 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! |