_mcd_client_registry_list_possible_handlers() currently only uses the given PreferredHandler (if non-NULL) as a last resort, if there are no matching handlers.
In the "normal" dispatching code-path, other code in mcd-dispatcher.c and mcd-dispatch-operation.c special-cases the PreferredHandler (separately) and tries it before the PossibleHandlers, so this is OK.
(As of commit 34e8ab1f4b4e: for delegation, add_possible_handlers() specifically prepends the preferred handler to the list of possible handlers to which it will delegate; for an Ensure operation on channels waiting to be dispatched, _mcd_dispatcher_add_channel_request() calls _mcd_dispatch_operation_approve() with the preferred handler, if any; and for channels created in response to a request, mcd_dispatch_operation_set_property() extracts the preferred handler from the request and calls _mcd_dispatch_operation_approve.)
However, special-cased parts of the dispatching code path, such as Bug #40283, have started to use _mcd_client_registry_list_possible_handlers() (directly or via mcd_dispatcher_dup_possible_handlers()), in a way that passes in a preferred handler but does not then special-case it like this.
I think it'd be less confusing if _mcd_client_registry_list_possible_handlers always included the given preferred_handler (if non-NULL) at the head of the list. We could then refactor add_possible_handlers() to assume this. The special cases involving _mcd_dispatch_operation_approve would have to stay anyway, due to their secondary function of "mark the CDO as approved".
-- 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/47.