| Summary: | create_and_handle doesn't work if you get two channels back from a request | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Will Thompson <will> |
| Component: | tp-glib | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | libreoffice-tubes | ||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 32612, 50828 | ||
| Bug Blocks: | |||
(In reply to comment #0) > 11:02 cassidy | let's just kill Tubes channel Yeah I'm trying to get rid of "Tubes" from gabble right now. It's taking a lot lot longer than I'd hoped. :-( I have worked around this in the LibreOffice tubes code for now by firing off an ensure_channel_async() request for the legacy Tubes channel before any modern DBusTube request. This has no user-visible side-effects. Jonny tells me he has finished a branch to remove legacy Tubes from Gabble, which will render the workaround unnecessary but harmless. I just looked into the MUC tubes code in Gabble. It looks like the legacy Tubes channel is announced together with the Text channel in some cases, but modern DBusTube channels are not: /* Announce tube channels now */ /* FIXME: we should probably aggregate tube announcement with tubes and text * ones in some cases. */ Which is good news, because it means this bug won't resurface as and when LibreOffice is made to use a MUC. (Users will be startled by a text window appearing in their face, but that's a different bug.) Now that Tubes channels have been removed from Gabble and Salut, and Text and Tube channels are announced separately, this shouldn't be a problem anymore. I'm closing this bug. Feel free to reopen if I've missed something. (In reply to comment #3) > …Tubes channels have been removed from Gabble and Salut… … as of git master. The next versions will be: telepathy-salut 0.9.0 telepathy-gabble 0.17.1 Hopefully they'll come soon. (In reply to comment #0) > But if you create_and_handle a 1-1 Tube channel, sometimes (but not always, > apparently…) you get both a Tube and a Tubes back in the same blob. When it's released, Mission Control 5.13.1 will also cut up plural NewChannels signals into several singular NewChannels signals (Bug #52305), so this has been fixed from two different angles; it'll work if you have a new MC and/or new CMs. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
From account-channel-request.c: static void handle_channels (TpSimpleHandler *handler, TpAccount *account, TpConnection *connection, GList *channels, GList *requests_satisfied, gint64 user_action_time, TpHandleChannelsContext *context, gpointer user_data) { TpAccountChannelRequest *self = user_data; TpChannel *channel; if (G_UNLIKELY (g_list_length (channels) != 1)) { GError error = { TP_ERRORS, TP_ERROR_INVALID_ARGUMENT, "We are supposed to handle only one channel" }; tp_handle_channels_context_fail (context, &error); But if you create_and_handle a 1-1 Tube channel, sometimes (but not always, apparently…) you get both a Tube and a Tubes back in the same blob. I'm basing this on seeing this debug message in my logs and intuition: I haven't actually looked at the bus traffic and the error message provides no interesting information. (I will add more details to the error shortly.) 11:02 cassidy | let's just kill Tubes channel 11:02 cassidy | (we have to keep them internally in the code but can remove them from the bus) Are there any other cases where a request returns a plural reply? I think MUC tubes might be one case.