chore: Bump xmldom to 0.8.0

[karfau]

Switching from package xmldom to @xmldom/xmldom, which resolves the security issue present in latest xmldom version 0.6.0:
GHSA-5fg8-2547-mr8q

The reason is that the maintainers were forced to switch to a scoped package since 0.7.0:
xmldom/xmldom#271

No matter what version of node I used to try and run the normal npm install, I always received a warning about either old package lock file format or newer lock file version format.
So to avoid to many unrelated changes, I disabled the postinstall step locally and installed the root level using node v12 and the mbTest folder using node v16.

• When running the npm run test on the root level using node v12, there is a single failing test, but running them with node v16 works.So let's see what happens on CircleCI.
• When running cb mbTest && npm run test (using node 16) The first listed test fails. When adding MB_AIRPLANE_MODE=true there are quite a bunch of tests failing... not sure if this is really related to the xmldom update.

I'm happy to fix any regression we introduced, I just need help to understand how exactly the xmldom upgrade influences the failing test(s).

I'm one of the xmldom maintainers. Don't hesitate to ask me questions.

Changes in xmldom since 0.6.0

## [0.8.0](https://github.com/xmldom/xmldom/compare/0.7.5...0.8.0)

Fixed

• Normalize all line endings according to XML specs 1.0 and 1.1
  BREAKING CHANGE: Certain combination of line break characters are normalized to a single \n before parsing takes place and will no longer be preserved.
  • #303 / #307
  • #49, #97, #324 / #314
• XMLSerializer: Preserve whitespace character references #284 / #310
  BREAKING CHANGE: If you relied on the not spec compliant preservation of literal \t, \n or \r in attribute values.
  To preserve those you will have to create XML that instead contains the correct numerical (or hexadecimal) equivalent (e.g. 	, 
, 
).
• Drop deprecated exports DOMImplementation and XMLSerializer from lib/dom-parser.js #53 / #309
  BREAKING CHANGE: Use the one provided by the main package export.
• dom: Remove all links as part of removeChild #343 / #355

Chore

• ci: Restore latest tested node version to 16.x #325
• ci: Split test and lint steps into jobs #111 / #304
• Pinned and updated devDependencies

Thank you @marrus-sh, @victorandree, @mdierolf, @tsabbay, @fatihpense for your contributions

0.7.5

Commits

Fixes:

• Preserve default namespace when serializing #319 / #321
  Thank you @lupestro

0.7.4

Commits

Fixes:

• Restore ability to parse __prototype__ attributes #315
  Thank you @dsimsonOMF

0.7.3

Commits

Fixes:

• Add doctype when parsing from string #277 / #301
• Correct typo in error message #294
  Thank you @rrthomas

Refactor:

• Improve exports & require statements, new main package entry #233

Docs:

• Fix Stryker badge #298
• Fix link to help-wanted issues #299

Chore:

• Execute stryker:dry-run on branches #302
• Fix stryker config #300
• Split test and lint scripts #297
• Switch to stryker dashboard owned by org #292

0.7.2

Commits

Fixes:

• Types: Add index.d.ts to packaged files #288
  Thank you @forty

0.7.1

Commits

Fixes:

• Types: Copy types from DefinitelyTyped #283
  Thank you @kachkaev

Chore:

• package.json: remove author, maintainers, etc. #279

0.7.0

Commits

Due to #271 this version was published as

• unscoped xmldom package to github (git tags 0.7.0 and 0.7.0+unscoped)
• scoped @xmldom/xmldom package to npm (git tag 0.7.0+scoped)
  For more details look at #278

Fixes:

• Security: Misinterpretation of malicious XML input CVE-2021-32796
• Implement Document.getElementsByClassName as specified #213, thank you @ChALkeR
• Inherit namespace prefix from parent when required #268
• Handle whitespace in closing tags #267
• Update DOMImplementation according to recent specs #210
  BREAKING CHANGE: Only if you "passed features to be marked as available as a constructor arguments" and expected it to "magically work".
• No longer serializes any namespaces with an empty URI #244
  (related to #168 released in 0.6.0)
  BREAKING CHANGE: Only if you rely on "unsetting" a namespace prefix by setting it to an empty string
• Set localName as part of Document.createElement #229, thank you @rrthomas

CI

• We are now additionally running tests against node v16
• Stryker tests on the master branch now run against node v14

Docs

• Describe relations with and between specs: #211, #247

[bbyars]

Thanks! Sorry for a slow response, been busy but should free up shortly and will respond.

[bbyars]

First, thank you so much for creating a PR like this. It's pretty amazing that you not only updated your package but made an attempt at updating the ecosystem around it.

The failing test is causing me some head-scratching so I'll describe it here in case you have an idea based on a deeper understanding of the change. The cause appears to be an assumption in another npm package (xpath), which sets a case sensitivity flag based on an check that I'm struggling to wrap my brain around (doc.implementation.hasFeature("HTML", "2.0")). The test that's failing in mountebank has nothing to do with HTML; it uses a simple document of "<TITLE>value</TITLE>". Here's a simplified view of the xpath code, including their comment. This code sets caseInsensitive to false before the xmldom change and true after:

  // backward compatibility - no reliable way to detect whether the DOM is HTML, but
  // this library has been using this method up until now, so we will continue to use it
  // ONLY when using an XPathExpression
  this.context.caseInsensitive = XPathExpression.detectHtmlDom(n);

    XPathExpression.detectHtmlDom = function (n) {
        if (!n) { return false; }

        var doc = XPathExpression.getOwnerDocument(n);

        try {
            return doc.implementation.hasFeature("HTML", "2.0");
        } catch (e) {
            return true;
        }
    }

Any thing strike you as obvious about the change that would flip that feature between versions?

[bbyars]

After a bit more research, I suspect it's a legacy check in xpath, but I don't understand the issue well enough to make a PR there, so I ended up patching xmldom. Works as far as I can tell, but LMK if you think there's something wrong with this code:

    if (doc && doc.implementation) {
        // Monkey patch due to some legacy case sensitivity check in xpath
        // Couldn't find a way to patch xpath due to closures so patched the dom instead
        const originalHasFeature = doc.implementation.hasFeature;
        doc.implementation.hasFeature = (feature, version) => {
            if (feature === 'HTML' && version === '2.0') {
                return false;
            }
            else {
                return originalHasFeature.apply(doc.implementation, [feature, version]);
            }
        };
    }

And, thanks again for all your effort!

[karfau]

Yes, before 0.7.0 DOMImplementation.hasFeature had a very strange implementation where the "enabled features could be passed as constructor arguments (or return flase)". Since 0.7.0 it always returns true which is what the specs suggest.

I'm very close to finish a change that will allow HTML detection again starting from 0.9.0.
I will let you know when it's available, so you can stop patching xmldom :)

(Of course you could simplify your patch to just always return false, to replicate the previous behavior.)

[karfau]

O and goto100/xpath#27 (comment) suggests there is an isHtml option you can set to true to avoid the detection. Maybe that also works for you test?

[karfau]

I will let you know when it's available, so you can stop patching xmldom :)

Sorry that was an offer I have to take back. I have to many things to keep track of already. Feel free subscribe to the related issue or PR or to watch the xmldom releases, so I don't have to remember to notify you 🤝

[bbyars]

Not a problem, thanks again for your help,

…

On Thu, Feb 24, 2022 at 1:14 PM Christian Bewernitz < ***@***.***> wrote: I will let you know when it's available, so you can stop patching xmldom :) Sorry that was an offer I have to take back. I have to many things to keep track of already. Feel free subscribe to the related issue <xmldom/xmldom#203> or PR <xmldom/xmldom#338> or to watch the xmldom releases <https://github.com/xmldom/xmldom/releases>, so I don't have to remember to notify you 🤝 — Reply to this email directly, view it on GitHub <#660 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARFP4UVSRJ3HM3WGIKU2DU4Z7TFANCNFSM5KYBC7EA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>