[Webkit-unassigned] [Bug 24418] New: transformToFragment() method from XSLTProcessor objects returning null when processing XML data read from on-disk files

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24418

           Summary: transformToFragment() method from XSLTProcessor objects
                    returning null when processing XML data read from on-
                    disk files
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: XML
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jmpp at macports.org


I'm using r41443 of the Webkit nightly builds, the current one as of
2009-03-05, on top of the Safari 4 beta and I'm experiencing a problem with the
transformToFragment() method of the XSLTProcessor() objects, which is always
returning null when processing the sample XML and XSL files that can be reached
at the following URLs:

-) http://jmpp.org/ttf_testcase/ a small index.html file with a clickable link
to see the bug in action;
-) http://jmpp.org/ttf_testcase/data.xml the sample XML file;
-) http://jmpp.org/ttf_testcase/stylesheet.xsl the XSLT stylesheet;
-) http://jmpp.org/ttf_testcase/fragment_broken.js the JS code that attempts to
process the previous two files.

A couple of things I'd like to note explicitly:

-) this particular combination of XML, XSLT and JS works perfectly on Firefox
3;
-) a slight variation of this test case mysteriously makes the problem go away,
in which the XML to be processed is turned into a string (rather than an
on-disk file) that's output by a server-side script, such as
http://dykasa.com/imAppInterfaces/IArticulos.php?act=articulos_marca&marId=1&page=0

In this modified testcase, the xmlDoc JS variable that holds the XML to be
processed is filled a little differently, as demonstrated in the script inlined
below:

/* fragment_working.js */
var myXMLHTTPRequest = new XMLHttpRequest();
var xsltProcessor = new XSLTProcessor();
var xmlDoc;
var fragment;

// load the xslt file
myXMLHTTPRequest.open('GET',
'http://dykasa.com/imClientFormats/articulos_marca.xsl', false);
myXMLHTTPRequest.send(null);
xsltProcessor.importStylesheet(myXMLHTTPRequest.responseXML);

// load the xml file
myXMLHTTPRequest.open('GET',
'http://dykasa.com/imAppInterfaces/IArticulos.php?act=articulos_destacados&page=0',
false);
myXMLHTTPRequest.send(null);
// different xmlDoc var here!
xmlDoc = (new DOMParser()).parseFromString(myXMLHTTPRequest.responseText,
'text/xml');
fragment = xsltProcessor.transformToFragment(xmlDoc, document);
console.log(fragment);

In this case, transformToFragment() returns a valid object off of the
custom-filled xmlDoc variable. This narrowing-down process leads me to believe
the problem is in the responseXML property of the XHR object the second time it
is used in the 'fragment_broken.js' file, i.e. when the XML file is loaded.
Unfortunately, I hit a dead end with this theory because dumping
myXMLHTTPRequest.responseXML to the console just after loading the XML file
('data.xml') in 'fragment_broken.js' shows me a perfectly valid XML structure.
Also, the 'data.xml' file used in 'fragment_broken.js' and the XML string
produced by the URL used in 'fragment_working.js' have the exact same
structure, so that makes it difficult to point to the XML file as the possible
culprit (e.g. being malformed). Similarly, the 'stylesheet.xsl' file used in
'fragment_broken.js' has the exact same structure as that used in
'fragment_working.js', so it is equally difficult to point to a possibly
malformed 'stylesheet.xsl' file as the culprit of the problem.

So, summarizing:

-) http://jmpp.org/ttf_testcase/data.xml and
http://dykasa.com/imAppInterfaces/IArticulos.php?act=articulos_destacados&page=0
have the exact same structure, but the former is an on-disk file and the latter
is a string output by a server-side script (this seems to be the only sensible
difference so far);
-) http://jmpp.org/ttf_testcase/stylesheet.xsl and
http://dykasa.com/imClientFormats/articulos_marca.xsl have the exact same
structure and both are on-disk files;
-) in 'fragment_broken.js', the xmlDoc JS variable is simply the 'responseXML'
property of the XHR object that loads the on-disk XML file;
-) in 'fragment_working.js', the xmlDoc JS variable is the XML resulting of a
DOM parse:

xmlDoc = (new DOMParser()).parseFromString(myXMLHTTPRequest.responseText,
'text/xml')

Lastly, a search through bugzilla led me to a similar issue, #10419, but that
has not only already been fixed, but also the suggestions made there don't seem
to help this time round:

-) removing or leaving in the <?xml version="1.0" encoding="UTF-8"?>
declaration at the top of my stylesheet.xsl file makes no difference, problem
demonstrated in fragment_broken.js persists;
-) switching the xsl:output to <xsl:output method="xml"
omit-xml-declaration="yes"/> makes no difference either, problem demonstrated
in fragment_broken.js persists.

Please don't hesitate to ping me here or on IRC, under the nick jmpp, if any of
this is not clear, I'd be happy to elaborate and/or clarify.


-jmpp


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.