| Summary: | transfer from chat applet to text-ui hangs | ||
|---|---|---|---|
| Product: | [Unmaintained] telepathy | Reporter: | Martin Bednar <martin+kde> |
| Component: | chat-plasmoid | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | amrecio, kde, mchugh19, simonandric5 |
| Priority: | NOR | ||
| Version: | 0.8.0 | ||
| Target Milestone: | Future | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
text-ui screenshot
log when issue arised Bustle log |
||
|
Description
Martin Bednar
2014-03-13 14:59:19 UTC
Created attachment 85566 [details]
text-ui screenshot
state of text-ui after trying to move chat from applet to text-ui
Next time it happens, could you: 1 run ktp-debugger. 2 Copy and paste me the mission control tab as the attachment. 3 Ideally give me timestamps of approximate when you transferred the chat. so I know where to look. Privacy note: This debug data _will_ contain email addresses of yourself and who you are talking to, but not any message content. I've seen this happen before, if it does happen, restarting plasma relinquishes the chat and it will be visible as a new window. Incoming messages are never lost. ktp-debugger shows nothing at the exact moment I try to switch from applet to window. But it is full of : 13/03/2014 16:25:58.395768 - [tp-glib] tp_cli_connection_interface_contact_capabilities_call_update_capabilities: assertion 'TP_IS_CONNECTION (proxy)' failed This one appeared when I restarted plasma-desktop. Maybe I'm doing something wrong/have some bad setting somewhere. I too see this since upgrading to 0.7.80 in kubuntu 14.04 beta. Eventually the window populates with the im content, but I am unable to enter any text into the bottom. Also, selecting previous conversations opens up the history browser, but it just displays the message "There are no logs for this contact" even though I can see the files in ~/.local/share/TpLogger/logs/gabble_jabber_... Created attachment 85829 [details]
log when issue arised
Enabled chat plasmoid ad 21:44:36 (.793216 more or less)
Tried tranferring around 21:45:33 (.611751 more or less)
What was interesting was that it also happened when trying to open a normal chat while the system was under very heavy I/O load. Tentative timestamp is 21:34:20 (.41674) But that might be a different bug from an older version...
Do any of you happen to have enabled the "Application Menu in Window Decoration" feture? (http://blog.martin-graesslin.com/blog/2013/01/4-10-feature-presentation-application-menu-in-window-decoration/) Your symptoms seem identical to the ones I've described in Bug #333829. Thanks Alvaro! Disabling the menu in window decoration fixed the issue for me. Created attachment 86285 [details]
Bustle log
I can reproduce when delegating channels that were started locally
whereas it seems to work when delegating channels that were started remotely.
Bustle log shows the text-UI channel dispatcher trying to talk to MC and not getting any reply. It then just ignores the channel and the request times out.
I am 90% sure the bug is in TpQt; - during the initial construction it tries to call methods on the ChannelDispatcher to find out about the channel. - The channel isn't listed by the channel dispatcher as another handler has it. - Unfortunately Channel handling code in TpQt is really mental. Quick fix: In the plasmoid, instead of delegating the channel we could just close it; and then call ensureChannel again. I fixed this in TpQt I fixed this in TpQt |