New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 8441 link

Starred by 37 users

Issue metadata

Status: WontFix
Last visit > 30 days ago
Closed: Dec 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

XSLTProcessor in JS does not permit xsl:include for http

Reported by, Mar 5 2009

Issue description

Chrome Version       :
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3,4 beta: FAIL
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. press "Run Transform" - in result empty, I.e. transformation failed
2. remove xsl:include in top text area, press "Run Transform" - result 

What is the expected result?
Transformation passed.

What happens instead?
failed. Exception thrown in JS during xsltProcessor.transformToDocument 
real life use case works fine on file system, failed on web:

I suspect security settings in XSLT engine are broken for http. (again, on 
file system all fine).
Feel free to contact directly.

sasha (at)


Comment 2 by, Oct 12 2009

I can also confirm having this issue. 
Googling also found that i'm not the only one. Heck a complete fix for this bug is 
already posted on:

Would love this to be fixed asap!

Comment 3 by, Oct 12 2009

What's the fix?  I'd have to pay experts exchange to see what's posted there.

Comment 4 by, Oct 12 2009

You don't have to pay actually you can scroll down to see the answers :) 
Actually, experts-exchange only displays the answers at the bottom when referred from
a search engine.

Here is the answer as posted:
Hi zc2,

I know you closed this question, but you asked me to update if I knew something more.
These days I played a bit with the source code of Chrome (quite a bit of a piece of
code, btw) and tried to find the point of error and/or a workaround.

Unfortunately, the place in the code where XSLT is resolving external documents (id.
for xsl:import/include) does never run. It uses an if-statement that is supposed to
check the validity of the URL, but because of negligence of the programmers, they
forgot to give it a context-frame, which is necessary for that piece of code to
return true (i.e., valid).

End of the story: it is a bug, and quite a major one. They do have all the code there
to make it work, but due to this bug it doesn't work. I changed the code a bit and
managed to get it working without too much efforts. Here's a screenshot of a
beta-build with modified source that runs your code correctly:

[picture with working solution]

The solution was posted by 'able'. His profile page on experts-exchange is at:

where you can find his email address.

Comment 6 by, Oct 12 2009

Status: Assigned

Comment 7 by, Oct 12 2009

Thanks!  I've sent him email asking if he'd be willing to contribute his patch.
Any updates on the state of this issue?

Comment 9 by, Oct 29 2009

Labels: -Area-Misc Area-WebKit
He has sent me his patch yet.  We're focusing on Mstone-4 bugs at the moment.  Once that push is over, I'll 
return to this bug.

Comment 10 by, Oct 29 2009

Labels: Mstone-5
Status: Started
Sorry for the delay.  This is now on the top of my list.
Wow, I'm not sure this code ever worked.  I see the problem.  Looking for a solution.
Status: WontFix
This is an architectural problem in WebKit:

The problem is that Frame-less document can't load sub-resources.  We're not going to
get this fixed for Mstone-5.  If you load the test case in a normal frame, everything
works fine:

We'll eventually fix this issue, but I'm "duping" this issue against WebKit's 10313.

Comment 14 by Deleted ...@, Jun 24 2010

Hi, I have that bug, too. Any ideas how to fix it ? 
@andrew: I currently work around this bug by preprocessing the stylesheets.
See here for a description of how I arrived at this solution:

Here is the script I use to preprocess stylesheets that use xsl:import:

I then incorporate the stylesheet preprocessing into the build step.

xsl:include could likely be handled similarly, with a slightly modified script.
I actually use xsl:param with xsl:include, when the param is at the top xsl, and the included xsl needs to read it.

I could work around with some codes and plugins to bypass the xsl:include problem, but there still this one, i need to get params to work there too. It works at Internet Explorer and FF, but not Chrome.

Any ideas on when this will be fixed?
I really need to be able to load additional XML resources via the document function of XSLT over XMLHttpRequest for my design pattern as demonstrated by which works in Opera and Firefox, but not in Webkit Safari or Chrome. This is the only way I can think of to keep the architecture modular and scalable.

Can it be true that this has still not been addressed? Sorry if I sound a bit frustrated, but it has killed my development stone dead for over a year
@abarth: hahaha...
"We'll eventually fix this issue" = Status: WontFix

This is silly that WebKit won't support this w3c documented standard.  It is even crazier to think the first bug was submitted in 2006.  It is out-of-control that I have to recommend Internet Explorer as an alternative browser.

-disappointed developer
I'm sorry you're disappointed.  Please feel free to submit a patch for

Comment 20 by, Jun 26 2012

Status: Available
This bug is causing an issue with a large Google Apps enterprise customer using an XML authoring system called "easyDITA" that otherwise works fine in various versions of Firefox and Internet Explorer.  Please reconsider a fix, as this would allow this enterprise customer to standardize completely on Chrome and ditch Firefox/IE.
Labels: -Mstone-5
Owner: ----
I won't be able to get to this anytime soon.
Can this be revisited?
Project Member

Comment 23 by, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 24 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Labels: Cr-Blink-XML

Comment 26 Deleted

Comment 27 by, Dec 29 2013

It's still not fixed (Chrome version 31) after over 4 years, so here's a partial client-side workaround to get xsl:include working.

Before calling XSLTProcessor.importStylesheet( xsl ),
add this check:

      if ( )         // Chrome detection
        xslResolveIncludes( xsl );   // special treatment

Here's the method:

  var xslns = "";

  // remove xsl:include tags, fetch them, and
  // insert them into the original xsl.
  function xslResolveIncludes( xsl )
      var includes = xsl.getElementsByTagNameNS( xslns, "include" ); // NodeList

      // reverse order to maintain NodeList integrity
      for ( var i = includes.length -1; i >= 0; i-- )
          var n = includes.item(i);
          var d = xmlRequest( xsl.documentURI + "/../" + n.getAttribute('href') )
          replaceNode( n, d.documentElement.childNodes );

The xmlRequest(), replaceNode() and other functions can be found in the attached file
if need be.


If you declare attributes in included stylesheets, they will not be available.
For instance, if your included file contains 
  <xsl:stylesheet ....
   <xsl:template match="FOO">
     <xsl:variable name="node">
       <xsl:apply-templates select="." mode="foo"/>
     <xsl:apply-templates select="exsl:node-set($node)" mode="link"/>

then the 'FOO' template will not work, since the 'exsl' prefix is not imported
into the including xsl. 
To do this properly, identical namespace prefixes with different namespace uri's would
have to be renamed, etc. (I tested calling importStylesheet for each xsl but
this didn't work).

IMPORTANT: xsl:import is NOT addressed by this example, so to have transformTo(Document|Fragment) return non-null, these will have to be removed aswell, in a similar fashion. 
Also, recursion is not implemented. These are left as an exercise for the reader ;-)

I any case, I didn't see a solution that didn't require either modifying the Chrome sourcecode
or performing XSLT transformations server-side, so I thought I'd offer the beginning of a truly portable solution ;-)
5.0 KB View Download
Status: WontFix
We're not planning to improve our XSLT implementation.

Comment 29 by, Dec 30 2013

You're joking right?

Or do you really want Chrome to be the only browser that doesn't comply with current standards?
We would prefer to remove support for XSLT, but we haven't decided whether we're actually going to remove the feature.  If you're using XSLT on the client, I'd recommend migrating to HTML, CSS, and JavaScript, perhaps by applying the XSLT on the server.  If/when we decide to remove XSLT support, we'll communicate more broadly about the timeline and migration options.

I realize that adding this comment to this bug is likely to trigger a large number of unhappy comments.  However, I think it's better to be truthful about our plans in this area than to silently ignore the topic.

If you'd like to read more about our motivations for wanting to make this change, you can read this blink-dev thread:

There are a handful of other threads on this topic on the blink-dev mailing list.  The current status of this topic is that no one is actively working on removing XSLT support, but, by the same token, no one is working on improving our XSLT support either.

Comment 31 by, Dec 30 2013

I have never been happy about the support of XSLT in Chrome. It's basically the only web browser which is missing full XSLT support. But on the other side, I understand that Google don't want to put resources in something which is hardly used.

Fortunately there is a new project ( which is trying to implement XSLT Processor purely in JavaScript. This could offer browser-independent solution for those who still need to use XSLT on the client side.
Yeah, I'd much rather see XSLT built on top of the platform rather than built into the platform.  In the past, when JavaScript was slow, building features like XSLT into the platform made sense because they'd be vastly faster implemented in C++.  Now that JavaScript is fast, an approach like Frameless is much more powerful because you don't need to wait for browsers to catch up.  You can iterate more quickly and build an awesome framework.

Comment 33 by, Dec 31 2013

@ #32
XSLT has been a standard since 1999, so, lots of time for the browsers to have caught up.
The 'awesome framework' would be a rewrite of an existing framework, though, and writing new software means writing new bugs.
And, how fast it is developed has little to do with whether it is written in JavaScript or any other language.

If you want to build on top of the platform, then you should also build XML and HTML parsers in JavaScript. In fact, write the entire browser in JavaScript. 
Isn't it the task of 'the platform' to provide all shared functionality to deserve that name?

The whole idea of offering a scripted language for client side processing is to separate it from the 'platform' or execution context, as it is another level of abstraction. This is why it is possible to implement security features in the first place.

Going this way, I'm not really sure whether this 'platform' will be anything more than a virtual machine, like the JRE or Zend. Perhaps sites should also let the clients download the javascript code for the browser itself.

Also, interpreted languages are by definition slow. Software speed is measured relative to CPU opcode processing speed.
I can guarantee you that any Javascript engine will not be faster than a native binary. Even if hotspot or 'just in time' compilation technology is employed, the result will be native CPU opcodes, which proves my point. In that case, all that is effectively done is letting users download the sourcecode for libxslt and compiling it every time it is used. How is this faster?

Comment 34 by, Dec 31 2013 is not open source and I wouldn't never ever use any software with such a license.

Comment 35 by, Apr 13 2014

Anyone using Saxon-CE ( successfully as an open source replacement for frameless?

Comment 36 by Deleted ...@, Jun 9 2014

-- it's better to be truthful about our plans in this area than to silently ignore the topic.

But the truth is you *have* silently ignored this topic. This bug has been open since 2009.

In your link you claim the reason for dropping XSLT support is nobody uses it. Yet this bug has been a major problem for many AJAX developers, who had to tell their clients to use another browser. Have you ever considered that you may not have seen so much XSLTProcessor use because of this bug? But yet you claim a desire to drop XLST support because nobody uses XSLT. To be blunt: that argument I find circular and disingenuous.

Our corporate users asked us to support Chrome despite this bug, and we wrote a JavaScript work around (but Chrome is still slower than Firefox or IE because of this -- scripts are an imperfect solution).

Either way, it is your browser. Do what you want. 

I for one have the opinion Google does want want to support XSLT because the more developers that use JavaScript libraries (often supplied by Google as free options which developers use without thinking about their end uses) the more Google can track users. As for me I will again tell my customers, with a shrug, to use Firefox or IE. We give our users all the facts about using Firefox with add-ons like NoScript enabled to prevent Google tracking, which was a hard sell year ago, but more recently has gotten a lot of ears lately, especially in Europe.

Comment 37 by, Sep 19 2014

-- -- it's better to be truthful about our plans in this area than to silently ignore the topic.

-- But the truth is you *have* silently ignored this topic. This bug has been open since 2009.

I am another victim on the enterprise side that has suffered from this bug for too long observing it not being fixed for all that time.

I can subscribe under every word of the #36 comment. 

By saying that you're truthful is a hypocrisy. Nobody is using it, because of this bug. The xslt is a standard, and Chrome by not fixing this and similar bugs due to a political reason places itself into a strange and awkward position of negating all the great and hard work that was done overall.

Comment 38 by Deleted ...@, Jan 28 2015

xsl:include in stylesheets don't work on Google Chrome. any suggestion ?
thanks in advanced

Comment 39 by Deleted ...@, Feb 23 2015

I did get Saxon-CE working XSLT20Processor working perfectly for my XSLT Transform in Chrome!

It was very easy since our existing application used XSLTTransform. I just replaced it with XSLT20Processor as a result from Saxon.newXSLT20Processor, and voila! Works.

Sign in to add a comment