Last modified: 2009-07-30 13:14:08 UTC
The above example URL shows a wiki where XML-documents are managed using templates and forms. XML uses many characters that also have special meaning in MediaWiki, but most of those do not need any escaping, since they do not occur in contexts that MW recognizes. There are two exceptions:
* Comments in XML are written as in MediaWiki. To prevent MW from interpreting them, it is necessary to write "<!--" on the wiki page instead of "<!--".
* XML entities are unescaped by MediaWiki during parsing. So to get an escaped entity like "<" into a semantic property value, one needs to write "&lt;" in the input.
Both encodings work in MW and SMW. (A more general but less user-friendly strategy would be to escape all <, >, ", ... in the input fields. This would be more systematic, but most cases work pretty well without such escapes.)
Now the problem is that, when editing with SRF, the text that is loaded into the form does not contain the original entities, i.e. it shows "<!--" where the page included "<!--" and it shows "<" where the page included "&lt;". Either SF does too much unescaping, or it simply passes on literal escaped text to the browser who unescapes it for display. In any case, "edit with form" changes the page contents even if the user does not modify the form contents at all.
Tested on FF 3.0.10, MW 1.14alpha, SMW 1.5e-SVN, SF 1.6.
The problem also occurs for #-style escapes as required for working around Bug 19063. In other words, the workaround, after being implemented by a knowledgeable user, will be destroyed as soon as the page is edited by someone who is not aware of this, or who forgets to re-encode one occurrence of the escapes after editing.
This is fixed in version 1.7.2.
I cannot confirm the fix after upgrading to SRF 1.7.3. Using "edit with form" on the below example pages (using HTML and hex entities, respectively) still shows the expanded characters, and round-tripping fails when saving.
Okay, this time (in version 1.8) I think it's *really* fixed. Feel free to re-open again if not, though.
Confirmed: the bug seems to be fixed now. Very nice!