Bug: XML-XSL-SVG-based applications stopped working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-08 12:18:35+00:00
Resolved: 2020-11-11 00:24:37+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

* Preamble:
In 2012-2013 I developed XML-XSL-SVG-based application for reporting the results of mass-spectrometry analysis, namely ms2prot (i.e. converting mass spectra to protein identifications). This application uses a very simple JS-dispatcher that processes XML-requests. There were two main purposes: reports should be easily shared just by copying them to web folders and be viewable locally without the need for a web server. Thus, they worked, i.e. rendered, by opening from local file storage as an ordinary file and from a web site via a link to the start page of an ms2prot report.

And there were several other requirements: the reports should be readable by human and external software and be independent from JavaScript and its libraries. The rationale of this requirement is as follows:
1. XML and SVG may be rendered much faster than extremely complex and buggy JS code implementing the same features.
2. To stop being in the hell of discontinuous versioning instead of respecting standards and use stable environment and requirements.

The critical disadvantage of JS is that JS code disallows reading its internal state, which is required for processing reports by external means. The most important and usable feature is importing SVG from a report into MS Visio to prepare complex function graphs (chromatograms) and embed them into slides, posters and manuscripts.

As the same origin policy was accepted as intentionally wrong security mean just to complicate the architecture of web applications and to make impossible a lot of advantages of shared library code, I used the following file structure for ms2prot report:

<ms2prot report>\
	data\
		{directory of each report page}*\
			*.svg
			tr_grp_rec.xml
		assay.dtd
		assay.xml
		rpt.xml
		sample_types.xml
		tr_grp_recs.xml		
	methods
		*.js
		*.xsl
	styles
		style.css
	ms2prot.htm

The same represented directory structure has a sample ms2prot report attached (ms2prot_for_testing.zip).

In a web server, the directory "methods", "styles" and common files in "data" are mapped to a specific version thus allowing updating the shared code just in one directory instead of in all reports. For the local version of ms2prot reports, the mentioned directories reside in the report directory itself. As you see, in both the cases the same origin policy is fullfilled, and the common directory is the root directory of a report.

* Previous state:
At least in the version 47, ms2prot reports function as desired without any errors. However, they worked only on Mozilla Firefox as only this browser had simultaneously the correct implementation of the same origin policy for XML and SVG as well as XML and SVG themselves. Neither Chromium/Safari nor MS Internet Explorer/Edge processed XML, SVG and the same origin policy as defined by the corresponding standards and concepts. Only Gecko did.
	
The title page for the above-mentioned work published in a scientific journal (that is why updating code is disallowed and impossible):
http://msr.ibmc.msk.ru/jpr2012/
The links to a few ms2prot reports for reproducing the bug are in the first column of the table in it.


Actual results:

ms2prot does no longer function: the browser even won't opening ms2prot reports, say nothing to rendering them as desired. When clicking to the ms2prot link, the browser creates new tab/window and then close it immediately. When opening developer tools and loading ms2prot.htm directly, the browser does not report any errors after putting XML request via the data/xml protocol. So, I wasn't able to debug ms2prot to clarify the bug.


Expected results:

Respecting the standards and the concept's definitions disregarding any versions, browsers, individual interpretations and beliefs. Any security means must have lower priority than the purpose for which they were invented, exist and applied: without reaching the purpose, any security means are nonsense as they are applied to noting. Otherwise, anyone who forced breaking security means became the intruder.

ms2prot reports should function as previously in the version 47. The same origin policy should determine the local filesystem directories as well as web directories and process them as defined by this concept in XML, XSL and SVG taking into account that the same origin can be any up level directory as defined by the policy.

XML and SVG should function at least with the features supported by the version 47. Again, respect standards and the efforts made to develop them so that users do not longer depend on individual interpretations of the standards and concepts. That is why mathematically correct definitions should be forced, applied and used as they are computable and hence verifiable, i.e. objective.

Most things can be and should be implemented without the use of JavaScript since immutable directives are processed by the layout engine much faster than any JS code, which disallows reading its internal state thus making impossible exporting the view state, e.g. polygons in SVG to external software.

This case rationales:
1. why things should work long time after without the need for any updates,
2. why the respect of standards is crucial and more important than discontinuous updates and critical dependencies on security "innovations", versions, browsers, engines, libraries and so on.
Just stop breaking things (that work earlier) to force any ideas. It is much better to complete the implementation of standards by removing all gaps, intermediate assumptions and temporary simplifications.