|Summary:||_mcd_client_registry_list_possible_handlers doesn't fully respect PreferredHandler|
|Product:||Telepathy||Reporter:||Simon McVittie <smcv>|
|Component:||mission-control||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||NEW ---||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
Description Simon McVittie 2011-09-20 03:56:46 UTC
_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".