How can I make XSLT work in chrome?

Question

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?

Herbarium

It would be great to post the solution, when you know it. I haven't really used Chrome for anything serious -- seems like a google-toy to me. Why do you need to perform XSLT client-side? – Rabblement

I don't. I just thought it would be kinda neat. And I'd still like to know why some things work on Chrome, but mine doesn't. Oh, and for IE users, sorry for the atrocious rainbow styling of the page. – Herbarium

For me Chrome can do the transformation only when opening the XML over http://, it does not work when working via file://, the xmlns-attribute does not make any difference for me. – Dint

This bug is mentioned here – Occultation

The actual chrome bug for this is at code.google.com/p/chromium/issues/detail?id=111905 – Baggywrinkle

Another useful trick is to run a local webserver to host your files; Python gives you a painless option here: #12905926 – Aphrodisiac

Google discussion "Intent to Deprecate and Remove: XSLT": groups.google.com/a/chromium.org/forum/#!topic/blink-dev/… – Sestet

Polyfill candidate: developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor – Sestet

Answer 1

At the time of writing, there was a bug in chrome which required an xmlns attribute in order to trigger rendering:

<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >

This was the problem I was running into when serving the xml file from a server.

---

If unlike me, you are viewing the xml file from a file:/// url, then the solutions mentioning --allow-file-access-from-files are the ones you want

Herbarium

Good find! Filled a bug for this. – Ingham

@Peter: it depends on your input document. The XSLT spec is pretty clear here and IE is just too forgiving. If the input is valid XHTML, it has a namespace declaration. To have XSLT locate anything in that input document, you must define the namespace. It's, however, not necessary to use the default namespace (but easiest). – Pili

@Eric: take a look at my answer, no offense, but your answer is wrong. – Zebulen

This is not the answer (nor the solution, and the "..." is definitely a bit vague), Pacerier's is the correct one. – Ashcan

This is incorrect. not required that deceleration. It asking for version numbers. – Lamee

Answer 2

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:

1. You receive an email message from an attacker containing a web page as an attachment, which you download.

2. You open the now-local web page in your browser.

3. The local web page creates an <iframe> whose source is https://mail.google.com/mail/.

4. Because you are logged in to Gmail, the frame loads the messages in your inbox.

5. 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.)

6. 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:

1. 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.

2. Upload it to a host, and problem solved.

Zebulen

This is true, however that was not the only cause of the problem. I've been following the "bug" report for a while now. However, I couldn't get it to work server-side either without the xmlns attribute. This might have changed in newer versions of chrome. – Herbarium

@Herbarium ok this may not be an answer to your problem, but it is the correct answer to your question. judging by the comments of the visitors to this page, we can see that the answer that had been marked answer is not solving their problems. (otherwise why would they have to wade through the other 6 answers to find a solution) – Zebulen

@Pacerier: It's not the correct answer to my question. My question was asking about why a pair of documents hosted on my server were not being transformed correctly. The security problem, while worth knowing, is not relevant to this particular question. – Herbarium

@Zebulen Thanks, --allow-file-access-from-files works fine. – Wideman

how to set this in macOS? – Armoured

Chrome restrictions on file:// are plain stupid and devs are just too lazy to implement the same-origin policy the right way (as Firefox does) And that's a shame because Chrome is my everyday's browser. – Tutelary

Maybe it's time to rethink about this? I don't think that scenario is possible anymore. Loading gmail in a frame fails with Refused to display in a frame because it set 'X-Frame-Options' to 'sameorigin'. error. That's even answered in SO: https://mcmap.net/q/219329/-how-can-i-lt-iframe-gt-gmail. So, since one can refuse one's content to load in a frame whether the page is local or not maybe it's time for Chrome to do XSLT some justice? – Scaremonger

use python to start a local http server with python3 -m http.server 8000. This serves files relative to the current directory. local python server documentation – Casa

@Casa Fairly difficult to tell an end-user, in a locked down corporate environment, with no privileges to install python, or open a listening socket, to do any of that. It's much easier to tell them to right-click the file and say "Open in Internet Explorer". – Digressive

Answer 3

I had the same problem on localhost. Running around the Internet looking for the answer and I approve that adding --allow-file-access-from-files works. I work on Mac, so for me I had to go through terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files and enter your password (if you have one).

Another small thing - nothing will work unless you add to your .xml file the reference to your .xsl file as follows <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Another small thing I didn't realise immediately - you should be opening your .xml file in browser, no the .xsl.

Softfinned

Answer 4

The problem based on Chrome is not about the xml namespace which is xmlns="http://www.w3.org/1999/xhtml". Without the namesspace attribute, it won't work with IE either.

Because of the security restriction, you have to add the --allow-file-access-from-files flag when you start the chrome. I think linux/*nix users can do that easily via the terminal but for windows users, you have to open the properties of the Chrome shortcut and add it in the target destination as below;

Right-Click -> Properties -> Target

Here is a sample full path with the flags which I use on my machine;

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files

I hope showing this step-by-step will help windows users for the problem, this is why I've added this post.

Counterpressure

You should really avoid using this trick to run Chrome. This exposes it to critical attacks with external scripts from rogue websites having access to files on your local system, because this wide-opens the sandbox. Thus bug is still in chrome, for not recognizing the "application/xml" mediatype and allowing it to be rendered locally, but still using only an external XML stylesheet (from the same origin server as the XML file, or a default builtin stylesheet provided by the webbrowser itself) and not random local files on your system. – Sismondi

@Sismondi Ideally Chrome would have fixed their security bugs, rather than breaking users. – Digressive

Answer 5

Well it does not work if the XML file (starting by the standard PI:

<?xml-stylesheet type="text/xsl" href="..."?>

for referencing the XSL stylesheet) is served as "application/xml". In that case, Chrome will still download the referenced XSL stylesheet, but nothing will be rendered, as it will silently change the document types from "application/xml" into "Document" (!??) and "text/xsl" into "Stylesheet" (!??), and then will attempt to render the XML document as if it was an HTML(5) document, without running first its XSLT processor. And Nothing at all will be displayed in the screen (whose content will continue to show the previous page from which the XML page was referenced, and will continue spinning the icon, as if the document was never completely loaded.

You can perfectly use the Chrome console, that shows that all resources are loaded, but they are incorrectly interpreted.

So yes, Chrome currently only render XML files (with its optional leading XSL stylesheet declaration), only if it is served as "text/xml", but not as "application/xml" as it should for client-side rendered XML with an XSL declaration.

For XML files served as "text/xml" or "application/xml" and that do not contain an XSL stylesheet declaration, Chrome should still use a default stylesheet to render it as a DOM tree, or at least as its text source. But it does not, and here again it attempts to render it as if it was HTML, and bugs immediately on many scripts (including a default internal one) that attempt to access to "document.body" for handling onLoad events and inject some javascript handler in it.

An example of site that does not work as expected (the Common Lisp documentation) in Chrome, but works in IE which supports client-side XSLT:

http://common-lisp.net/project/bknr/static/lmman/toc.html

This index page above is displayed correctly, but all links will drive to XML documents with a basic XSL declaration to an existing XSL stylesheet document, and you can wait indefinitely, thinking that the chapters have problems to be downloaded. All you can do to read the docuemntation is to open the console and read the source code in the Resources tab.

Sismondi

Answer 6

Check http://www.aranedabienesraices.com.ar

This site is built with XML/XSLT client-side. It works on IE6-7-8, FF, O, Safari and Chrome. Are you sending HTTP headers correctly? Are you respecting the same-origin policy?

Garland

See my answer, I've solved it. Chrome seems to require an xmlns attribute. – Herbarium

I don't think so. To perform the transformation, Chrome does not need to set the default namespace to XHTML namespace. To render XHTML it needs proper XHTML, of course. You are mixing things. – Garland

The site referenced above is not built with XML but with XHTML. The two are not quite the same (both are XML but one is also HTML and the other is not). – Lumen

Answer 7

As close as I can tell, Chrome is looking for the header

Content-Type: text/xml

Then it works --- other iterations have failed.

Make sure your web server is providing this. It also explains why it fails for file://URI xml files.

Zuleika

Answer 8

What Eric says is correct.

In the xsl, for the xsl:stylesheet tag have the following attributes

version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml"

It works fine in chrome.

Shied

Answer 9

I started testing this and ran into the local file / Chrome security issue. A very simple workaround is put the XML and XSL file in, say, Dropbox public folder and get links to both files. Put the link to the XSL transform in the XML head. Use the XML link in Chrome AND IT WORKS!

Duty

Answer 10

After 8 years the situation is changed a bit.

I'm unable to open a new session of Google Chrome without other parameters and allow 'file:' schema.

On macOS I do:

open -n -a "Google Chrome" --args \
    --disable-web-security \               # This disable all CORS and other security checks
    --user-data-dir=$HOME/fakeChromeDir    # This let you to force open a new Google Chrome session

Without this arguments I'm unable to test the XSL stylesheet in local.

Glide

Answer 11

I tried putting the file in the wwwroot. So when accessing the page in Chrome, this is the address localhost/yourpage.xml.

Higginson