| Summary: |
conn_requests_requestotron_validate_handle should use tp_ensure_handle_async() |
| Product: |
Telepathy
|
Reporter: |
Will Thompson <will> |
| Component: |
tp-glib | Assignee: |
Telepathy bugs list <telepathy-bugs> |
| Status: |
RESOLVED
MOVED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
major
|
|
|
| Priority: |
medium
|
CC: |
xclaesse
|
| Version: |
git master | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
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.
The latest release of tp-glib allows dynamic handle repos to normalize identifiers asynchronously. (Upsetting that this is necessary.) conn_requests_requestotron_validate_handle(), as used by the implementations of CreateChannel and EnsureChannel, transforms TargetID properties provided in requests into handles for the benefit of the CM. It does so using tp_handle_ensure(), not tp_handle_ensure_async(), and hence is now broken. (I'm setting major severity because I think this is a pretty big deal: through a totally valid user input, you can now end up with two handles where you should have one. Relatedly, TpChannelManagerRequestFunc contains the following documentation: > Changed in version 0.15.5: Previously the TargetID property was guaranteed to be missing from request_properties. Now it is always present, whether it was in the original channel request or not. I think it should be pointed out that the TargetID property may not match the result of tp_handle_inspect(request_properties[TargetHandle]) due to normalization. This has always been the case—in fact, that was the point of passing through the TargetID, to allow CMs to process stuff (like dial strings) that gets stripped out in normalization—but it would be good to explicitly document this.