[Bug 43166] Sending chatstate messages in muc doesn't please some server

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43166

--- Comment #11 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #10)
> http://cgit.collabora.com/git/user/wjt/wocky/log/?h=muc-fixes adds
> policy-violation to the set of XMPP errors recognised by Wocky, fixes a bug
> which clobbered the type='' attribute, and passes more details of the error
> (including its message) to the WockyMuc API user.

Looks good.

> http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=43166-muc-
> rate-limit makes Gabble map policy-violation to Permission_Denied and
> include the error text in the delivery report.

Also looks good, apart from a 'print parts' that crept into the last commit.

> Unfortunately it exposes a
> tp-glib bug/issue: the legacy Received signal gets the text of the error
> from the server (which seems fine) but loses the Non_Text_Content flag
> (because there is text content).

Hmm. I think the solution to this is probably that Message_Type_Delivery_Report
should trigger Non_Text_Content? In my original draft of DeliveryReports, they
would have had { 'interface': '...DeliveryReports' } in the header, which I
think does trigger Non_Text_Content, but that was lost when delivery reports
became a core part of Messages in a later draft.

This might be a bit more significant than it looks, because on the client side,
telepathy-glib Messages clients use the same code to make tp_message_to_text()
output Non_Text_Content if necessary.

If you don't want to fix this right now, please open the bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.