1675997 - XML-XSL-SVG-based applications stopped working because of wrong implementation of the same origin policy

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[Aleksey F.]

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-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 software and be independent from JavaScript and its libraries (as XML and SVG may be rendered much faster than extremely complex and buggy JS code implementing the same features, and because of 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 -- importing SVG from a report into MS Visio to prepare complex function graphs (chromatograms) and embed them into slides, posters and manuscripts.

Previous state
Till 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. For example, neither Chromium/Safari nor MS Internet Explorer/Edge processed XML, SVG and the same origin policy as defined by the corresponding standards. 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 are in the first column of the table in it.

Actual results:

After Mozilla Firefox migrated to Chromium, ms2prot does no longer function as Chromium ignores the difference between local filesystem directories and files as well as some unidentified behavior that prevents loading XSL as XML supports in its standard.

As a result the browser even won't opening ms2prot reports, say nothing to rendering them as desired and as before the migration to Chromium. And the browser does not report any errors so I wasn't able to debug ms2prot.

Expected results:

Respecting the standards and the concept's definitions disregarding versions and browsers.

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.

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.

Most things can be and should be implemented without the use of JavaScript as constant directives are processed by the layout engine much faster than any JS code, which disallows reading its internal state. This case rationales why things should work as developed long time after, and why the respect of standards is crucial and more important than discontinuous updates and critical dependencies on versions, browsers, engines, libraries and so on.

Comment 1

[Aleksey F.]

If I am wrong about migrating to Chromium then sorry (so please update the title). All other said is still in act.