| Summary: | When a client loses any well-known name, MC thinks it has crashed | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | mission-control | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | Keywords: | patch |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/smcv/telepathy-mission-control-smcv.git;a=shortlog;h=refs/heads/misc | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Patch and release preparations in http://git.collabora.co.uk/?p=user/smcv/telepathy-mission-control-smcv.git;a=shortlog;h=refs/heads/misc - I'd like to get this released tomorrow. Fixed in 5.1.4 |
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.
> if (old_owner[0] == ':') > { > /* it's a unique name - maybe it was handling some channels? */ > _mcd_handler_map_set_handler_crashed (priv->handler_map, > old_owner); > } Both occurrences of "old_owner" here should be "name". Consider a handler with multiple names, like the fake Kopete in test/twisted/dispatcher/bypass-approval.py: * unique name, say :1.94 * main well-known name ...Client.Kopete * sub-handler to claim special channels without approval, ...Client.Kopete.BypassApproval Now consider what happens if Kopete no longer wishes to bypass approval. MC sees this NameOwnerChanged signal: * owner of ...Client.Kopete.BypassApproval changed from :1.94 to nothing That shouldn't cause it to take any special action (except removing the .BypassApproval filter). However, because of the above logic error it's interpreting it as if it was: * owner of :1.94 changed from :1.94 to nothing which is what happens if Kopete crashes, causing all its channels to be closed.