| Summary: | When Delegating handlers are given a Requests_Satisfied path that doesn't exist | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | David Edmundson <kde> |
| Component: | mission-control | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Bustle log | ||
(In reply to comment #0) > - MC sends sends a HandleChannels call to my AppB with a all the normal > stuff and a path to the ChannelDispatcherRequest path as the > Requests_Satisfied: > @ao ["/org/freedesktop/Telepathy/ChannelDispatcher/Request24"] You're right, that sounds like a MC bug: the request finished ages ago, so we shouldn't be referring to it any more. > - TpQt does it's introspection and tries to load the request from the > ChannelDispatcher > - it fails with "GetAll" with signature "s" on interface > "org.freedesktop.DBus.Properties" doesn't exist" > - TpQt then explodes and ignores the request. I think this is also a TpQt bug, or possibly design flaw (but perhaps one that you can't fix without breaking API, so you might need to fix it in 'next'). In telepathy-glib we deliberately didn't require, or wait for, the ChannelRequest to prepare successfully, because it takes a round-trip and approximately nobody is going to need it. The main purpose of Requests_Satisfied is matching up channels you're being asked to handle with either requests you started (if you create/ensure channels), or channels whose channel request you were previously asked to approve (if you're an Observer or Approver). If you're doing either of those, you have a TpChannelRequest already, it's probably already prepared too, and all you need to do is match it by object path or by object identity, for instance looking it up in a hash table { channel request => chat window }. If you're not doing either of those, HandleChannels seems too late for the channel request to be useful. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/80. |
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.
Created attachment 98062 [details] Bustle log What's currently happening: - App A has a channel. - App A tells MC to delegate a channel to AppB - MC sends sends a HandleChannels call to my AppB with a all the normal stuff and a path to the ChannelDispatcherRequest path as the Requests_Satisfied: @ao ["/org/freedesktop/Telepathy/ChannelDispatcher/Request24"] (this is the same request path as when MC gave App A a HandleChannels) - TpQt does it's introspection and tries to load the request from the ChannelDispatcher - it fails with "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist" - TpQt then explodes and ignores the request. From what I can tell there is no request object on MC, as the channel is already handled. I think we should modify _mcd_client_proxy_handle_channels to have some argument to know if it is delegating channels and if so not send any Requests_Satisfied. Am I right? If I modify TpQt to silently ignore loading the ChannelRequest error, everything works perfectly. I've attached a quite simply bustle log of the problem.