GNOME Bugzilla – Bug 396372
& in attributes in .glade files load as & instead of &
Last modified: 2011-07-19 23:06:04 UTC
Please describe the problem: libxml2 returns & in attributes as & instead of & by default Steps to reproduce: 1. Using glade-2 or glade-3, make a button whose "Name" attribute contains a & e.g. "button&1" 2. Save project 3. Notice how saved .glade file is ok 4. Load the file into an application using libglade 5. Try to fetch the widget "button&1" Actual results: I get a NULL pointer in return Expected results: To get the "button&1" widget pointer Does this happen every time? yes Other information: The actual problem is in the usage of the sax parser in the libxml2 library, and it has been reported as a bug multiple times, for example Bug #172638. The problem also exists in glade-3 and I have reported that as Bug #396311. The example in the "how to reproduce" part is not the only occurence where attributes are used for user-typed text, it's just easy to test. At least ATK actions contain a "description" attribute that thus has the same problem. In #172638 you see that the "problem" is actually expected default behaviour, and the default can be changed (so that libglade works properly) by calling xmlSubstituteEntitiesDefault(1); before starting the sax parsing and restoring the original behaviour afterwards (to avoid breaking other parts of the software possibly using libxml2). I have tested my fix in glade-3 and it works fine, and I have made a the same fixes in libglade (but haven't tested them since I'm quite certain it works :). I'll attach my patch which does the changes mentioned above in the two places where the sax parsing occurs.
Created attachment 80225 [details] [review] fix for CVS HEAD at Jan 14 2007
I don't think changing the _default_ value (xmlSubstituteEntitiesDefault) is safe to do in a library (what if another thread in the programme uses a parser at the same time)? IMHO, what should be done instead is to create a xmlParserCtxt to parse the document and set the flag only for this context.
Well, libxml2 stores those variables per-thread so it's safe.. as long as the calling program initializes libxml2 as specified on the libxml2 "thread safety" statement page. Yeah maybe it would be possible create a context yourself and all that.. but with the thread-safety in place I would say it isn't worth it unless it can be done in some 10 lines.. I mean, my fix is quite clean after all.. Apologizes if I went too far in suggesting what to do - in the end, I'm happy if it gets fixed regardless of how it's really done :)
The GNOME Release team has officially deprecated libglade in favor of GtkBuilder[1]. So it's unlikely to get further development. I am closing bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development. [1] http://permalink.gmane.org/gmane.comp.gnome.devel.announce/28