Open Bug 98168 (doe) Opened 23 years ago Updated 4 months ago

<xsl:text disable-output-escaping="yes"> not working

Categories

(Core :: XSLT, defect, P4)

Product:
Core
Component:
XSLT
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: troyer, Unassigned)

References

(
URL
)

Details

(Whiteboard: See comment 140)

Attachments

(4 files, 2 obsolete files)

catalogue.xml - testcase file
439 bytes, text/xml
Details
catalogue.xsl - a testcase files which demonstrates the problem
656 bytes, text/xml
Details
Challenge.html - a file which explains what the testcase files are about
2.13 KB, text/html
Details
A workaround template written in XSLT (updated)
17.24 KB, text/xsl
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010829 BuildID: 2001082905 The tag <xsl:text disable-output-escaping="yes"> does not work as it should, i.e. the escapes in &lt; is not converted to < and interpreted as the starting character of the tag <B>. Instead <B> is displayed literally. Reproducible: Always Steps to Reproduce: 1. open the URL http://ogdoad.ethz.ch/xml/bug.xml Actual Results: equivalent to HTML &lt;B>Bold&lt;/B> Expected Results: equivalent to HTML <B>Bold</B> I am aware that this is not great XSL, but it is an example extracted from actual code produced by a commerical graphical XSLT editor package. IE6 displays the file as it should, but Mozilla has problems. Since this is incorrect behavior it should be fixed.
I disagree. What you are asking is that we do the transform, serialize the result and then parse the result again. The Transformiix module does a tree to tree transformation, and we will not serialize/reparse. In the module, we could completely ignore section 16 (and that would not be incorrect behaviour). I think we should implement as much as possible out of it, but this is not on my list. I'll leave this open for the standalone Transformiix, I think we still need to fix it there.
Assignee: kvisco → peterv
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Priority: -- → P4
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.0
adding to that, please file an tech evangelism bug on the editor. Put Peter and me on CC
Whiteboard: [standalone]
Does that mean that it's going to get fixed or not then? I got confused by the ending of it. I need to put apostrophes into some text and without disable-output-escaping I can't.
It's not going to be fixed in the Transformiix Mozilla module, it is going to get fixed in the standalone Transformiix because that one serializes it's output tree.
Matthew: There is nothing that you can do with disable-output-escaping that you can't do without it, except produce non-valid xml and i assume that you don't want to do that... why can't you just do <foo>'</foo> if you want an apostrophe? The reason that we won't do anything about disable-output-escaping for module is that it dosn't do anything. It's a noop when outputting a DOM like transformiix does. So you could actually say that we do support it
I agree with those who say that there is nothing that cannot be done without it. There is however at least one graphical XSLT design program, the one in the new release 4.0 of the popular XMLSpy suite (www.xmlspy.com), which for some technical reasons uses it in some locations. The XSLT files they produce work correctly on all standalone transformers, and it also display correctly in version 6 of Internet Explorer. I fear that if this new tool becomes popular there might be a large number of XLST files produced which rely on the feature.
Matthias: could you please file an evangelism bug in that product so we can get them to fix thier broken code. Thanks
I would like to output non-breaking space entities and compose anchors on the fly. I currently do this using disable-output-escaping="yes" and it works everywhere except NS6
just use &#160; instead of &nbsp; and it'll work just fine everywhere and you won't need any disable-output-escaping hacks
I think it should be fixed in mozilla. Right now I must transform my XML on server side, but I'd like to do it in mozilla. My XML contains HTML fragments encoded like this <some-tag> <![CDATA[ <a href="http://www.mozilla.org">This should be a link</a> ]]> </some-tag> Problem is that HTML fragment may not be valid (it is entered by hand). All I want to do is transofrm it to a HTML page. Right now I'm doing this like this <xsl:value-of select="." disable-output-escaping="yes"/> and it works fine but not in mozilla.
I think there is some misunderstanding here. The W3C spec is very clear: "An XSLT processor will only be able to disable output escaping if it controls how the result tree is output". The Transformiix module integrated in Mozilla only generates a tree, it does not and will never output (serialize) the result tree to a XML document (nevertheless subsequently reparse that to a tree). If that is what you want (XML document->parse->transform->serialize->XML document), I suggest you find a way that works with trees or use a server-side processor.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Check the url http://netpr.pl/bin/xml.cgi?id=217&style Without ability to disable output escaping body of a message is rendered as html source. It works fine when transformed with Sablotron on server side, but it would be nice to make it possible on client side (as it works in IE6.0)
Please stop advocating in this bug, use the newsgroup if you must. I'll repeat it one last time: we are not fixing it in the Transformiix Mozilla module.
this was fixed for standaloen together with the output rewrite. So we could go three ways with this: 1. Close it 2. morph into fluffy dream about parsing escaping-disabled text in module in a far far future when people travel using mindcontrolled teleporters 3. morph into an "evang and document" bug
I think we should close this.
agreed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 140651 has been marked as a duplicate of this bug. ***
*** Bug 142234 has been marked as a duplicate of this bug. ***
we didn't verify for a long time. I really checked, so VERIFIED.
Status: RESOLVED → VERIFIED
*** Bug 194008 has been marked as a duplicate of this bug. ***
*** Bug 197471 has been marked as a duplicate of this bug. ***
*** Bug 197988 has been marked as a duplicate of this bug. ***
As per bug 215360, I'm reopening to make sure we get a consistent resolution here. Now that I've bothered half my friends on the project ;) can somebody just say this is by design and move it to WONTFIX, and/or document the correct way to implement this? (/me runs)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whichever resolution we give it will be half true. It is implemented in the standalone version of the processor but not in the Mozilla module and that's the way it will stay.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WONTFIX
*** Bug 215360 has been marked as a duplicate of this bug. ***
You're the boss. VERIFIED
Status: RESOLVED → VERIFIED
We could reinvestigate this decision if we ever make up a good way to support document.write as well. If we handle one, we can easily handle the other. See bug 176668
*** Bug 219309 has been marked as a duplicate of this bug. ***
*** Bug 220280 has been marked as a duplicate of this bug. ***
Anyone that just wants to output an entity, like &nbsp; or &copy; should just use a numerical entity instead, like &#160; or &#160;. So <xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text> simply becomms &#160;
*** Bug 222445 has been marked as a duplicate of this bug. ***
*** Bug 231753 has been marked as a duplicate of this bug. ***
*** Bug 233921 has been marked as a duplicate of this bug. ***
Why don't you just serialize xml+xsl output to text and treat it as an input to the rest of engine? It'd fix bugs with javascript document.write and document.body an this feature who a lot of people find anoying enough to post a bugreport. What's the tradeoff for changing architecture in such way?
because it would be a huge hit to performance
It should take just as much time as doing transformation and rendering page from pure text/html. Is that really such high price for meeting expectation of your users? For many people it will be easier to just ignore that mozilla has any xsl capability at all and do transformation on the server side than to find structural walkaround of your decision. Twice as high performance is no gain if you don't use it. When you design web application you expect xml+xsl to generate html as you told it to. You don't want tree transformations. You just want your stylesheet applied on client side. Xsl is very interesting technology, I currently try to migrate from some template library to xsl stylesheets. It's really good idea that can help lower transfers between client and server and lower server processor load a little bit. For such a migration it'd be great if I could use html fragments already written wich often are not properly formed xml by just putting them in CDATA sections with quouting disabled.
> It should take just as much time as doing transformation and rendering page from > pure text/html. No, it's going to take that amount of time *plus* the time it takes to execute the XSLT stylesheet, which in many cases is a significant amount of time. See all the bugs filed on XSLT pages being slow (some of them are closed for various reasons) Anyway. Please read this entire bug. There are a lot of reasons why we don't support d-o-e. Such as spec says we shouldn't, you can't do anything with it that you can't do without it, supporting it encourages bad stylesheets, even if we did support it stylesheets would be faster if they were changed to be correct rather then to use d-o-e, etc, etc. Again, please read this entire bug, and a few of the bugs being duplicated against it. Most of your questions have already be asked and answered.
I've read this bug and all duplicates. Maybe I describe my problem in little more detail and you or maybe someone else can give me some advice. My webapges consists of three parts: - opening of layout (title bar, left panel, few opened <table>s) - content (area for most information) - closing of layout (right panel, footer, few closed </table>s) I have few different openings, and few differnt closings that can be used i different combinations. I'd like to define html fragments for each of them in different xsl files and <xsl:include>-them in central stylesheet containing layout for content. I can't do it in mozilla because if you insist that result of xsl transformation must be tree then result of each <xsl:template> match must be complete node, and all of my layout openings and closings have only halfnodes :-) Please check my example in bugreport. It's pretty much something like this, but templates defining layout for opening and closing are defined in different files. I find it is really a shame that it all works in IE 6.0 as in W3C specifications and just as I expect to. :-) and fast i guess i'll just parse it on server side for mozilla ...
The only timewhen you need to use d-o-e is if you have markup as data in your source XML. All other cases can be solved using proper XSLT. And even in that case you can use .innerHTML to solve your problem. However this bug is not the forum for XSLT education so I won't go into details here. There are plenty of XSLT newsgroups and mailinglists that can describe the solution for you. So we are not going to implement it unless someone comes up with a patch or pays us to do it. And even in that case the implementation needs to not slow down the engine, break the current architecture or add too much codebloat.
*** Bug 236363 has been marked as a duplicate of this bug. ***
*** Bug 240162 has been marked as a duplicate of this bug. ***
*** Bug 244970 has been marked as a duplicate of this bug. ***
*** Bug 245504 has been marked as a duplicate of this bug. ***
It is so annoying when everyone talks about different ways of doing something without any example or even an helpful link. So here is my example to the rest of you guys: Making the dynamic link: <a href="{LINK/address}"><xsl:value-of select="LINK/text" /></a> This solution has been tested on IE and Mozilla and it will do the same thing as text-block + d-o-e + CDATA do on IE.. ;)
*** Bug 251434 has been marked as a duplicate of this bug. ***
Why does the Mozilla community refuse to fix this bug? The reference implementation, which is still Internet Explorer (flamebait), supports the XSLT spec properly - why doesn't Firefox/Mozilla? This is very frustrating!
*** Bug 258395 has been marked as a duplicate of this bug. ***
*** Bug 258732 has been marked as a duplicate of this bug. ***
(In reply to comment #47) I agree with you! It's a very strange attitude from people making OPEN software!
(In reply to comment #50) > (In reply to comment #47) > I agree with you! It's a very strange attitude from people making OPEN software! When they're diplaying html it's probably like this: html-textfile => parsed-html-tree => rendering-page-from-tree When they're displaying xml + xslt it's probably like this: xml-textfile => xml-tree => tranformation => html-tree => rendering-page-from-tree Output of xsl:text is always escaped because it transforms to html dom text-node. To disable output escaping displaying xml+xslt should work like this: xml-textfile => xml-tree => tranformation => html-result-tree => html-text => parsed-html-tree => rendering-page-from-tree And they refuse to do it because they think It would have a huge performance hit. I'm sure IE does the same but it's fast enough. I can't imagine how come mozilla could be slower by doing the same thing.
Attached file catalogue.xml - testcase file —
This attachment is one of two files which demonstrates why this by should be fixed, a html file has also been attached which explains thier usage.
This attachment is one of two files which demonstrates why this by should be fixed, a html file has also been attached which explains thier usage.
This attachement contains the html posted to the mozillazine forum, which challenges people to come up with a solution if one is available - if not then this bug needs to be fixed.
I have added three attachments to help demonstrate this bug and added a discussion to the MozillaZine forum: http://forums.mozillazine.org/viewtopic.php?t=136981 Please take this opportunity to demonstrate how this bug can be worked around, rather than just saying it can be.
That's one of the worst examples of why you'd need d-o-e. Do some research instead of bugspamming, there are plenty of examples on the web for grouping. See for example http://www.jenitennison.com/xslt/grouping/
*** Bug 262466 has been marked as a duplicate of this bug. ***
*** Bug 264135 has been marked as a duplicate of this bug. ***
*** Bug 270366 has been marked as a duplicate of this bug. ***
The main reason I want to do d-o-e is because I want to send XHTML content down a RSS feed within my description so feed readers can render nicely formatted text at the end. I don't see why I should have to do this server side when the browser could do it for me but as it stands I'm going to have to add another page to my app and make additional calls to the server to get this done
Hi, first I'm sure you won't fix this, I'd just like to say one thing perhaps overlooked till now. Perhaps I'm wrong. I'm sorry then. In comment 1 Peter says that Transformiix may ignore section 16 completely. Problem is that section 16 is a bit confused itself. One may look at disable-output-escaping as at a feature only allowing some tricks but there are more issues. The primary idea of output escaping is simple. If you have <xsl:text>&amp;</xsl:text> or more obvious syntax <xsl:text><![CDATA[&]]></xsl:text> you really have this -> '&' sign in your data and want to have it in your output. In other words if you perform an identity transformation your data will be literally the same as the input. Problem is that if you use disable-output-escaping you will not get the same data. From this point of view you modify not only how the output is serialized but you really modify the output tree. From this point of view arguing that Mozilla only builds output tree is a bit weaker then before. Shortly XSLT spec. mixes output escaping with methods modifying the output tree. You may object that you still build the only valid DOM tree, but it true only until you suppose serialization of the output to be a plain projection of the DOM model. XSLT is not really exact on this and you have chosen one interpretation of it. you are right if you want, but don't blame people to expect something else. They have good reason to expect the output tree to be modified because XSLT serialization really does it. Don't eat me alive... :)
Pavel: when you consider that Mozilla doesn't make a distinction between eg. "&nbsp;", "&#160;", "&#xA0;" or the equivalent UTF-8 sequence in a normal XHTML document, there isn't really much of a reason to use output escaping tricks to put an entity in the result tree that will just be interpreted the same as if you just put the character itself in the result tree (which can be done without output escaping). The main places I've used disable-output-escaping are: 1. producing files suitable for some website templating system that doesn't fit into a DOM tree, which usually look something like this: # some directive to include a standard header <content goes here> # some directive to include a standard footer This use is not relevant to Mozilla's XSLT because you need to do this processing before the data gets to the client for the server side directives to get processed. 2. Doing something useful with evil file formats like RSS which actually contain escaped content that you don't want escaped in the result tree. This one is possibly relevant to Mozilla's XSLT if you want to serve RSS files directly to the client. There are a few work arounds for (2). One is to use a format that doesn't require you to escape the content (eg. Atom). The other is to output some javascript in your result document that removes the content escaping. Something like this: <head> <xsl:if test="system-property('xsl:vendor')='Transformiix'"> <!-- Mozilla ignores disable-output-escaping --> <script type="text/javascript"> function onload_cb() { var elements = document.getElementsByTagName('div'); for (var i = 0; i &lt; elements.length; i++) { var el = elements[i]; if (el.className == 'description') { el.innerHTML = el.firstChild.data; } } } </script> </xsl:if> </head> <body> <xsl:if test="system-property('xsl:vendor')='Transformiix'"> <xsl:attribute name="onload">onload_cb()</xsl:attribute> </xsl:if> ... </body> The above will generate some javascript that will go through the document and fix up the display of any divs of class "description" if using Mozilla. For other browsers, it is assumed that the disable-output-escaping attribute will work.
*** Bug 298654 has been marked as a duplicate of this bug. ***
*** Bug 298888 has been marked as a duplicate of this bug. ***
*** Bug 301727 has been marked as a duplicate of this bug. ***
(In reply to comment #62) > if (el.className == 'description') { > el.innerHTML = el.firstChild.data; > } firstChild.data here returns "undefined" and should be firstChild.textContent instead. There is also a generic JavaScript "cleaner" file that you can include with your generated HTML that will determine if the browser it's being called from supports d-o-e or not, and if not (as with Mozilla and FireFox), will attempt to clean up and re-render the portions that need it. This JavaScript file was written by Sean M. Burke, is public domain, and can be found at http://www.fadshop.net/xsl_mop-up.js. More information can be found at http://fadshop.net/blog/2005/07/firefox-doesnt-support-disable-output.html.
*** Bug 306965 has been marked as a duplicate of this bug. ***
Here's a real-world test case.. Works great in IE, not in Firefox 1.5, because disable-output-escaping="yes" is ignored: Taking one's Google Earth placemark file, and rendering it into HTML. Google Earth lets you enter HTML in the Description field for a placemark. The tool encodes the XML - that's out of your hands. All you can do is write a stylesheet. If you want the HTML that the Google Earth user entered (such as an <IMG SRC="..."> tag) to be displayed in html AS THAT HTML, then the only way to do it is via disable-output-escaping="yes". Placemark as encoded by Google Earth: ################################################## <Placemark> <name>Jeff in Kauai</name> <description><![CDATA[<CENTER><a href="http://www.keegan.org/jeff/homemovies/05_11_2001/thumbs-640/DSC00089.JPG"> <img src="http://www.keegan.org/jeff/homemovies/05_11_2001/thumbs/DSC00089.JPG" WIDTH="144" HEIGHT="108"><BR><BR>On our honeymoon</CENTER></A><BR>]]> </description> <LookAt> <longitude>-159.6379001672474</longitude> <latitude>22.16000876849679</latitude> <range>1619.143300178664</range> <tilt>66.91575385990892</tilt> <heading>37.48591068133026</heading> </LookAt> <styleUrl>#khStyle590</styleUrl> <Style> <IconStyle> <Icon> <href>root://icons/palette-4.png</href> <x>192</x> <y>96</y> <w>32</w> <h>32</h> </Icon> </IconStyle> </Style> <Point> <coordinates>-159.6461690593752,22.15189108277365,0</coordinates> </Point> </Placemark> ################################################## The only way to render that description correctly is to do: <xsl:value-of select="kml:description" disable-output-escaping="yes"/>
the provided javascript as a workaround won't work if "Linkification" extension is enabled. even worse the elements after and including the first html will vanish.
I totally disagree with the comments made here: (a) Such as spec says we shouldn't, This is total **** as the XSLT spec at http://www.w3.org/TR/xslt#disable-output-escaping clearly says <quote>Normally, the xml output method escapes & and < (and possibly other characters) when outputting text nodes. This ensures that the output is well-formed XML. However, it is sometimes convenient to be able to produce output that is almost, but not quite well-formed XML</quote> It goes on to say <quote>An XSLT processor is not required to support disabling output escaping.</quote> Note that NOT REQUIRED TO SUPPORT IT is not the same as MUST NOT SUPPORT IT. (b) you can't do anything with it that you can't do without it, This is also total **** because if I have a text node which contains an HTML fragment I want it output as an HTML fragment and not as a piece of text, such as what happens when '<' and '>' are converted into '&lt;' and '&gt;'. GThere is no other way around this. (c) supporting it encourages bad stylesheets, This again is total ****. If the W3C spec says that it is allowed then your XSLT processor should allow it. If you can't do it, it just proes what second-rate programmers you are.
Tony, if you don't mind your wording in the future, we'll consider administrative actions against it.
Ooooh! What sensitive little darlings you are!
XSLT seems wonderful to be for having self-describing data files (which is what I often use it for). I've tried working around Mozilla's limitation of not displaying escaped HTML by using JavaScript to force the re-translation... only to hit another Mozilla limitation that dynamic code generation via JavaScript does not work with Mozilla's XSLT... You guys are killing me. I'm left with the pityful alternative of using Javascript to warn the customers to use Internet Exploder. Come on! You guys must be more creative then this? Just check if D-O-E is set to "yes" and re-parse the field. Even a delay is preferable to forcing the customer to switch browsers.
the Linkification problem has been fixed. see also http://www.beggarchooser.com/forum/index.php?topic=37.0
How about supporting disable-output-encoding in the case that the fragment is well-formed? That wouldn't require reparsing the entire document, but I think it would allow web developers to do most of what they want d-o-e for (e.g. using XSLT on evil file formats like RSS that unnecessarily include XML as text).
*** Bug 335305 has been marked as a duplicate of this bug. ***
When my well-formed XML source contains an encoded special character, like &#237; (which corresponds to an acuted i - "Ă­"), after the transformation, what I get is something like: "&amp;#237;". Is not that I want to embed HTML in the XML (if I got it well, that is what is considered bad-formed XML). Instead, I'm using the recommended encoding-neutral way to include a special character. Could it be possible that, when the D-O-E flag is set, the transformer avoids changing such escape sequences and pass-them as they come?
That bug was submitted 5 years ago. Still not fixed in Firefox 2.0 beta 2. What exactly are you people waiting for ? Shame on you.
It seems that there are arguments in favor and against fixing this bug, to say the least. But in any case, it would be good to have a known workaround. Are there examples of JavaScript that could deal with that ? I suppose it would be possible to look for the tags (&gt; followed by &gt;) in the text of the page, and replace them by tag, in the DOM tree I suppose. I'm not very experienced in Javascript, does anyone know of a good example ?
I'll answer my own post :-) There is an excellent piece of Javascript written by Sean M. Burke that does the work, and Scott Mitchell has written a very complete tutorial on how to make it work in the case of RSS (which is probably 95% of the cases - at least is was mine :) the jscript is at: http://aspnet.4guysfromrolla.com/rss/disableOutputEscaping.js explainations are at: http://www.4guysfromrolla.com/webtech/100505-1.shtml My 2c would be that since (or *if*) this javascript does the job it's OK not to fix the bug. After all, XSL on the client is not a feature that is very common, and Mozilla is (and should stay) "everybody's browser" -- not the browser of geeks who do wacky things with RSS :-). But this would be true only *if* the workaround is good. Could someone from Mozilla review the javascript, and confirm that is will not cause other problems ? thank you You can find
The javascript fix is unacceptable to me as I do not use javascript anywhere in my application, and I refuse to use it to get around a stupid browser problem. This is a bug in the browser, pure and simple, and nothing less than a full and proper solution will be acceptable.
> The tag <xsl:text disable-output-escaping="yes"> does not > work as it should, i.e. the escapes in &lt; is not converted to > < and interpreted as the starting character of the tag <B>. > Instead <B> is displayed literally. The tag xsl:text is about the text you wish to display. If your browser would interpret the text as part of your DOM I would say that is a bug. (Even whilst you are have incorrect text inside an element.) If you have HTML elements in XML you wish have in your endresult HTML-DOM you should treat those elements as elements. For this I use <xsl:copy-of> to copy a subtree out of my XML DOM to my HTML DOM. For example: <xsl:for-each select="body-paragraph"> <p> <xsl:copy-of select="."/> </p> </xsl:for-each> on the XML fragment: <body-paragraph> Go and get <a href="http://www.mozilla.org">Mozilla</a> now! </body-paragraph>
Here is an example of why this is needed. Solr, the Lucene based open source search application, has this feature called highlighting <http://wiki.apache.org/solr/HighlightingParameters>. When this feature is on, Solr returns an XML result that includes XML fragments like this: <arr name="feedName"> <str>&lt;em&gt;BBC&lt;/em&gt; Arabic News</str> </arr> Firefox would read this into the DOM tree, interpreting the character references (&xxx;). In the DOM tree, Firefox has this string "<em>BBC</em> Arabic News" as the value of this str element. If this str node is processed by: <xsl:value-of select="." disable-output-escaping="yes"/> XSL processor within Firefox should output the node as: <em>BBC</em> and the HTML rendering engine within Firefox should render the string BBC in an emphasize form, as opposed to render "<em>BBC</em>". The users don't want to see "<em>BBC</em>" nor would not understand what it means. Fixing this shouldn't be very difficult. The XSL engines just needs to skip the conversion to character reference temporarily. (Even) IE does it right. I don't want to ask my users to use IE, because Firefox doesn't handle the disable-output-escaping attribute. Please reconsider the decision.
I think that the best fix for people who want to use XML data-driven sevices is using some free XML standard-compliant web browser. Like Konqueror for Linux, Internet Explorer for Microsoft Windows and Safari for Mac. XML is the data format of present and future and we should promote standard compliance.
This ended up being a major roadblock to convert our software from a php template engine to client side xml/xslt. In a perfect world all html would be perfect and every open would have a close etc... But end users don't see nor care about this. We have end users inputing bad html into our db where we pull from "<i>blog text <b>I want this bold</i></b>" this happens, I can use tidy etc... to clean but still most browsers are tolerant of this and will render it anyway. so simply saying only have valid xhtml and use copy-of to get the result your looking for doesn't seem to be good enough. 1. Copy-of Solution for the perfect world, do not encode entities in entry or wrap with cdata. -- the xml doc -- <blogs> <entry> I <b>love</b> blogging. </entry> </blogs> -- the xsl doc -- ... <xsl:copy-of select="entry" /> ... 2. Imperfect solution for the imperfect world use javascript innerHTML to populate the area with all your bad html :) below is a reference to a site that has this method well documented. http://use.perl.org/~TorgoX/journal/24272 3. Get the source and start making a patch that (x's fingers) mozilla will include in next release. Which is what I'm going to do. 4. Beg Peter and send him candies and flowers until he feels so guilty he decides that he must address this cause it will make him feel warm and fuzzy inside.
This bug still persists on Mozilla Firefox 2.0.0.10 (running on Windows XP). The tag <xsl:value-of disable-output-escaping="yes" .../> does not work as hoped. Test sample: XML: sample1.xml -------------------------------- <?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet type="text/xsl" href="sample1.xsl"?> <main> <value><p>ab<b>ac</b>o</p></value> <value><![CDATA[<p>ab<b>ac</b>o</p>]]></value> <value>&lt;p&gt;ab&lt;b&gt;ac&lt;/b&gt;o&lt;/p&gt;</value> </main> -------------------------------- XSL: sample1.xsl -------------------------------- <?xml version='1.0' encoding="ISO-8859-1"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="main"> <html> <head> <title>Transformation test</title> </head> <body bgcolor="#FFFFFF"> <xsl:apply-templates select="value"/> </body> </html> </xsl:template> <xsl:template match="value"> <xsl:value-of select="." disable-output-escaping="yes"/><br/> </xsl:template> </xsl:stylesheet> -------------------------------- The transformation differs from Internet Explorer.
Oh guys... This is ridiculous... Why can't you fix a missing implementation of w3c recommendation? Firefox is getting worse, than the good old times... Nowadays 2.0.0.11 is so buggy as hell. I don't have day without crash, and now it comes this. I can't solve a simple problem (embed (X)HTML in XML transformed with XSLT), because you are mad (excuse for this expression, but I don't find words, because I was wasting my time, founding a working solution in Firefox...). You, developers, should pay attention to users, who are trying to help you make firefox better, more usable... Now, I have to use server-side XSL Transformation which is very ugly I think. You shouldn't participate in open source projects!
Here's another real-world situation where Firefox's lack of support for '<xsl:text disable-output-escaping="yes">' is harmful, and for which there's no workaround. The Google Search Appliance controls appearance of search results via an XSLT file. The XSLT file can be edited on the server via a text field, which is messy, or it can be exported to a client and edited there, testing the resulting appearance in a browser. Problem is, the Google Search Appliance XSLT file contains numerous instances of '<xsl:text disable-output-escaping="yes">', and these can't be edited out. So Firefox's tools are useless for editing this file. It may be true, as has been said earlier, that "there is nothing that you can do with disable-output-escaping that you can't do without it". But if XSLT files in real-world applications are using disable-output-escaping, and if we're stuck with editing those XSLT files, then Mozilla/Firefox is making a stand that's leaving its users without a decent solution.
Every other XSL transformation engine in the entire universe provides proper support for disable-output-escaping, so Firefox is the odd one out and therefore non-standard. The developers' reasons for refusing to fix this SERIOUS bug are, quite frankly, pathetic in the extreme and simply do not wash with the multitude of users who have encountered it. The statement that "there is nothing that you can do with disable-output-escaping that you can't do without it" is ABSOLUTE B*LL*CKS. I want to use it on a text node which contains valid HTML, and which I want treated as HTML in the browser and not displayed as text. There is *NO* work-around to this problem with Firefox. The only alternative is to switch to a more standards-compliant browser, such as (gasp!) Internet Explorer. Saying that you cannot fix it without incurring an unacceptable hit on performance is also ABSOLUTE B*LL*CKS as every other transformation engine seems to manage OK. Come on guys, get your heads out of your rear ends and do the right thing.
Today I had a bug filed against my website relating to this. I spent countless hours trying to understand why disable-output-escaping wasn't working in my application. Then I found this thread and was very disappointed by what I found. First of all, it strikes me that the reasons for Firefox not implementing this are too esoteric. The common implementation - as generally implemented throughout the industry - are to implement this feature. That, in my mind makes it a general part of the standard, It should be implemented even if there is an obscure argument - that 99% of developers (myself included) won't understand for not implementing it. Second, this feature is silently not implemented so that I, and countless others, end up wasting many many hours trying to track down the issue. Third, much of the arguments against implementing this seem be based around a holier-than-thou attitude that the input documents shouldn't have been written that way to begin with. Except I am dealing with an external feed (that I can't change) and it is correctly implementing the RSS standard (and the Atom standard calls for this too). Its seems invalid to argue against this. Fourth, the reason that RSS and Atom feeds call for HTML elements to be escaped in content is that HTML, unlike XML, is not as rigorous in its structure. A perfectly good HTML fragment need not be perfectly good XML - and not all HTML tools output XML-valid HTML. While this looseness is frustrating to developers, that looseness is something that browsers must work with - it is a very big part of the success of HTML for the masses. Fourth, the JavaScript workarounds results in a mess in my code. I don't know how many times I have seen Firefox zealots criticize the extremes one must go to to get CSS in IE6 to work correctly. Don't throw stones... comes to mind. Sixth, it seems that everyone over the years have dug their heals in so much on this issue that it has gone beyond a rational argument - people are arguing for the sake of preserving their opinion rather than is doing what is the right thing to do. That is irresponsible on many levels and it tarnishes the image of Firefox. Please correct this bug - it would be the right thing to do - even if it can be argued that it isn't the correct thing to do.
Another reason why your "this is not a bug" attitude is so ridiculous is that you clearly have not read the standards regarding a CDATA section (refer to http://www.w3.org/TR/REC-xml/#sec-cdata-sect) which states quite clearly (and I quote): ... that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "&lt;" and "&amp;". Thus if I create a CDATA section containing left angle brackets and ampersands whch I do not want escaped it is quite legitimate to use disable-output-escaping="yes". This means that I can insert HTML into an XML document and have it treated as HTML (not escaped) and not XML (escaped).
To the Firefox/Mozilla team: it would be useful to have a more recent statement from you on your policy on this. The most recent one was years ago, and it said > There are a lot of reasons why we don't support d-o-e... > ... you can't do anything with it that you can't do without it, > supporting it encourages bad stylesheets, even if > we did support it stylesheets would be faster if they were changed > to be correct rather then to use d-o-e, etc, etc. but since then, many examples have been provided for which the developers (us) are having to edit third-party XSLT files which DO use d-o-e, and we're stuck with it, and are not receiving support from Firefox. Some sort of statement from you would be useful.
I've read though this entire bug from the first to last entry. It amazes me that this problem has not been resolved since 2001. It plainly ridiculus. I have a very simple example that does not seem to be mentioned earlier. None of the earlier proposed solutions seem to work. We have spent most of the last 3 weeks converting our application to work across IE 6, IE 7, Sarfari, and Firefox, and only Firefox seems to have this problem. The sample below attempts to use the work-around that was mentioned earlier of using the character codes to avoid the need for escaping, but this does not work on Firefox for my simple sample. If I have misunderstood the workarounds suggested then please correct me. The alternative of moving the XSLT transormation to the server is really a ridiculous suggestion for something so simple. The argument that performance impacts preclude fixing this in the browser is also ridiculous since any attempt to fix this in Javascript will require walking the HTML tree using am interpreted language, vs, the Firefox browser walking the tree and fixing the escapes in an compiled language. Clearly the resulting overall performance to the end-user is better if the fix is performed by compiled code in the browser. (By "browser", I mean the entire application - I don't and users don't care about the various modules that make up the Firefox browser). The suggestion that you have to rebuild the entire tree to fix this is also suspect to me. I don't know the internals of Firefox, but the XML, HTML and DOM tree before and after has the same structure in this simple sample. I would suggest that the fix to Firefox be limited, if necessary, to scenarios where only properties of the object trees are manipulated, but the trees retain the same basic structure. Perhaps if I am wrong about before and after trees structure being the same in my simple sample, then this is area where Firefox can be improved during the fix. The question about use of performance is a design issue that can be bargained. There is no absolute here. If the performance were to degrade slightly when d-o-e is used, then that is the consequence of the application designer's choices. This is not he only area where we application developers have to make these kind of choices. I submit that this is our choice to make - not the Firefox tool designers. I believe that you should be able to develop a fix where XSL stylesheets that do not use d-o-e have the current performance, and those that do use d-o-e may have some small performance impacts. I believe most application developers would conside this an acceptable design point - we can have the non-do-e performance or the d-o-e performance simply by choosing our application design approach. <xmp> <!-- sample.xml --> <?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet type="text/xsl" href="sample.xsl"?> <Parent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0"> <Person id="1" first="Peter" last="Beken" alias="He"/> <Person id="2" first="Van" last="Der" alias="does not"/> <Person id="3" first="Der" last="Beken" alias="get it"/> </Parent> <!-- sample.xsl --> <?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="Parent"> <html> <head> </head> <body> <table border="1"> <tr> <th> </th> <th>First</th> <th>Last</th> <th>Alias</th> </tr> <xsl:for-each select="Person"> <tr> <!-- checkbox --> <xsl:text disable-output-escaping="yes">&#60;td&#62;&#60;input type='checkbox' id='</xsl:text> <xsl:value-of select="@id"/> <xsl:text disable-output-escaping="yes">' value='</xsl:text> <xsl:value-of select="@id"/> <xsl:text disable-output-escaping="yes">' /&#62;&#60;/td&#62; </xsl:text> <td><xsl:value-of select="@first"/></td> <td><xsl:value-of select="@last"/></td> <td><xsl:value-of select="@alias"/></td> </tr> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet> </xmp>
For your example, I am not sure why you need disable-output-escaping="yes" to achieve those results. What is wrong with doing something like: <td><input type="checkbox" id="{@id}" value="{@id}" /></td> While there are some places where disabling the escaping is necessary, this does not look like one of them.
This has to be one of the most ridiculous issues that I have ever encountered in all my years of working with open source. The comments from the "Developers" make them sound more like spoiled children throwing tantrums than reasonable adults who are able to get along with other adults in an imperfect world. I have to perform XSLT transforms on a half-a-million-record database that is populated with various html entitites. These entities are entered by individuals who use the commonly accepted notation (&trade;). When they then view the records they have created, they find that when displayed directly in their browsers (no XSLT transformations), these entities display correctly (TM). That being the case, it would be difficult to convince these people - who live in the real world like most of us - that they must use numeric entities just to satisfy the narrow-minded view of the Firefox XSLT developers. Safari XLST transformations of these entities work correctly; even Internet Explorer renders them correctly. The only combination that fails to render these entities correctly is Firefox/XSLT. After using Firefox as my preferred development environment for years, I am starting to prefer Safari for development. Please just fix this.
Reopening to reflect the real status of this bug. We've always been open to fixing this, someone just needs to step up and provide an acceptable patch (don't slow down non-doe transforms). BTW, insulting developers is about the worst way to motivate someone to fix this.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: mozilla1.0.1 → Future
I might do this at some point in the future, but not now. If someone else wants it they should take it, I'll reassign if I get to it before that.
Assignee: peterv → nobody
Status: REOPENED → NEW
QA Contact: keith → xslt
> BTW, insulting developers is about the worst way to motivate > someone to fix this. Peter, in fairness, there've been numerous very polite posts that were entirely ignored (See comments 93 and 95, for example). Nonetheless, it's great that the Firefox developers are looking at this now. Thank you very much!
I'll try to fix the bug, does any one know where to find the pre-made patch(s)? Or no patch yet? I've viewed most of the dup bugs, only test cases found.
There are no patches yet. What you need to do is to implement output handlers that rather than create a DOM create a serialization (possibly by hooking in to the existing serializer code) and then parse that serialization into a DOM.
I've been hacking these code for days. It seems that there is no way to make this bug's testcase work except serialization and re-parse. But there still have a way to stop slow down the none doe xslt, eg. 1) we make a flag to mark whether the xslt file used doe feature or not 2) when we do dom 2 dom translation, we serialization the xslt output into a string buffer also. 3) if the xslt does not require doe feature, we just return the generated dom; if not, we parse the serialized string, and create the target dom. As a side affect, the method will cause a larger memory consume. And might greatly slow down the doe-needed xlst's speed, I've no idea about that. Another hacking is injecting the doe generated code into the xlst source.
I think the strategy would be to either automatically enable the 'serialize-and-reparse' mode when there is a doe element somewhere in the stylesheet (this is trivial to detect during stylesheet parsing). Or we can require a special attribute to be added to the xsl:output element. The former is nice since it makes existing stylesheets work "automatically". However it is also ugly since it makes the stylesheet slower, as well as makes it behave differently in some edgecases, without any obvious reason why.
Need an in-line JavaScript workaround? See my lib source here for example code: http://ajamyajax.com/ajaMyXSL.html or download the entire lib to get actual source (it's all free): http://ajamyajax.com/ Hope this helps.
An idea for implementation, along the lines of the workaround. (Note that I am *not* familiar with the related code, but this seems like an approach that would not alter the tree-to-tree transformation process.) If it's possible, create an internal-only wrapper DOM element, and restrict its usage to the XSLT process. If that element is encountered during the transformToFragment, transformToDocument, or the actual document-writing process in <?xml-stylesheet?>, then the wrapper DOM element is discarded and its text content is parsed as HTML. That would avoid the issues I'm getting with the el.innerHTML = el.textContent workaround, which does not execute the contents of <script> tags written with d-o-e. That said, come _on_ now. None of the other FOUR main flavors of browsers out there have this problem (even remotely). When you load a document with d-o-e on one of them, it Just Works. There _are_ very legitimate usages for it, and the blame for the hard dead-ends lies squarely with Mozilla here. Doesn't Firefox 3 use libxslt now, anyway? (Same as Safari and Chrome?)
In February of last year I submitted to comment about this bug - disappointed that a seven year old bug had turned into a ridiculous idealogical debate instead of a real-world issue deserving of a fix. Now I come back over a year later to check on the status of this bug and what do I find. Nothing. The treatment of this bug makes a mockery of the open source argument. The next time that some throws open source in my face, I am going to direct them to this thread.
You mean the argument that open source is great because if the people working on the software don't have time to work on the bugs that matter to you, you can fix the bugs yourself, or find someone that does have time to fix it?
Guys, this thread has been going on for almost 8 years! In the mean time the IE, Safari, Opera and Chrome have had the support for this feature all along. In 7 years the processing speed of an average computer increased by an average of 5 times, and the available RAM in average computer has also increased by about 5-10 times! The argument that this feature adds extra processing overhead has now become irrelevant - the computers are just too fast these days and the supposed 'extra overhead' will add probably less than 1 millisecond. Human eyes cannot possibly notice this difference. Another important point is that while you (the developers) have been arguing that this will add extra processing time, someone has written a javascript as a specific workaround for Firefox lack of disable-output-escaping feature The feedburner.com has been using this fix for years now. You can google for it, it's called 'godecoding' So you see, the argument for not wanting to add overhead has lead to people having to use javascript to add this missing functionality and of cause using javascript for this is a lot more overhead that just implementing this feature in your xsl processor. This reminds me of a situation in my former job. A sysadmin has implemented a policy to change our login passwords once a month and required passwords to be 12 chars long. He argued that this will add more security. It turned out to do exactly the opposite as all employees started to write down their password on posted notes and sticking them to their desks or monitors. The situation with the Firefox developers refusing the implement disable-output-escaping=yes feature and arguing that this feature is not secure is really similar to the story with passwords I just told you - it has good intentions but produced the exactly opposite result
I've tried to dig the issue. But not an easy thing, for in Gecko, XSL Translation is a tree to tree process. So the problem is everything have been parsed into a tree (if they can) before the parser find out that they do NOT need to parse the 'disable-output-escaping=yes' context at all. So, this is a design issue, not a few lines patch can be fixed. I've no time to do such a deep hacking. But as you've been watched this issue for 8 years, why not try to fix it by yourself?
All I can do is keep using the javascript hack. Maybe Firefox should switch to a different xsl processor.
Probably now output tree of xsl transformation is passed directly to rendering engine to be displayed. It should be instead serialized to plain text and passed to html parsing engine. It does not require any architectural changes. It's probably how other browsers do it. I proposed this five years ago and it was dismissed as supposed big hit to performance. I failed to see validity of this argument back then and I'm still failing to see it now. Personally I use javascript workaround. XSL generates document.write('') that displays actual effect of transformation.
Yes, serializing and reparsing is what we'd like to do. Help with writing such a patch would be greatly appreciated. Whining about why such a patch has not been written is not as appreciated.
Most people who submit bugs dont know anything about programming mozilla browser. I don't even know what language it's written in. I have a habit of submitting bugs any time I see a bug in any program I use. I think this is a good way to contribute to development. We just assume that developers are super smart gurus who can always find a way to fix a bug. The ability to insert the formatted HTML into xml in a form of CDATA is not much different than adding innerHTML to DOM element. innerHTML is not even a part of the w3c standard, but ALL browser support it. Imagine if Firefox did not support innerHTML because developers would argue that its not a part of DOM standard. How hard it would make the development of most Ajax scripts, as most of them use innerHTML at one point or the other.
I feel disappointed. Sorry, this is not something to help solve the bug, obviously you know how to fix it, the problem is that you don't want it. I aways defend firefox all the time, its the best browser ever... But this option of escaping stuff is really important to me and seems to be important to a lot of people. What stress me the most, is that this does not create a warning on firefox error console, like most stuff related to xml/xslt, you have no clue what you are doing wrong, because browsers simply don't tell you that you are using something that you shouldn't. If firefox doesn't support that feature, why can't you put a tiny little message on the console saying that it won't work because of it? Do you know how many hours I spent to get to this place? you may think "well, its your time, get over it bleh" but the problem is that the least thing I would expect is that it was a known firefox bug(if it can be called as bug). I aways create stuff on Firefox than fix to run on other browsers... Sorry my english.
I have this problem too. My problem is, I have to embed an HTML fragment (written by the user or an HTML generator tool) inside the generated page. The XML source contains obviously some tags containing entity encoded text (like &lt;b&gt; and so on) and I have to insert the corresponding data (tags or character entities : <b>, ...) verbatim. I agree with Jonathan, it is very, very disapointing.
Attached file A workaround template written in XSLT (obsolete) —
This is a template designed to replace the use of <xsl:value-of select="..." disable-output-escaping="yes"> in Transformiix and other transformToFragment-based browsers (Opera, Safari, Chrome), while the functionality remains unsupported in those engines. disable-output-escaping works in those other browsers when used on an XML page that loads with <?xml-stylesheet type="text/xsl" href="..." ?>, but does not work when client-side Javascript executes a transformation using the transformToFragment() method of the XSLTProcessor instance. The template works by parsing through the text character-by-character, determining where elements and attributes start and end, and creating real XML elements and attributes in their place. No guarantees are made about the accuracy of the content, but the code has been tested to work with a variety of common usage cases. Any corrections or improvements are welcome.
(number of people waiting for this bug to be resolved)++
(In reply to comment #119) > (number of people waiting for this bug to be resolved)++ Comments without actual facts (such as this one, sorry!) only make harder to crawl through the useful comments... :-| The best way of doing this "me too" thing is through voting (I've noticed you aren't in this bug's voting list). ;-)
Previous workaround template, updated with named-entity support.
Attachment #433858 - Attachment is obsolete: true
Previous workaround template, updated with named-entity support. Fixes a bug in the previous update with entities in text preceding HTML elements. Sorry for the quick double-update!
Attachment #408748 - Attachment is obsolete: true
Come on, i'm waiting for a ten years now. I'm promise to send a $100 to guy who implement this. I agree with #110 - other browsers do this functionality for years, wtf? btw, the real problem that many people want to use is not simple &nbsp; character, they (and me) want to put into xslt-parser the ill-formed html code. For example, i'm a CMS-developer and want a transformation of content of shop-item properties which handled as xml. Part of xml-tree is escaped item html-description which well-formless i cannot grant, and so i doesn't want to do a <xml:copy-of>, i just want to <xml:value-of d-o-e> and make the things on. Of course, because of Firefox i use a server side transformation. But in last project i have a task to do a ajax load of pages, and i have to rewrite a many xsl's to javascript implementation, instead of just using browser xslt.
This feature is needed. Or how do you output a custom DOCTYPE with some custom entities ? (so that you cannot use the "cdata-section-elements" of <xsl:output>) For what I understand of XSLT, here is the proper way to do it : ---------------------------------------------- <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes" /> <xsl:template match="/"> <xsl:text disable-output-escaping="yes"> <![CDATA[ <!DOCTYPE custom "-//CUSTOM//My custom DTD//EN" "http://www.urltomycustomdtd.dtd" [ <!ENTITY myentity "entityvalue"> ]> ]]> </xsl:text> </xsl:template> <!-- various other xsl templates here--> </xsl:stylesheet> ---------------------------------------------- This works in every browser BUT Firefox, although it SHOULD work.
You can use my fix It's here http://ra-project.net/xsl_tests/fix_ff_xsl.zip And tests http://ra-project.net/xsl_tests/test2.html It works in any browsers. --------- About fix I use jQuery to xsl-transform. But you can use it with any your js-scripts. How to use 1. add include to your xsl-file <xsl:include href="../fix_ff_xsl/fix.xsl"/> 2. instead <xsl:value-of select="xxx" disable-output-escaping="yes"/> use <xsl:call-template name="inc_disable_output_escaping"><xsl:with-param name="param" select="xxx"/></xsl:call-template> 3. and call js-script after transform (when DOM was updated) fix_ff_disable_output_escaping();
(In reply to comment #122) > Created attachment 434081 [details] > A workaround template written in XSLT (updated) > > Previous workaround template, updated with named-entity support. Fixes a bug in > the previous update with entities in text preceding HTML elements. > > Sorry for the quick double-update! Hi, as I do not want to use javascript I have found your workaround very helpful... but I have problems getting named-entities to work as I expect. in XML I have <html_part><![CDATA[<b>Text &#9829; Text</b>]]></html_part> in xslt I need content of <html_part> to be used as part of rendered html page. I use: <xsl:call-template name="disable-output-escaping"><xsl:with-param name="string" select="html_part"/></xsl:call-template> In IE everything is ok as expected and the heart is rendered in place of &#9829; (standard way is used) In Firefox included html tags works just fine (text is formatted in bold), but instead of heart I see text &#9829; (& is rendered as &amp;)... Is there still a mistake in submitted workaroud, or am I missing something?
Well, Mozilla doesn't want to. But they even don't have to. http://www.w3.org/TR/xslt#disable-output-escaping Quote: "An XSLT processor is not required to support disabling output escaping." Maybe here is the wrong place to complain about that, maybe we should contact w3c to make this requiered? Maybe the better way, huh?
Over three years ago I complained about this now 10 year old bug. I was shocked back then to discover, after wasting many hours trying to track down a bug that wasn't mine, just how unreasonable the responsible developer(s) for this feature were being. A year later I came back to see if there had been any progress. Nope. Just more arguing. Now another two years later where are we? Nowhere! I guess this is ok. There is no law that browsers should be standards compliant. But it is disappointing as IE finally becomes a standards compliant browser that Firefox is the lone holdout against standards.
I argued the need for this feature a few years ago, but after seeing that nothing was going to happen I moved on (which required browser detection and conditional logic in the XSLT to handle Firefox.) Now the only time I think about this issue is when I get an infrequent email alert from this thread. Frankly I was amazed by the "Can't do" attitude of the lead developers. I can't tell you how many times I have seen similar arrogance destroy user bases and companies. Two notable examples that come to mind are Wang Laboratories and Digital Equipment Corporation. End user and third-party developers contributed to the success of those companies, and when they started ignoring their developer base they both went downhill quickly. And where are they now? At one time Firefox a clear favorite, but times are changing. Check the size of the shrinking Firefox bars in the chart in this article: http://www.zdnet.com/blog/networking/browser-wars-chrome-winning-ie-losing/1119 Could attitude again be a contributing factor?
Just reminding that although a year elapsed since the previous comment, the reported behaviour still persists in Firefox 14.0.1.
(In reply to ivegner from comment #130) > Just reminding that although a year elapsed since the previous comment, the > reported behaviour still persists in Firefox 14.0.1. The behavior is intentional and conforming to the spec. You are asking for something that would require lots of work, and would make transformations very likely slower. Also - most of the time - d-o-e isn't needed at all, and the request for it indicates a design problem in the XSLT code. I recommend to set the status of this issue to RESOLVED/WONTFIX.
The XSLT specification calls out this feature at: http://www.w3.org/TR/xslt#disable-output-escaping - Since when does requiring a lot of work override conforming to a spec? - Can you perhaps quantify slower? Since when is doing something wrong fast better than doing something right? - So you acknowledge that while "most" of the time d-o-e isn't needed, your use of "most" is an implicit acknowledgement that situations do exist where it is needed. Those situations are not the result of bad XSLT code, they are the result of having to process input files that you can't fix. In my case, about 5 years ago, the situation was processing RSS and Atom feeds that contained snippets of HTML. Those HTML snippets were not XML compliant, and nor were they required to be. I wanted to simply take the HTML in the snippets and embed them into my transformed document. The Atom/RSS feeds were not in my control, were fully compliant with their specs, and my use of XSLT's d-o-e feature was a perfectly rational way to deal with this situation. Because of the bad attitude by Firefox's developers, I was forced to push all XSLT transforms back to the server. This had a far greater performance penalty and rendered the existance of an XSLT processor in Firefox totally moot - I never use it. I recommend finding someone with a more helpful attitude to manage the UNRESOLVED/WONTFIX BECAUSE OF ATTITUDE
The XSLT specification calls out this feature at: http://www.w3.org/TR/xslt#disable-output-escaping - Since when does requiring a lot of work override conforming to a spec? - Can you perhaps quantify slower? Since when is doing something wrong fast better than doing something right? - So you acknowledge that while "most" of the time d-o-e isn't needed, your use of "most" is an implicit acknowledgement that situations do exist where it is needed. Those situations are not the result of bad XSLT code, they are the result of having to process input files that you can't fix. In my case, about 5 years ago, the situation was processing RSS and Atom feeds that contained snippets of HTML. Those HTML snippets were not XML compliant, and nor were they required to be. I wanted to simply take the HTML in the snippets and embed them into my transformed document. The Atom/RSS feeds were not in my control, were fully compliant with their specs, and my use of XSLT's d-o-e feature was a perfectly rational way to deal with this situation. Because of the bad attitude by Firefox's developers, I was forced to push all XSLT transforms back to the server. This had a far greater performance penalty and rendered the existance of an XSLT processor in Firefox totally moot - I never use it. I recommend finding someone with a more helpful attitude to manage this. In the meantime, change the status of the issue to UNRESOLVED/WONTFIX BECAUSE OF ATTITUDE
(In reply to Grant Vergottini from comment #133) > The XSLT specification calls out this feature at: > > http://www.w3.org/TR/xslt#disable-output-escaping "An XSLT processor will only be able to disable output escaping if it controls how the result tree is output. This may not always be the case. For example, the result tree may be used as the source tree for another XSLT transformation instead of being output. An XSLT processor is not required to support disabling output escaping. If an xsl:value-of or xsl:text specifies that output escaping should be disabled and the XSLT processor does not support this, the XSLT processor may signal an error; if it does not signal an error, it must recover by not disabling output escaping." The XSLT processor in Firefox generates a DOM, not a sequence of characters here, so this is the case here. > - Since when does requiring a lot of work override conforming to a spec? Firefox *does* conform to the spec. > - Can you perhaps quantify slower? Since when is doing something wrong fast > better than doing something right? Firefox *does* things right- > - So you acknowledge that while "most" of the time d-o-e isn't needed, your > use of "most" is an implicit acknowledgement that situations do exist where Because I'm careful. > it is needed. Those situations are not the result of bad XSLT code, they are > the result of having to process input files that you can't fix. In my case, > about 5 years ago, the situation was processing RSS and Atom feeds that > contained snippets of HTML. Those HTML snippets were not XML compliant, and > nor were they required to be. I wanted to simply take the HTML in the > snippets and embed them into my transformed document. The Atom/RSS feeds a) You can handle those anyway; it's just a lot of work in XSLT. Essentially you need to write a custom HTML tokenizer. b) Allowing plain HTML from uncontrolled sources into your output document creates a Cross Site Scripting problem; are you aware of that? > were not in my control, were fully compliant with their specs, and my use of > XSLT's d-o-e feature was a perfectly rational way to deal with this > situation. Because of the bad attitude by Firefox's developers, I was forced > to push all XSLT transforms back to the server. This had a far greater > performance penalty and rendered the existance of an XSLT processor in > Firefox totally moot - I never use it. > > I recommend finding someone with a more helpful attitude to manage this. In > the meantime, change the status of the issue to UNRESOLVED/WONTFIX BECAUSE > OF ATTITUDE Please check the facts.
I am web-developer, and i am not using d-o-e feature at all because of firefox implementation. I know that even ie6 have support of d-o-e, but i cant write something that have no support in firefox. I personally don't think that this feature make rendering slower, because it's just html to dom convertation which browser CAN make fast. In fact in the pages that can make use d-o-e the +1 second of parsing is far better than not doing this at all. In most cases having perfect xml-valid html isn't needed. I think the xhtml is dead because of this now.
I am following this bug because once I thought I need d-o-e. Now I am much better in xslt and know exactly that neither me nor anyone wishing to write robust code needs it. D-o-e opens a whole can of worms security-wise, and anyone stating that "having xml-valid html isn't needed" should be reminded the insane amount of workarounds and code bloat existing as a result of this approach. So please stop whining about lack of doe support. What firefox would need is a parser capable to normalize the **** we normally see on the net (it have) and exposed to the xslt processor (which I am not aware of). I am normally using tagsoup for this purpose, but I am sure that the already existing parser in firefox would do equally well. As a side note, I neither use the xslt implementation of firefox for any serious purpose, because xslt 1.0 is not up to the task. However until you don't want to do heavy offloading of application logic to the browser, it is enough to render rest/xml to html.
(In reply to Julian Reschke from comment #134) > Firefox *does* conform to the spec. No, it doesn't. The section 17 and 16 clearly talk about input, transformation and output of trees. If the input is a valid tree and the output is a valid tree, then the XSLT transformer MUST do the transformation. The XSLT transformer is required to transform trees according to the spec. Let me cite the spec for you: "A conforming XSLT processor must be able to use a stylesheet to transform a source tree into a result tree as specified in this document." Otherwise, by your definition, the "transformer" that does nothing (just outputs the same XML tree) would be considered "valid". You can try arguing about producing output that is not valid XML, but if the expected output is valid, then you MUST do the transformation as for the spec. Which you don't do. > a) You can handle those anyway; it's just a lot of work in XSLT. Essentially > you need to write a custom HTML tokenizer. Should web developers write HTML tokenizers instead of the browser authors? Well, we can, but that shows total incompetence of the developers of the broken Transformix module. Maybe Google should just port their Chrome Frame to Firefox... > b) Allowing plain HTML from uncontrolled sources into your output document > creates a Cross Site Scripting problem; are you aware of that? Allowing plain HTML from uncontrolled sources into your browser creates lots of security problems. Should Firefox stop rendering HTML form all websites (except Google.com and Mozilla.org)? > Please check the facts. The most undeniable fact is that broken d-o-e implementation is a problem of Mozilla Firefox. This fact is acknowledged by Mozilla and I try to believe them. I like the no-nonsense way it's written here: https://developer.mozilla.org/en-US/docs/Common_XSLT_Errors "We do realize that the lack of disable-output-escaping is a problem and we'd like to find a solution for it" Much better that the farce that's going here.
(In reply to Alex Volkov from comment #137) > (In reply to Julian Reschke from comment #134) > > Firefox *does* conform to the spec. > No, it doesn't. Yes, it does. "An XSLT processor will only be able to disable output escaping if it controls how the result tree is output." This is the case here. The XSLT module generates a DOM. > The section 17 and 16 clearly talk about input, transformation and output of > trees. > If the input is a valid tree and the output is a valid tree, then the XSLT > transformer MUST do the transformation. No. > The XSLT transformer is required to transform trees according to the spec. > Let me cite the spec for you: "A conforming XSLT processor must be able to > use a stylesheet to transform a source tree into a result tree as specified > in this document." And that's what it does. > Otherwise, by your definition, the "transformer" that does nothing (just > outputs the same XML tree) would be considered "valid". > > You can try arguing about producing output that is not valid XML, but if the > expected output is valid, then you MUST do the transformation as for the > spec. Which you don't do. This has nothing to do at all with "validity". > > a) You can handle those anyway; it's just a lot of work in XSLT. Essentially > > you need to write a custom HTML tokenizer. > Should web developers write HTML tokenizers instead of the browser authors? That's a separate question. Would it be good if in-browser-XSLT engines exposed HTML parsers for this use case? Probably yes. > Well, we can, but that shows total incompetence of the developers of the > broken Transformix module. Maybe Google should just port their Chrome Frame > to Firefox... > > > b) Allowing plain HTML from uncontrolled sources into your output document > > creates a Cross Site Scripting problem; are you aware of that? > Allowing plain HTML from uncontrolled sources into your browser creates lots > of security problems. Should Firefox stop rendering HTML form all websites > (except Google.com and Mozilla.org)? Please read about what a cross-site-scripting attack is and then come back. > > Please check the facts. > The most undeniable fact is that broken d-o-e implementation is a problem of > Mozilla Firefox. This fact is acknowledged by Mozilla and I try to believe > them. > I like the no-nonsense way it's written here: > https://developer.mozilla.org/en-US/docs/Common_XSLT_Errors > > "We do realize that the lack of disable-output-escaping is a problem and > we'd like to find a solution for it" > > Much better that the farce that's going here. There's no "farce" going on here. d-o-e is totally optional, and claiming it is not won't change anything. If you really believe that FF needs to support this: the source code is public; go ahead and proposed a patch.
Julian: Why are you talking about XSS attacks? 1) If external html what i'm getting from another website would be xml-valid, is it safe from XSS? No 2) If I'm getting non-valid xml-data from my own website via AJAX (which is edited in WISIWIG editor), and i simply want to do transformation on the client, is it safe from XSS? Yes (if i trust my editors, or myself).
As one of the module peers for the XSLT module in Firefox, here's my input: Julian is correct that the XSLT implementation in Firefox is technically conforming in this regard. The XSLT specification uses very confusing terminology. The term "output" doesn't means what you'd intuitively think. In the XSLT spec it means[1] "converting the result tree to a stream of bytes", i.e. serializing the result tree. That said, it's not really very relevant whether we're technically conforming to the spec or not. What matters is that this is causing problems for authors. A web browser would be perfectly conforming to HTML4 and HTML5 even if it didn't support javascript or CSS. However such a web browser wouldn't be able to display the modern web which is what users and developers care about. What matters is that this is something that people would like to work, and it works in other browsers. However, it is also the case that XSLT is used very little on the web today. As a result, it's simply not a high priority to fix this bug. As firefox developers, we have almost an infinite amount of things that we could work on, and so we have to choose to work on what helps the most people. As much of a fan of XSLT as I am (I've spent years working on the firefox XSLT engine), it's simply a reality that we help more developers by working on other features. We have actually discussed if we should remove support for XSLT given that we can't support it to the level we would like to. I.e. because we don't have time to fix bugs such as this one. However so far the decision has been that we'd rather keep the limited support that we have. So there's no need to ask why this isn't fixed. It's simply due to a lack of time. Complaining about it won't magically cause us to have more time. Patches are accepted though. [1] http://www.w3.org/TR/xslt#output
Whiteboard: [standalone] → See comment 140
Would switching to an external library like libxslt be a viable option, or would it be even more work than enabling this feature on Transformiix? I don't know about you, but I want XSLT support in Firefox better, not gone.
Jonas - I understand your time/priority argument, it's valid. Julian's argument that it SHOULDN'T be implemented due to his interpretation of the spec, however, is not, and it's petulant as well. That said, here's my understanding of the base of this issue. Please correct me where I'm wrong in the following items: 1. There is a text-to-DOM parser available in Firefox for HTML, used in innerHTML and other places. 2. Transformiix outputs a result DOM rather than result text. 3. d-o-e text nodes are output as DOM text nodes, and the Transformiix processor creates those nodes from the XSLT result tree. 4. The code for the public transformation methods is controlled by Firefox and can be modified to make an additional pass on the result tree, modifying it if needed. If all those are more-or-less true, then what's preventing us from marking d-o-e text nodes and then replacing them in-place with the result of passing them through Firefox's text-to-DOM parser?
There are several possible solutions here. All require dramatic changes to how the XSLT engine interacts with the rest of firefox as it would no longer be done by the XSLT engine modifying the displayed page using the DOM. Hence none of them are very easy to implement. Simply outputting textnodes and then replacing them won't work since the following wouldn't work: <xsl:text d-o-e><!--</xsl:text><p>hello there</p><xsl:text d-o-e>--></xsl:text> This shouldn't output an element, it should just output a comment. Additionally, outputting normal textnodes at first and then replacing them, it would mean that rendering would be wrong first and then get fixed up.
Jonas, in fact <xsl:text d-o-e><!--</xsl:text><p>hello there</p><xsl:text d-o-e>--></xsl:text> should result in an empty text node, as <!--comments--> in xsl stylesheets are excluded from processing. There's an <xsl:comment> instruction to provide <!--comments--> in result tree. Also, >outputting normal textnodes at first and then replacing them does not yet mean any rendering. When we call tranformToFragment, the resulting fragment is not yet a part of the document tree (because as soon as fragment is inserted in the tree it ceases to exist), thus it is not a subject to rendering. Transforming is purely in-memory operation. If I got Scott's proposition right, all you are to do is run current implementation tranformToFragment hacked so d-o-e parts are somehow marked, then you loop through them applying text-to-DOM parser to marked areas and substituting text nodes with corresponding document fragments, and return the result from the new tranformToFragment. Correct me if I miss something out.
Sorry, I meant <xsl:text d-o-e>&lt;!--</xsl:text><p>hello there</p><xsl:text d-o-e>--></xsl:text>
And transforms done through .transformToFragment are indeed purely an in-memory operation. However transforms done due to an <?xml-stylesheet?> PI in a document which the user navigates to is displayed while the transformation is running.
ivegner - that's precisely correct. And <xsl:text> does not allow any <xsl:*> elements as content, so comments wouldn't go into those text nodes anyway. I think this approach would work to fix the legitimate usages of d-o-e in browser XSLT, while preserving the structural benefit to the Transformiix process. There would still be some cases where output wouldn't match - say, if they tried to wrap content in an element by using d-o-e to literally output the opening tag and closing tag. That is pretty clearly bad XSLT, so I wouldn't care if that part didn't work. Jonas - yes, I thought about the processing-instruction case as well. Is Transformiix actually running transformToFragment in that case, though? Since a xml-stylesheet transformation is only done at source load time, everything's coming out as text anyway, so I can't imagine that it's an apples-to-apples comparison. I don't know what the serialization process is for these two different use cases.
>There would still be some cases where output wouldn't match - say, if they tried to wrap content in an element by using d-o-e to literally output the opening tag and closing tag. That is pretty clearly bad XSLT, so I wouldn't care if that part didn't work. The example with &lt;-- being wrapped in <xsl:text> node also fits the case. Meddling with tree structure is not what d-o-e is meant for. In my opinion the XSLT 1.0 spec seems to lack the restriction that <xsl:text d-o-e> content which is not parseable as a document fragment should (or may? or must?) be processed as if without d-o-e attribute. Scott, I believe Jonas's point was that Firefox doesn't actually build _text_ representation of a page loaded with <?xml-stylesheet?> processing instruction. Once the input xml file and its corresponding stylesheet (or a number of them) are loaded and parsed into documents, the browser may now forget about any text files and process documents as trees. And that's what it does, in fact. And the line: >However transforms done due to an <?xml-stylesheet?> PI in a document which the user navigates to is displayed while the transformation is running. figures that the process there is not identical to that of transformToFragment. XSLT is designed in the way that a processor is able to "spit out" signficant parts of the resulting tree while the transformation is not yet done. For example, if the matching template is like: <xsl:template match="/whatever"> <root> <some-awesomeness> <xsl:for-each select="*"> [<xsl:value-of select="name()"/>] </xsl:for-each> <some-awesomeness/> </root> </xsl:template> then a processor is able to first yield a document fragment <root> <some-awesomeness/> </root> and then proceed to xsl:for-each part, generating a series of instruction to append, first, a '[' text node, then tag name text node, then at last, a ']' text node to some-awesomeness node. Apparently, Firefox makes use of this mechanics to display a part of resulting tree which is not yet fully processed. That's why it is linked against rendering, and why the idea to "first insert as-is, then run standard HTML parser" meets a display problem. The above being my mere assumptions (as I have not yet had a look at the source code and I am unlikely to do so because of lots of JavaScript to work on), it seems I now see the problem. Even if you insert a call to text-to-DOM parser at each instance of d-o-e, you will cover most of the functionality requested by sane developers (i.e. those who do not write things like <xsl:text d-o-e><td></xsl:text>foobar<xsl:text d-o-e></td></xsl:text>), but then it would not be specification-compliant, as it requires to either do processing or don't. And again, it is the problem with XSLT 1.0 spec that it allows an unfair use of d-o-e when outputting to text rather than to a document fragment. Attempting to update the spec by introducing a notion of fair and unfair use of d-o-e seems to be out of question, that's why we have to bear with what is given. I'm sorry, Scott, to bring it to this conclusion, but the problem is deeper than it seemed at first. By the way, the task I faced that brought me to bumping this thread have received a solution that indeed did not require FF to support d-o-e and still insert an html from outer sources into resulting tree with having it rendered as if d-o-e was there. The key point was to pre-parse the html into a fragment of input document and use <xsl:copy-of> instead of <xsl:value-of d-o-e>. The statements that you don't really need the d-o-e feature start to make some sense to me now.
Oopsie, I did something wrong with my quotation blocks. I wonder if it is reparable.
"Meddling with tree structure is not what d-o-e is meant for." What are you using as basis for this statement? There's clearly other people in this bug that disagree with you.
ivegner: The copy-of and DOE are different. The copy-of assume that you have a valid xml tree. The doe - assume that you have a non valid-xml html data which you have to insert in you document as is. for example you outputting the table, and use: <xsl:if test="position() mod 2=0"> <xsl:text d-o-e>&lt;tr&gt;</xsl:text> </xsl:if> Or you have to insert date which is edited via wysiwyg editor (like ckeditor) which cant guarantee you the valid xml. Jonas: You point right that the xslt feature is now much popular by web-developers, by browsers and poorly used by search engines. As web-developer i have to use server-side xsl transformation. But i will be happy if i could sometimes use firefox-side transformation, even if it would be slow and buggy in firefox. I suppose that this feature don't require speed, the question is it working or not. P.S. And i suppose that importance of bug should be sometimes determined by votes for bug in bugzilla.
(In reply to mr.troll from comment #139) > Julian: Why are you talking about XSS attacks? > 1) If external html what i'm getting from another website would be > xml-valid, is it safe from XSS? No Indeed. But if it's wellformed, unescaped XHTML, such as possible in the Atom Feed format, you can use XSLT to filter the subset of HTML tags/attributes you want to support. If you take raw HTML and just copy it over using d-o-e, you have zero control over the content. > 2) If I'm getting non-valid xml-data from my own website via AJAX (which is > edited in WISIWIG editor), and i simply want to do transformation on the > client, is it safe from XSS? Yes (if i trust my editors, or myself).
I want to set the doctype to use HTML5 output. How may I solve this? http://stackoverflow.com/questions/6334381/how-to-output-doctype-html-with-xslt
Marcelo, I don't think setting the doctype in this case is actually useful (does it make a difference?), but if you think you need it then http://stackoverflow.com/questions/3387127/set-html5-doctype-with-xslt/10468906#10468906 should answer the question.
Yes, it makes difference. Apparently your recommendation works. Thanks.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: