| Summary: | Preferred handler doesn't get the channel if too new; no way to handle *only* the request | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Sjoerd Simons <sjoerd> |
| Component: | mission-control | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | high | Keywords: | patch |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/smcv/telepathy-mission-control-smcv.git;a=shortlog;h=refs/heads/prefer-preferred-handler | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 23687, 24120 | ||
| Bug Blocks: | 21003, 24004 | ||
(In reply to comment #0) > In some cases this handler doesn't actually get the channel. From the looks of > it this happend because MC starts dispatching the channel before it has > finished introspecting the recently popped up handler, which means that it's > unaware of the specific filter and ignores the preferred handler. I'd go further than this, and say that as long as the preferred handler exists, it should be the first handler tried even if its filters are known not to match, as you suggested as one alternative: > * Always give it to the preferred handler, even if its filter is unknown (or > even if it doesnt match?) because that makes it easier to write one-shot handlers (like nautilus-sendto) that handle the channel that they themselves requested, but never want to be given channels requested by other processes. (Admittedly, this doesn't matter for n-s, because FileTransfer channels can't usefully be requested on another process's behalf - but it could matter for Tubes, Text etc.) High priority as requested by Sjoerd; to be worked on after Bug #23687. Implemented! ship it Fixed in git For the record, this is fixed in 5.3.2. |
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.
nautilus-sendto does the following when requesting a channel: * pop up a new ClientHandler head with a specific filter * Request the channel with the CLientHandler head as the preferred handler In some cases this handler doesn't actually get the channel. From the looks of it this happend because MC starts dispatching the channel before it has finished introspecting the recently popped up handler, which means that it's unaware of the specific filter and ignores the preferred handler. Two potential solutions for this: * Always give it to the preferred handler, even if its filter is unknown (or even if it doesnt match?) * When dispatching a channel with a preferred handler, block dispatching until the preferred handler has been fully introspected