14101 2007-06-12 12:42:47 -0700 XSLTProcessor does not accept Nodes as parameter values 2022-07-28 13:49:43 -0700 1 1 1 Unclassified WebKit XML 523.x (Safari 3) All All NEW https://bugs.webkit.org/show_bug.cgi?id=28744 InRadar P2 Normal --- 1 sjoerd webkit-unassigned ahmad.saleem792 ap asaf.mesika bedney bfulgham cafulnecky desamo julian.reschke mail marcus michael.slama mrizzo99 rbrandt rniwa robert rwlbuis tobyschachman ydshang oldest_to_newest 7762 0 sjoerd 2007-06-12 12:42:47 -0700 F.e. assuming doc is the XML document <test/>: proc.setParameter(null, "test", doc) With XSLT: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:param name="test"/> <xsl:template match="/"> <result> <xsl:copy-of select="$test" /> </result> </xsl:tempate> </xsl:stylesheet> gives: <result>[object Document]</result> where I expected: <result><test/></result> 7655 1 ap 2007-06-13 13:18:28 -0700 Confirmed, it's an nsIVariant in Gecko, but a String in WebKit. 5909 2 ap 2007-06-29 09:02:02 -0700 What types does Firefox accept in setParameter()? If I understand the spec correctly, XSLT parameters are just expressions, so the type can be one of boolean, number, string, or node-set. Is there a way to pass an arbitrary node-set, rather than a single Node? Also, can XPathEvaluator result values be used in XSLTProcessor? 72981 3 19582 mail 2008-03-07 03:56:30 -0800 Created attachment 19582 Should render Hello World! when this bug is fixed. I would very much appreciate if this bug is being fixed. I have attached a test file that will render "Hello World!" when this bug is fixed. Opera and Firefox already succeed, but Safari returns "Hello[object Element]". 72997 4 mail 2008-03-07 09:22:00 -0800 Bug filed in libxslt for this: http://bugzilla.gnome.org/show_bug.cgi?id=521030 75040 5 tobyschachman 2008-03-24 19:24:24 -0700 (In reply to comment #2) > What types does Firefox accept in setParameter()? > > If I understand the spec correctly, XSLT parameters are just expressions, so > the type can be one of boolean, number, string, or node-set. Is there a way to > pass an arbitrary node-set, rather than a single Node? Also, can XPathEvaluator > result values be used in XSLTProcessor? > In Firefox, one can pass a node-set by setting the parameter to an array of nodes. There may be other ways, I found this out by trial and error. One more vote here to resolve this bug (at least for single nodes). It's keeping me from porting my app to Webkit. 75043 6 hyatt 2008-03-24 19:33:18 -0700 Not sure what we can really do here if it's a bug in libxslt. 75600 7 ap 2008-03-28 02:09:46 -0700 From the WebKit side, the main issue AFAICT is that it's hard to properly pass a node reference from DOM to libxml2, given that we re-create the document each time for XSLT processing. 75633 8 sjoerd 2008-03-28 06:20:10 -0700 That is a really limiting way to implement XSLT. If you'd want to implement user defined extension functions, which you can do with MSXML, you would have to be able to get the original node back for nodes that are passed to such functions. 88811 9 ap 2008-08-19 04:58:19 -0700 *** Bug 20444 has been marked as a duplicate of this bug. *** 88897 10 ydshang 2008-08-19 23:26:13 -0700 (In reply to comment #9) > *** Bug 20444 has been marked as a duplicate of this bug. *** Could you tell me that when the bug could be fixed? Thanks! more detail: The following code: alert(typeof(proc.getParameter(null,"test"))); will display "string". It sounds as if Safari converts the DOM document node to a string([object Document]) and passes that string into xsl. 130202 11 cafulnecky 2009-07-07 07:01:59 -0700 The ability to pass a node-set as a parameter is a critical component for high-performance push/comet style applications that use XML as an in memory database. XSLT provides a performant means of merging an incoming document with an existing client-side model. Javascripted DOM operations are relatively costly for large documents (in excess of 2 megabytes). Without the ability to pass a node-set we are limited to using URLs which prevents pre-processing and error handling by standard AJAX XMLHttp libraries. See http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge 192650 12 desamo 2010-02-22 14:54:11 -0800 <rdar://problem/7672261> 204521 13 cafulnecky 2010-03-26 05:42:12 -0700 The passing of nodes as parameter values is fully supported in the latest versions of: Internet Explorer Firefox Opera 286288 14 rbrandt 2010-09-28 09:08:52 -0700 Still seeing this over three years later. As a platform for web-applications this is a pretty big limitation of the web-kit browsers. 538777 15 michael.slama 2012-01-19 09:56:52 -0800 (In reply to comment #13) > The passing of nodes as parameter values is fully supported in the latest versions of: > Internet Explorer > Firefox > Opera We (HP ESSN) are being asked to add support for Chrome in upcoming enterprise Web application releases due to Chrome's rise in adoption, and this limitation is preventing that for some of our teams. We have been successfully using IE and Firefox to pass node-sets as parameters since late 2005 when the good folks at Mozilla (esp. Peter Van Der Beken) fixed their XSLT library to support node-set parameters in version 1.50. See https://bugzilla.mozilla.org/show_bug.cgi?id=248025 (comment #15 is referring to me because I was building Mozilla to test the fix). Is there a way to move this issue to a higher priority, or perhaps request outside help to get it addressed? This is a critical requirement for our XSLT-heavy Web applications because we need to pass entire documents to the XSLT processor as parameters. We have a large customer base and the addition of Chrome support within our organization would boost adoption even further IMO. 1031650 16 bedney 2014-08-27 06:57:25 -0700 7 years... wow. Unfortunately, it looks like this will never get fixed. And with the Blink fork, that makes it even more unlikely that it will be fixed for both codebases, etc. I have a relatively painless workaround for this bug if anyone is interested: Use JavaScript to grab the 'xsl:param' elements in your XSLT document, replace them with 'xsl:variable' elements with your 'node' content for that parameter as child content and then use that modified XSLT document in the processor. If folks are still interested enough to want a code snippet, I can paste that here. Cheers, - Bill 1498273 17 mrizzo99 2019-01-25 09:20:16 -0800 Bill I know it is a long shot at this point (given it is almost 5 years later from the last comment) but I would be interested in the javascript snippet you put together. I'm working on an old legacy product and am actively looking for a workaround to this issue to expand browser support. Thanks Mike. 1498356 18 bedney 2019-01-25 11:39:09 -0800 Mike - The codebase I was working from 5 years ago has changed, but I found a chunk of code in a temp file that looked to be more-or-less working code (but probably should just be treated as pseudo-code - I'm sure you'll have to debug a bit): Assume you have an Array of Objects that contain the parameters you want to feed to the sheet: params = [ {name: 'foo', value: <Node>}, {name: 'bar', value: <Node>), ... ]; Assume that 'xsltDoc' is the *XSLT* document that you're using to process the source document and 'inputDoc' is the source XML that you're transforming. for (i = 0; i < params.length; i++) { // Search the style doc to see if there's an 'xsl:param' element with a name matching params[i].name paramElem = xsltDoc.evaluate('//param[@name="' + params[i].name '"]', null, XPathResult.ANY_TYPE, null); if (paramElem) { // Create an 'xsl:variable' element and set it's name to be the same as the 'xsl:param' newElem = xsltDoc.createElementNS('http://www.w3.org/1999/XSL/Transform', 'variable'); newElem.setAttribute('name', params[i].name); // Swap in the 'xsl:variable' element for the 'xsl:param' element paramElem.parentNode.replaceChild(newElem, paramElem); // Append the parameter node under the 'xsl:variable' element newElem.appendChild(params[i].value); } } That's about it. Go ahead and import the sheet: processor = new XSLTProcessor(); processor.importStylesheet(xsltDoc); And then run it through the processor: resultDoc = processor.transformToDocument(inputDoc); Note that this approach has the distinct disadvantage of modifying your *XSLT* document. If you need to do multiple transformations, you'll want to clone the XSLT document and keep a pristine copying before modifying it like this. I would caution again that the code above is close, but probably has bugs. Sorry I don't have the original running source to give you. If you run into issues, feel free to email me directly. My email address is: bedney@technicalpursuit.com Hope this helps! Cheers, - Bill 1498369 19 mrizzo99 2019-01-25 11:51:33 -0800 Cheers! This is a huge help and I will treat as psuedo-code. I will only bother you if I run into issues I can not work around. 1498376 20 bedney 2019-01-25 12:02:31 -0800 Mike - In looking back over this code, I realized that the call to xsltDoc.evaluate() is going to give you back an 'XPathResult' object - not the element itself. More docs can be found here: https://developer.mozilla.org/en-US/docs/Web/API/XPathResult It was all so long ago... ;-) And the API around 'document.evaluate' is pretty weird. I think what you'll want is the '.singleNodeValue' of the result. Sorry in advance to everyone on this bug for the not-quite-interactive debugging session ;-). Cheers, - Bill 1887405 21 ahmad.saleem792 2022-07-28 12:16:53 -0700 I am still able to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case and it just shows 'Hello[object Element]' and it is same with Chrome Canary 106. Only Firefox Nightly 105 show "Hello World" in this test case. Just wanted to share updated test results. Thanks! 19582 2008-03-07 03:56:30 -0800 2008-03-07 03:56:30 -0800 Should render Hello World! when this bug is fixed. SetParameterTest.html text/html 1167 mail PHRpdGxlPlNldFBhcmFtZXRlclRlc3Q8L3RpdGxlPgo8c2NyaXB0IHR5cGU9J3RleHQvamF2YXNj cmlwdCc+CmZ1bmN0aW9uIHRlc3QoKSB7CiAgdmFyIHBhcnNlciAgICAgPSBuZXcgRE9NUGFyc2Vy CiAgdmFyIHNlcmlhbGl6ZXIgPSBuZXcgWE1MU2VyaWFsaXplcgoKICB2YXIgeHNsID0gcGFyc2Vy LnBhcnNlRnJvbVN0cmluZyhbCiAgICAnPHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIgeG1s bnM6eHNsPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm0iPicsCiAgICAgICc8 eHNsOnBhcmFtIG5hbWU9InBhcmFtIi8+JywKICAgICAgJzx4c2w6dGVtcGxhdGUgbWF0Y2g9Ii8i PicsCiAgICAgICAgJzxzcGFuPjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSIkcGFyYW0iLz48L3NwYW4+ JywKICAgICAgJzwveHNsOnRlbXBsYXRlPicsCiAgICAnPC94c2w6c3R5bGVzaGVldD4nCiAgXS5q b2luKCcnKSwgJ2FwcGxpY2F0aW9uL3htbCcpCiAgCiAgdmFyIHhtbCAgPSBwYXJzZXIucGFyc2VG cm9tU3RyaW5nKCc8bXNnPiBXb3JsZCE8L21zZz4nLCAnYXBwbGljYXRpb24veG1sJykKICB2YXIg b3V0ICA9IG51bGwKICAKICB2YXIgcHJvY2Vzc29yICA9IG5ldyBYU0xUUHJvY2Vzc29yCiAgcHJv Y2Vzc29yLmltcG9ydFN0eWxlc2hlZXQoeHNsKQogIHByb2Nlc3Nvci5zZXRQYXJhbWV0ZXIobnVs bCwgJ3BhcmFtJywgJ0hlbGxvJykKICBvdXQgPSBwcm9jZXNzb3IudHJhbnNmb3JtVG9Eb2N1bWVu dCh4bWwpCiAgZG9jdW1lbnQuYm9keS5pbm5lckhUTUwgKz0gc2VyaWFsaXplci5zZXJpYWxpemVU b1N0cmluZyhvdXQpCiAgCiAgcHJvY2Vzc29yID0gbmV3IFhTTFRQcm9jZXNzb3IKICBwcm9jZXNz b3IuaW1wb3J0U3R5bGVzaGVldCh4c2wpCiAgcHJvY2Vzc29yLnNldFBhcmFtZXRlcihudWxsLCAn cGFyYW0nLCB4bWwuZG9jdW1lbnRFbGVtZW50KQogIG91dCA9IHByb2Nlc3Nvci50cmFuc2Zvcm1U b0RvY3VtZW50KHhtbCkKICBkb2N1bWVudC5ib2R5LmlubmVySFRNTCArPSBzZXJpYWxpemVyLnNl cmlhbGl6ZVRvU3RyaW5nKG91dCkKfQoKd2luZG93Lm9ubG9hZCA9IHRlc3QKPC9zY3JpcHQ+Cjxo MT5TZXRQYXJhbWV0ZXJUZXN0PC9oMT4KPHA+VGhpcyBzY3JpcHQgc2hvdWxkIG91dHB1dCA8c2Ft cD5IZWxsbyBXb3JsZCE8L3NhbXA+CjxwcmU+