[Pidgin] #7814: xmlnode_from_str reads in extraneous detail from formatted XML files, makes xmlnode_to_formatted_str unhappy

[Pidgin]

#7814: xmlnode_from_str reads in extraneous detail from formatted XML files, makes
xmlnode_to_formatted_str unhappy
--------------------------------------+-------------------------------------
 Reporter:  darkrain42                |        Owner:           
     Type:  defect                    |       Status:  new      
Milestone:                            |    Component:  libpurple
  Version:  2.5.2                     |   Resolution:           
 Keywords:  xmlnode, xml, formatting  |  
--------------------------------------+-------------------------------------

Comment(by darkrain42):

 Conversation from devel at cpi:
 {{{
 (09:02:06) deryni: darkrain42: Does it look to you like once pidgin sees
 any xmlnode DATA that nothing should ever be pretty again?
 (09:02:21) darkrain42: Yes
 (09:02:21) darkrain42: That's how I'm reading this...
 (09:02:36) darkrain42: But, when I look at my accounts.xml, I see data in,
 e.g., the <protocol> tag
 (09:03:01) deryni: Good, at least we are equally confused.
 (09:03:21) deryni: This may be a problem with how we read data in.
 (09:03:34) deryni: Since he is using the direct xmlnode from reading and I
 don't think we do.
 (09:32:41) darkrain42: deryni: When printing out the xmlnode read in, this
 is the first child of the root node (gdb edited):
 c->type == XMLNODE_TYPE_DATA, c->data == "\n        ���e\177", c->data_sz
 == 9
 (09:33:00) darkrain42: (there are 9 characters up to but not including the
 first question-mark thingy)
 (09:36:54) deryni: That's before the xml declaration?
 (09:38:20) darkrain42: The XML declaration doesn't appear in the xmlnode
 read in. That's the first child of the launchinfo xmlnode. It seems to
 correspond to the pretty-formatted newline and 8 spaces between
 <launchinfo> and the first <game>
 (09:39:12) darkrain42: It's treating that as cdata (and now that I think
 about it, I'm not sure it shouldn't...)
 (09:39:31) deryni: It probably should, and that will almost definitely be
 the problem.
 (09:40:38) deryni: Hm, actually, I'm not sure that should be cdata.
 (09:41:09) darkrain42: Why not?
 (09:45:24) deryni: Hm, given that we don't have a DTD it (libxml2)
 probably should be giving us the whitespace and letting us decide what to
 do with it, I think we are wrong in considering it data.
 (09:53:28) deryni: I wonder if specifying the ignorableWhitespace entry in
 the xmlSAXHandler struct might be of use here.
 (09:55:36) deryni: Or not, the documentation indicates it is unused.
 (09:56:20) darkrain42: heh. That might also break the cdata in, e.g.,
 saved status <message/>s (though that could be fixed by encoding it)
 (09:57:35) darkrain42: What about xmlKeepBlanksDefault?
 (09:58:37) deryni: We might be able to 'fix' this by dropping a previous
 DATA node when we encounter a TAG node, since I don't believe we ever have
 both data and tags as children of the same element. (Though plugins
 proabably could, as I'm assuming that is valid even though horribly ugly.)
 (09:59:14) deryni: Alternatively, we could just try to fix
 xmlnode_to_str_helper. =)
 (09:59:45) darkrain42: That might also break XHTML IM, which definitely
 intermingles cdata and tags
 (10:01:49) deryni: Yeah, dropping data is almost certainly the wrong fix.
 }}}

-- 
Ticket URL: <http://developer.pidgin.im/ticket/7814#comment:1>
Pidgin <http://pidgin.im>
Pidgin