Bug 23651 - Preferred handler doesn't get the channel if too new; no way to handle *only* the request
Summary: Preferred handler doesn't get the channel if too new; no way to handle *only*...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: mission-control (show other bugs)
Version: unspecified
Hardware: Other All
: high normal
Assignee: Simon McVittie
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/sm...
Whiteboard:
Keywords: patch
Depends on: 23687 24120
Blocks: 21003 24004
  Show dependency treegraph
 
Reported: 2009-09-02 05:43 UTC by Sjoerd Simons
Modified: 2009-11-26 04:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sjoerd Simons 2009-09-02 05:43:45 UTC
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
Comment 1 Simon McVittie 2009-09-15 03:55:01 UTC
(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.)
Comment 2 Simon McVittie 2009-10-16 04:47:47 UTC
High priority as requested by Sjoerd; to be worked on after Bug #23687.
Comment 3 Sjoerd Simons 2009-10-19 02:40:09 UTC
This blocks https://bugzilla.gnome.org/show_bug.cgi?id=598905
Comment 4 Simon McVittie 2009-10-20 15:09:47 UTC
Implemented!
Comment 5 Sjoerd Simons 2009-11-02 08:42:02 UTC
ship it
Comment 6 Simon McVittie 2009-11-02 10:39:52 UTC
Fixed in git
Comment 7 Simon McVittie 2009-11-26 04:53:03 UTC
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.