Menu
I have an XML document here that is served with a corresponding XSL file. The transformation is left to be executed client-side, without JavaScript.
This works fine in IE (shock horror), but in Google Chrome, just displays the document's text nodes.
I know that it is possible to do client-side XSL in Chrome, as I have seen examples of it, but I am yet to be able to replicate this success myself
What am I doing wrong?
509
Add the XSLT style sheet using the Properties window. With the XML file open in the editor, right-click anywhere in the editor and choose Properties. In the Properties window, click in the Stylesheet field and choose the browse button (...). Select the XSLT style sheet, and then choose Open.
The reason this doesn't work is due to a security concern that Chrome has addressed in a controversial way, by blocking XML files from accessing local XSLT files in the same directory, while HTML files can access . CSS files in the same directory just fine.
Web browsers: Safari, Chrome, Firefox, Opera and Internet Explorer all support XSLT 1.0 (only). Browsers can perform on-the-fly transformations of XML files and display the transformation output in the browser window.
Just drag and drop any XML file and you can see the collapsible tree view of the file. It also supports viewing RSS feeds. Show activity on this post.
The other answer below by Eric is wrong. The namespace declaration he mentioned had nothing to do with the problem.
The real reason it doesn't work is due to security concerns (cf. issue 4197, issue 111905).
Imagine this scenario:
You receive an email message from an attacker containing a web page as an attachment, which you download.
You open the now-local web page in your browser.
The local web page creates an <iframe> whose source is https://mail.google.com/mail/.
Because you are logged in to Gmail, the frame loads the messages in your inbox.
The local web page reads the contents of the frame by using JavaScript to access frames[0].document.documentElement.innerHTML. (An online web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)
The local web page places the contents of your inbox into a <textarea> and submits the data via a form POST to the attacker's web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.
Chrome foils the above scenario by putting restrictions on local files opened using Chrome. To overcome these restrictions, we've got two solutions:
Try running Chrome with the --allow-file-access-from-files flag. I've not tested this myself, but if it works, your system will now also be vulnerable to scenarios of the kind mentioned above.
Upload it to a host, and problem solved.
86
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
