Trouble with xhtml extension

SparkWeb
1

How do I use the xhtml extension?

I think it’s broken.

So far, I make sure I register the extension on init:

XHTMLExtension.enable();

Then when I send a message, I set both the message body and htmlBody

I see in the debug output that the right information is there:

I think not!

I think not!

But in my incoming message, I see the XHTML extension, but the body is always empty!

What would make it interpret the contents, but never in a way that’s other than empty?

Thanks,

-jim

2

The deserialize function’s body was empty in XHTMLExtension.as … I changed it to read:

public function deserialize( node:XMLNode ):Boolean
{
// the constructor is passed null,
// so we have to act on the node here
getNode().appendChild(node);

return true;
}

It seems at one point in the future, extensions were always given a node in the constructor… this

changed, but the XHTMLExtension.as was never updated.

3

As best I can tell, that fix doesn’t solve the problem. Message.as simply never deals with an node at serialize or deserialize time. Though the problem could easily lie between the keyboard and the chair.

4

Attached our version of XHTMLExtension.as, and it’s working for us. We’re using the latest XIFF beta3, modified with a couple of the patches applied that we really needed and couldn’t wait.

Dont’t forget to do a:

XHTMLExtension.enable();

once you’ve received your LoginEvent…
XHTMLExtension.as.zip (1561 Bytes)

5

Added the simple line to the “deserialize” method (rev 11549).

This extension would need a lot more investigation, as in fact all the others.

If you can spare time, please move the development to the XML migration branch:
https://svn.igniterealtime.org/svn/repos/xiff/branches/xml-migration/

6

Found a bug I think relates to this - will raise in JIRA as soon as it’ll let me in. XHTML extensions are all working good, we can send chat messages with colour tags now.

When we mute players however, XIFF isn’t happy when Openfire comes back with an error message. It only happens if the user has XHTML in the message they sent.

I’m going to switch our XIFF version to use trunk or the one you recommend. At the moment we’re using the beta 1 version.

Let me know if anyone is having similar issues.

7

I think the problem is almost definitely due to deserialization inside XMPPStanza. Even though we’re using 3.0.1 beta I’ve checked and the relevant code is identical to what is on trunk.

When it receives a forbidden error back from the server the XML has three children, of which the third is the one with nName ‘error’. When the for loop starts around the children there are three children. However, after the second child has been processed and it goes back to the start of the loop, the third child has been lost!

It seems likely it is something to do with the code inside the else to do with the ExtensionClassRegistry.