Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronous XMLHttpRequest on the main thread is deprecated #5

Open
mrft opened this issue May 20, 2015 · 16 comments
Open

Synchronous XMLHttpRequest on the main thread is deprecated #5

mrft opened this issue May 20, 2015 · 16 comments

Comments

@mrft
Copy link

mrft commented May 20, 2015

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
Copy link
Member

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
Copy link

kosek commented May 20, 2015

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
Copy link
Author

mrft commented May 20, 2015

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

@michaelhkay
Copy link
Member

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
Copy link
Author

mrft commented May 20, 2015

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
Copy link

ghost commented Jul 24, 2015

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
Copy link
Member

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
Copy link

ghost commented Jul 24, 2015

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
Copy link

ghost commented Jul 24, 2015

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
Copy link
Member

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
Copy link
Member

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
Copy link

ghost commented Aug 14, 2015

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
Copy link

pgfearo commented Aug 15, 2015

"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
Copy link

ghost commented Aug 15, 2015

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
Copy link
Member

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
Copy link

ghost commented Aug 15, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants