The problem looks to be related to the site adding a property to XMLDocument.prototype and expecting it to be accessible via "this", which is an instance of Document.

window.XMLDocument is of course non-standard, but we might be able to alias it to Document if many sites have this problem.

We should already be aliasing window.XMLDocument to DocumentConstructor.

So yes, adding a property to XMLDocument.prototype generally does make it accessible on document instances, so there must be something else going on.

This is because an old version of Sarissa library on this site saves a version of document.load from XMLDocument, and tries to execute it later. Newer versions of Sarissa don't have this problem. XMLDocument.prototype._sarissa_load=XMLDocument.prototype.load; // undefined XMLDocument.prototype.load=function(_1e){ // lots of code that boils down to simply calling _sarissa_load. } There is currently active discussion in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=14037> that may eventually change how we work with such code.

Some spec work happened and it was made window.XMLDocument was aliased: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14037 Later the issue came back up: https://github.com/whatwg/dom/issues/278 But it was more on Firefox changing and aligning with spec. From the test case - http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1130 I see - all browsers (Chrome Canary 106, Firefox Nightly 105 and Safari 15.6) are showing: log: true log: true log: false log: false rendering mode: CSS1Compat document has no title rniwa@webkit.org & ap@webkit.org - Is something more needed here?

See https://dom.spec.whatwg.org/#xmldocument *** This bug has been marked as a duplicate of bug 36465 ***