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
(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.
This blocks https://bugzilla.gnome.org/show_bug.cgi?id=598905
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.