search

xml3d / xml3d.js

The WebGL/JS implementation of XML3D
Other
75 stars 25 forks source link

XML Syntax error for large XML files in Chrome #145

Open eherr opened 9 years ago

eherr commented 9 years ago

Chrome raises XML Syntax error exceptions when processing large XML files. The error can be caused by referencing to an asset file larger than 60 mb generated by ATLAS 1.0. 

<group id="middle_console" >
        <model src="assets/middle_console3.xml#middle_console3"></model>
</group>

In xml3d version 4.8 and 5.0 the reference to the asset leads to the following error messages:

xml3d-5.0: resourcemanager.js:291 Uncaught TypeError: Cannot set property '_documentURL' of null
xml3d-4.8: xml3d-4.8.js:1403 Invalid external XML document 'http://localhost:8889/assets/middle_console3.xml': XML

The same problem occurs for GET requests for large XML files. This was tested with the ATLAS 1.0 REST interface and the Compass client 2.0.1 (that uses xml3d version 'DEVELOPMENT SNAPSHOT (19.09.2014 14:57:58 MESZ)';.

xml3d.js.xhtml:1497 Invalid external XML document ... url ... : XML Syntax error
ns.debug.doLog  @   xml3d.js.xhtml:1497
ns.debug.logError   @   xml3d.js.xhtml:1520
setDocumentData @   xml3d.js.xhtml:9999
processResponse @   xml3d.js.xhtml:9972
xmlHttp.onreadystatechange  @   xml3d.js.xhtml:9952

The problem was reproduced in a different client that loads assets from ATLAS 1.0 using the following request.

$.ajax({
type: "GET",
dataType: 'xml',
url: uri,
headers: { "Accept":"model/vnd.xml3d.model+xml, */*; q=0.5"    },
success: function(response) {
  ....
}});

The problem could be circumvented in this client by making the request with the response type set to 'text'. The response can then be converted into an XML DOM Object using the DOMParser object.

$.ajax({
type: "GET",
dataType: 'text',
url: uri,
headers: { "Accept":"model/vnd.xml3d.model+xml, */*; q=0.5"    },
success: function(response) {
  parser=new DOMParser();
  xmlDoc=parser.parseFromString(response ,"text/xml");
  ....
}});

Performing the GET requests with an XMLHttpRequest object instead of jquery has corresponding results for the response types 'text' and 'document'.

The problem was found only in Chrome (Version 45.0.2454.85 m, 32 and 64-bit). Firefox (Version 40.0.3) can process the XML files produced by ATLAS 1.0 without a problem.

Supporting commented 9 years ago

This is related to #125, which addresses bad error reporting in cases XML is no parseable. The missing error reporting is solved in 970ca087c9d10d82e78b4508a731a8404d66c2e2. However, response is also null in Chrome when the XML buffer exceed the internal buffer (described here and in comments of #125), we should do a manual retry using DOMParser or request XML3D files always as text and do the parsing explicitly (don't know if this affects runtime/memory performance).

csvurt commented 9 years ago

This is related to a bug in Chrome 45 as detailed here:

https://code.google.com/p/chromium/issues/detail?id=528078

Set to be fixed in Chrome 46.

Parsing the response manually will also bind the URL field of the resulting document to the base URL of the page that initiated the request, not the URL of the external reference that was fetched. We would need a workaround for this similar to the document.documentURL workaround that was introduced for IE 11.

I'll schedule this for 5.1, but since the underlying cause is actually a bug in Chrome we may decide to leave it as is if it doesn't become a problem in other browsers.