Synchronous XMLHttpRequest on the main thread is deprecated

[mrft]

When trying to use the javascript API

var xsltDoc = Saxon.requestXML(...);
Saxon.newXSLT20Processor( xsltDoc );

I got the following message in chromium:

"Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/."

[michaelhkay]

Probably this means your stylesheet has a call on the doc() or document() function.

If you want to avoid this kind of effect, you need to break the stylesheet execution up at appropriate points using call-template with ixsl:schedule-action so that the browser has a chance to respond to user interaction events.

Michael Kay
Saxonica

On 20 May 2015, at 08:51, mrft [email protected] wrote:

When trying to use the javascript API

var xsltDoc = Saxon.requestXML(...);
Saxon.newXSLT20Processor( xsltDoc );
I got the following message in chromium:

"Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/. http://xhr.spec.whatwg.org/"

—
Reply to this email directly or view it on GitHub #5.

[kosek]

Just FYI, recently some browser vendors wanted to get rid of synchronous XHR at all, so this is probably result of this effort -- you will get warning if you use synchronous XHR. But I don't expect they will remove this from platform soon.

[mrft]

I don't really understand what you mean by "your stylesheet has a call on the doc() or document() function". Could you explain?

[michaelhkay]

If your stylesheet calls doc() or document() to retrieve an XML document from the server, Saxon (via GWT) translates that into a synchronoous XML HTTP request. There’s not really any practical alternative.

Michael Kay
Saxonica

On 20 May 2015, at 16:36, mrft [email protected] wrote:

I don't really understand what you mean by "your stylesheet has a call on the doc() or document() function". Could you explain?

—
Reply to this email directly or view it on GitHub #5 (comment).

[mrft]

My stylesheet doesn't do that... it is one single (long) stylesheet containing everything.

You say:
"There’s not really any practical alternative."

But there are different styles in javascript for handling asynchronous function calls, like 'the nodejs way', or using promises.
Maybe it would make more sense to make the loading of documents and the stylesheet processing an asynchronous operation.

[ghost]

Any updates on this? It is the intention of the Saxon-CE developers to eliminate the synchronous load? Can I do my own xml and xsl loads (asynchronously) and then pass those to Saxon?

[michaelhkay]

First point: we’re not actually doing any active development on Saxon-CE at the moment. That doesn’t mean we’ve abandoned it, just that it’s not top of our priority list and we have limited resources.

I don’t see any solution in sight to avoid a synchronous HTTP request if the stylesheet calls doc() or document(). But you can avoid this in your application if you know before the transformation starts what documents you want to load: you can load them yourself and supply them as transformation parameters.

Michael Kay
Saxonica

On 24 Jul 2015, at 17:26, Chris Harrington [email protected] wrote:

Any updates on this? It is the intention of the Saxon-CE developers to eliminate the synchronous load? Can I do my own xml and xsl loads (asynchronously) and then pass those to Saxon?

—
Reply to this email directly or view it on GitHub #5 (comment).

[ghost]

Hi Michael,
First, thanks for the speedy reply, and for being totally awesome!
So here's what I have in my test:

function onSaxonLoad()
{
  var xslt = Saxon.requestXML("test.xsl")
  var proc = Saxon.newXSLT20Processor(xslt);
  var xml = Saxon.requestXML("test.xml");
  proc.updateHTMLDocument(xml);
}

What's the simplest change one can make to eliminate the warning? Can it be done natively with the Saxon object?

[ghost]

I changed the code as follows. But my transform time went from 200ms to 8000ms. Why would how I load the xml and xsl change the transform time?

var xslDoc, xmlDoc;
var xslReq, xmlReq;

function getXml() {
    if (xmlReq.readyState==4 && xmlReq.status==200) {
       xmlDoc = xmlReq.responseXML;
       var proc = Saxon.newXSLT20Processor(xslDoc);
       console.time("transf");
       proc.updateHTMLDocument(xmlDoc);
       console.timeEnd("transf");
    }
}

function getXsl() {
    if (xslReq.readyState==4 && xslReq.status==200) {
       xslDoc = xslReq.responseXML;
       // now get xml
       xmlReq = new XMLHttpRequest();
       xmlReq.onreadystatechange = getXml;
       xmlReq.open("GET","test.xml",true);
       xmlReq.send();
    }
}

function onSaxonLoad()
{
  xslReq = new XMLHttpRequest();
  xslReq.onreadystatechange = getXsl;
  xslReq.open("GET","test.xsl",true);
  xslReq.send();
}

Before It was timed as follows:

function onSaxonLoad()
{
    var xslt = Saxon.requestXML("test.xsl")
    var proc = Saxon.newXSLT20Processor(xslt);
    var xml = Saxon.requestXML("test.xml");
    console.time("transf");
    proc.updateHTMLDocument(xml);
    console.timeEnd("transf");
}

[michaelhkay]

What's the simplest change one can make to eliminate the warning? Can it be done natively with the Saxon object?

I’m not entirely sure where the warning is coming from, but I think it may be purely because the browser detects the presence of Javascript code that does an asynchronous request, even if that code is not executed. If that’s the case then there’s not much we can do about it because the code is generated by GWT.

Michael Kay
Saxonica

[michaelhkay]

I may have misread this, but aren’t the times for loading the documents included in your measurement in one case, and excluded in the other? If you do things asynchronously, then the costs aren't incurred at the point you make the request.

Michael Kay
Saxonica

On 24 Jul 2015, at 18:07, Chris Harrington [email protected] wrote:

I changed the code as follows. But my transform time went from 200ms to 8000ms. Why would how I load the xml and xsl change the transform time?

var xslDoc, xmlDoc;
var xslReq, xmlReq;

function getXml() {
if (xmlReq.readyState==4 && xmlReq.status==200) {
xmlDoc = xmlReq.responseXML;
var proc = Saxon.newXSLT20Processor(xslDoc);
console.time("transf");
proc.updateHTMLDocument(xmlDoc);
console.timeEnd("transf");
}
}

function getXsl() {
if (xslReq.readyState==4 && xslReq.status==200) {
xslDoc = xslReq.responseXML;
// now get xml
xmlReq = new XMLHttpRequest();
xmlReq.onreadystatechange = getXml;
xmlReq.open("GET","test.xml",true);
xmlReq.send();
}
}

function onSaxonLoad()
{
xslReq = new XMLHttpRequest();
xslReq.onreadystatechange = getXsl;
xslReq.open("GET","test.xsl",true);
xslReq.send();
}
Before It was timed as follows:

function onSaxonLoad()
{
var xslt = Saxon.requestXML("test.xsl")
var proc = Saxon.newXSLT20Processor(xslt);
var xml = Saxon.requestXML("test.xml");
console.time("transf");
proc.updateHTMLDocument(xml);
console.timeEnd("transf");
}
—
Reply to this email directly or view it on GitHub #5 (comment).

[ghost]

Hi Michael,
In both cases my timer only wraps the proc.updateHTMLDocument() call.
But the change in runtime doesn't make much sense. Is there a code change that you can think to try?

• Chris

[pgfearo]

"Why would how I load the xml and xsl change the transform time?"

If I recall correctly:
When you use Saxon.requestXML to fetch the XSLT stylesheet and the source XML (as in your first example), the Saxon-CE XsltProcessor invokes both requests asynchonously .

If the XSLT request completes first, compilation can start while the XML is still being loaded. If the XML source request completes first then the transform starts as soon as the XSLT response completes and the XSLT source is compiled. This strategy can lead to significant time-saving.

You could change your code to adopt this strategy, but I don't think it will prevent the deprecation warning that seems to be triggered even when Saxon-CE is only using asynchronous requests.

[ghost]

Ok - that make sense.

On a different note, I'm curious if there is any initiative to port Saxon
to ES6. It seems that there is imminent support in major browsers.

On Sat, Aug 15, 2015 at 8:01 AM, Phil Fearon [email protected]
wrote:

"Why would how I load the xml and xsl change the transform time?"

If I recall correctly:
When you use Saxon.requestXML to fetch the XSLT stylesheet and the source
XML (as in your first example), the Saxon-CE XsltProcessor invokes both
requests asynchonously .

If the XSLT request completes first, compilation can start while the XML
is still being loaded. If the XML source request completes first then the
transform starts as soon as the XSLT response completes and the XSLT source
is compiled. This strategy can lead to significant time-saving.

You could change your code to adopt this strategy, but I don't think it
will prevent the deprecation warning that seems to be triggered even when
Saxon-CE is only using asynchronous requests.

—
Reply to this email directly or view it on GitHub
#5 (comment).

[michaelhkay]

On a different note, I'm curious if there is any initiative to port Saxon
to ES6. It seems that there is imminent support in major browsers.

Rather depends on what happens to GWT.

I’ve started thinking, however (no more than that) about an eventual replacement for Saxon-CE that is an XSLT runtime rather than a full XSLT interpreter; it would execute an intermediate representation of the stylesheet compiled server-side in advance. It might well be written natively in JS rather than compiled using GWT. Removing the GWT dependency would be liberating (and open up the possibility of a server-side engine under node-js) and I think we could get the whole thing down to a much more acceptable size. ES6 has some very nice features (I particularly like the class/method syntax) that makes this a much pleasanter prospect.

Michael Kay
Saxonica

[ghost]

Compiling to an intermediate representation that can run on
WebAssembly/LLVM is probably the a good idea.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/086881.html

Perhaps something like:
XSLT -> Java -> LLVM -> WebAssembly

I think the pieces are falling into place. I'd be happy to contribute some
effort to this initiative.

• Chris

On Sat, Aug 15, 2015 at 1:28 PM, Michael Kay [email protected]
wrote:

On a different note, I'm curious if there is any initiative to port Saxon
to ES6. It seems that there is imminent support in major browsers.

Rather depends on what happens to GWT.

I’ve started thinking, however (no more than that) about an eventual
replacement for Saxon-CE that is an XSLT runtime rather than a full XSLT
interpreter; it would execute an intermediate representation of the
stylesheet compiled server-side in advance. It might well be written
natively in JS rather than compiled using GWT. Removing the GWT dependency
would be liberating (and open up the possibility of a server-side engine
under node-js) and I think we could get the whole thing down to a much more
acceptable size. ES6 has some very nice features (I particularly like the
class/method syntax) that makes this a much pleasanter prospect.

Michael Kay
Saxonica

—
Reply to this email directly or view it on GitHub
#5 (comment).