Upgrade tests to HTML5

@daffie so is anything else needed or is the patch here complete from your perspective?

This is not really a bug but I does look good and consistent to what we've previously done in core with StyleTestBase.

Back to RTBC

The meta issue lists several issues each changing a single test - can these please be rolled into 1 issue - breaking this type of work into several issues makes more work for everyone. Also

Please give commit credits to all who have worked on the parent issue

makes it a lot of work for a committer to work out who to credit.

Start working on reroll

Rerolled #1

ups @daffie,

lets go :D

Applying reroll of #12

Why are the following changes to non-test code needed? If we can remove them, then this can be tagged "rc eligible" per https://www.drupal.org/core/d8-allowed-changes#rc.

1. +++ b/core/lib/Drupal/Core/Entity/Entity.php
   @@ -150,7 +150,7 @@ public function label() {
   -      $label = $this->{$label_key};
   +      $label = (string) $this->{$label_key};
   

   .

2. +++ b/core/modules/editor/editor.admin.inc
   @@ -92,8 +92,8 @@ function editor_image_upload_settings_form(Editor $editor) {
   -    '#field_prefix' => '<div class="container-inline clearfix">',
   -    '#field_suffix' => '</div>',
   +    // '#field_prefix' => '<div class="container-inline clearfix">',
   +    // '#field_suffix' => '</div>',
   

   .

3. +++ b/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php
   @@ -210,8 +210,8 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
   -      '#field_prefix' => '<div class="container-inline">',
   -      '#field_suffix' => '</div>',
   +      // '#field_prefix' => '<div class="container-inline">',
   +      // '#field_suffix' => '</div>',
   

   .

Here's a straight reroll of #21. No interdiff since I haven't changed anything except to move sections to make it apply. I checked #21 against #12 and the only functional change (other than moving blocks was that #12 had the following:

@@ -2120,11 +2118,11 @@ protected function cronRun() {
    */
   protected function checkForMetaRefresh() {
     if (strpos($this->getRawContent(), '<meta ') && $this->parse()) {
-      $refresh = $this->xpath('//meta[@http-equiv="Refresh"]');
-      if (!empty($refresh)) {
+      preg_match('|<meta\s*http-equiv\s*=\s*"Refresh"\s*content="(.*)"\s*/>|', $this->getRawContent(), $matches);
+      if ($matches) {
         // Parse the content attribute of the meta tag for the format:
         // "[delay]: URL=[page_to_redirect_to]".
-        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $refresh[0]['content'], $match)) {
+        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $matches[1], $match)) {
           return $this->drupalGet($this->getAbsoluteUrl(Html::decodeEntities($match['url'])));
         }
       }

which #21 seems to have condensed to:

@@ -2204,12 +2202,13 @@ protected function cronRun() {
    */
   protected function checkForMetaRefresh() {
     if (strpos($this->getRawContent(), '<meta ') && $this->parse() && (!isset($this->maximumMetaRefreshCount) || $this->metaRefreshCount < $this->maximumMetaRefreshCount)) {
-      $refresh = $this->xpath('//meta[@http-equiv="Refresh"]');
-      if (!empty($refresh)) {
         // Parse the content attribute of the meta tag for the format:
         // "[delay]: URL=[page_to_redirect_to]".
-        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $refresh[0]['content'], $match)) {
-          $this->metaRefreshCount++;
+      preg_match('|<meta\s*http-equiv\s*=\s*"Refresh"\s*content="(.*)"\s*/>|', $this->getRawContent(), $matches);
+      if ($matches) {
+        // Parse the content attribute of the meta tag for the format:
+        // "[delay]: URL=[page_to_redirect_to]".
+        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $matches[1], $match)) {
           return $this->drupalGet($this->getAbsoluteUrl(Html::decodeEntities($match['url'])));
         }
       }

which seems functionally equivalent.

I will take my reroll and remove the changes to non-test files as noted by @effulgentsia in #25 since those are commenting field prefix and suffix that shouldn't matter and changing the return type hint for the Entity.php label function should also not be part of this test as far as I can see.

Here is a new patch and an interdiff. The interdiff only removes the trivial changes to non-test files.

The HTML5 parser has added the option 'disable_html_ns' which removes all of the weird namespace stuff I was doing before. Woot.

This adds the meta-refresh hack back.

This adds back some commented out field prefixes. The reason for those is to just get the tests passing. We're generating invalid markup in some places. That should be a separate issue.

This adds an incrementor in WebTestBase::checkForMetaRefresh(). I frankly don't understand how it worked before.

Edit: It was there the whole time, I just removed it in a previous patch.

Thanks for tackling this @twistor!

Had a review through the latest patch:

1. +++ b/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php
   @@ -210,8 +210,8 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
   -      '#field_prefix' => '<div class="container-inline">',
   -      '#field_suffix' => '</div>',
   +      // '#field_prefix' => '<div class="container-inline">',
   +      // '#field_suffix' => '</div>',
   

   Of course we'd love to move that to the template, are these making some failures?

2. +++ b/core/modules/image/src/Tests/ImageFieldDisplayTest.php
   @@ -317,8 +317,8 @@ function testImageFieldSettings() {
   -    $this->assertNoRaw('<input multiple type="file" id="edit-' . strtr($field_name, '_', '-') . '-2-upload" name="files[' . $field_name . '_2][]" size="22" class="js-form-file form-file">');
   -    $this->assertRaw('<input multiple type="file" id="edit-' . strtr($field_name, '_', '-') . '-3-upload" name="files[' . $field_name . '_3][]" size="22" class="js-form-file form-file">');
   +    $this->assertNoRaw('<input multiple="multiple" type="file" id="edit-' . strtr($field_name, '_', '-') . '-2-upload" name="files[' . $field_name . '_2][]" size="22" class="js-form-file form-file">');
   +    $this->assertRaw('<input multiple="multiple" type="file" id="edit-' . strtr($field_name, '_', '-') . '-3-upload" name="files[' . $field_name . '_3][]" size="22" class="js-form-file form-file">');
   

   multiple is valid HTML5 as boolean attributes. What made this change?
   https://www.w3.org/html/wg/drafts/html/master/infrastructure.html#boolea...

3. +++ b/core/modules/rdf/src/Tests/Field/FieldRdfaTestBase.php
   @@ -150,8 +151,7 @@ protected function getAbsoluteUri($entity) {
   -    @$htmlDom->loadHTML('<?xml encoding="UTF-8">' . $content);
   +    $htmlDom = (new HTML5(['disable_html_ns' => TRUE]))->loadHTML($content);
   

   Nice to see we don't ahve to supress.

4. +++ b/core/modules/simpletest/src/WebTestBase.php
   @@ -7,15 +7,14 @@
   -use Drupal\block\Entity\Block;
    use Drupal\Component\FileCache\FileCacheFactory;
   
   @@ -29,6 +28,8 @@
    use Drupal\Core\Url;
   +use Drupal\block\Entity\Block;
   +use Masterminds\HTML5;
   

   This move is incorrect in the ordering. b before C.

5. +++ b/core/modules/simpletest/src/WebTestBase.php
   @@ -1873,14 +1872,12 @@ protected function drupalProcessAjaxResponse($content, array $ajax_response, arr
   +            $command['data'] = strlen(trim($command['data'])) ? trim($command['data']) : $command['data'];
   

   Wasn't trimmed before, why is this needed?

6. +++ b/core/modules/simpletest/src/WebTestBase.php
   @@ -2082,12 +2079,16 @@ protected function cronRun() {
   -    if (strpos($this->getRawContent(), '<meta ') && $this->parse() && (!isset($this->maximumMetaRefreshCount) || $this->metaRefreshCount < $this->maximumMetaRefreshCount)) {
   -      $refresh = $this->xpath('//meta[@http-equiv="Refresh"]');
   -      if (!empty($refresh)) {
   +    $meta_continue = !isset($this->maximumMetaRefreshCount) || $this->metaRefreshCount < $this->maximumMetaRefreshCount;
   ...
   +        // Parse the content attribute of the meta tag for the format:
   +        // "[delay]: URL=[page_to_redirect_to]".
   +      preg_match('|<meta\s*http-equiv\s*=\s*"Refresh"\s*content="(.*?)"\s*/>|', $this->getRawContent(), $matches);
   +      if ($matches) {
   ...
   -        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $refresh[0]['content'], $match)) {
   +        if (preg_match('/\d+;\s*URL=(?<url>.*)/i', $matches[1], $match)) {
   

   Looks scope creepy, why all the changes in this hunk?

7. +++ b/core/modules/system/tests/modules/form_test/src/Form/FormTestCheckboxesZeroForm.php
   @@ -56,7 +56,7 @@ public function buildForm(array $form, FormStateInterface $form_state, $json = T
   -    if ($form_state->has('json')) {
   +    if ($form_state->get('json')) {
   

   in scope?

8. +++ b/core/modules/views/src/Tests/Plugin/DisplayFeedTest.php
   @@ -61,7 +62,7 @@ public function testFeedOutput() {
   -    $result = $this->xpath('//title');
   +    $result = $this->xpathXml('//title');
   

   Would be nice if xpath continued to work with XML or this could mess with contrib and may make this harder to get in.

Thanks for the review! This was just a very quick attempt to get things passing so we could figure out what's broken.

1. I haven't had time to figure out the exact problem. But I think those field prefixes get wrapped in span tags, and things go wrong. It could also be a bug in the HTML5 parser not fixing faulty markup correctly.
2. Have to dig into why the attribute change. That hopefully won't be staying.
3. Makes me happy too.
4. Yeah, stupid editor.
5. The HTML5 parser is creating text nodes if there is extra whitespace. There's another oddity here, where sometimes we're sending commands with only whitespace. Possibly related: #2245901: Trim trailing EOF whitespace from templates and #1237012: An empty status message in the AJAX response is added to the commands[] array and added to the DOM as an empty div tag
6. The regex change is because the HTML5 parser treats noscript tags as text.
7. Again, not sure how it worked before. The json flag is either 1, or 0, so has() should always be true.
8. That was a quick hack to get tests passing. I think we can do something smarter to detect the document type.

This addresses #4 and #8.

Regarding point 2, in comment #40:
This is changed because simpletest is emulating the ajax API, and the HTML5 parser is changing the attributes. This could be fixed, but I'm not sure if it matters.

I figured as much, I just thought I'd see what direction this was going.

I had a pain with one test that didn't work with DomDocument or HTML5, which was really sad. I ended up going for Regex to ensure the regression didn't happen. IIRC they were ignoring or correcting the markup which is not cool. The problem was nested <form> tags in views_form. For your reference in-case you want to maybe avoid some strange things #2558061: Nested form tag in views forms

Feel free to spin-off follow-ups for things that start diverging from the main IS goal.

#2667340: Usage of field_prefix and container-inline creates invalid markup. created.

Here's a patch with that added.

Update on point 2, in comment #40:
Core is settings multiple="multiple" by default. It was \DOMDocument that was changing it. The current test and behavior is actually more correct.

#2667358: CheckboxTest doesn't test what it thinks it's testing. addresses point 7 from #40.

Triaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.

This looks like it belongs in the testing component, phpunit.

The blocker issue #2667340: Usage of field_prefix and container-inline creates invalid markup. was fixed in #3072752: Invalid markup in ImageItem (causes test failures with symfony/dom-crawler:4.3+) so this is not postponed anymore.

Here is a reroll from last patch. We added more new \DOMDocument(); since then so this patch NW for that.

Two patches, one is just comming out of thin air, (73b)
the other is a reroll of patch 71 (73)

lets see how ugly it looks

I'm not sure what needs to be done (yet) to get the last passing tests, 73b wasn't good so start from 73.

any assistance appreciated
https://www.drupal.org/files/issues/2021-07-20/D93x-2441373-73.patch

I don't understand why we need to make these changes. The tests are passing with the HTML4 DOMDocument parser, and the updated tests don't seem to be any different except for the parser. What benefits does switching to the HTML5 parser bring to the tests?

The IS only talks about one class but scope was expanded to more classes, it needs updating to cover what we are supposed to be fixing here and why.

DOMDocument should be from masterminds HTML5 not xhtml

there's many postponed issues held up on this issue.

Currently the "Limit allowed HTML tags and correct faulty HTML" parser in core is still using xhtml not HTML5, it's rewriting HTML5 into xhtml. There's a whole bunch of postponed issues that are hinging on updating the tests to use the HTML5 masterminds api in this above patch.

Perhaps I've misunderstood but it seems that this issue blocks almost all of the HTML5 fixes from moving forward.

***EDIT*** I will retest my observations on a fresh install of of D9.2.1

ok perhaps #3133749: Deprecate masterminds/html5 as a production dependency for Drupal 10

changes things

one way or another, there's some work to do to completely fix HTML5 support and test coverage

I still don't see why the test changes have been split out to a different issue. How do we know which tests to change, and why are we doing them separately from the actual change to the filter system?

I asked myself the very same question as brought up by @longwave in comment #80

Looks like we're very close to completion with #2441811: Upgrade filter system to HTML5

as commited #2441811: Upgrade filter system to HTML5

Re-roll patch created as per #86. rdf changes has been removed from the patch as it is not part of core now.

Fixed the test case, Please have a look.

Was previously tagged for issue summary update which believe still needs to happen.

Also not 100% about the test fix in #88. Is that what HTML5 requires?

Also not 100% about the test fix in #88. Is that what HTML5 requires?

@smustgrave, Will take the reference from "related & committed" issue in #86, Please have a look on file "core/modules/filter/tests/src/Kernel/FilterCaptionTwigDebugTest.php" in the related issue and advise.

+++ b/core/modules/system/tests/src/Kernel/Theme/FunctionsTest.php
@@ -480,8 +481,7 @@ public function testDrupalPreRenderLinks() {
-    $dom = new \DOMDocument();
-    $dom->loadHTML($html);
+    $dom = (new HTML5())->loadHTML($html);

Can we use Html::load() here instead of using the HTML5 parser directly? Same for all the other places that we call new HTML5().

Addressed #92, Used Html::load() wherever we use HTML5(). Patch created, Please have a look.

Fixed test cases, Please have a look.

This looks good to me so far. The remaining uses of new DOMDocument() in tests are:

core/modules/help/tests/src/Functional/HelpTopicsSyntaxTest.php:    $doc = new \DOMDocument();
core/tests/Drupal/KernelTests/AssertContentTrait.php:        $dom = new \DOMDocument();
core/tests/Drupal/Tests/Component/Utility/HtmlTest.php:    $document = new \DOMDocument();

The latter two are explicit cases where we still need DOMDocument - loading XML instead of HTML and testing a specific serialization bug.

Not sure what to do with HelpTopicsSyntaxTest; it uses libxml to ensure the HTML is valid and unsure how we can port this to the HTML5 library.

Not sure what to do with HelpTopicsSyntaxTest; it uses libxml to ensure the HTML is valid and unsure how we can port this to the HTML5 library.

@longwave, there may be a port for HelpTopicsSyntaxTest .
Here a version of the validation there using Masterminds\HTML5 functionality.
Let us see what CI thinks.

Fixed the CCF issues.

@vsujeetkumar, thanks for the variable typo fix, I was hoping to not need to run it locally :'-)

The test fail in #97 was related to the approach change.
Basically the error strings are different on Masterminds\HTML5 parser, than in php DOM extension libxml2.
Gladly there seems to be only one actual relevant error tested from the library output, the rest are errors created on the test itself related to structure.

After changing a bit how this works, I arrived to a point were it is mainly OK, but there is a problem in one case, on bad_html3 help topic error template.
Likely the parsing is different and produces a bit different error for that case, or there is an actual error to fix.

I am attaching a couple of patches, one expected to fail without the workaround, and other skipping the check on that specific case.
At this point we may either use the patch at #94 and open a follow-up specifically for help topics, that my use the code on the patches in this comment; or continue here.

#99 patch fails to apply, created updated path without fails. Also on below comment I am also thinking the same for now we can go with #94 and do followups on help topics, Here we need expert advise.

At this point we may either use the patch at #94 and open a follow-up specifically for help topics, that my use the code on the patches in this comment; or continue here.

@vsujeetkumar: thanks for re-exporting the patch as p1!
It seems I exported p0 instead :'-)
I see the test results reflect the hypothesis \o/

Was previously tagged for issue summary update which still believe is needed.

Since this is fixing tests I'm wondering if it should just continue here. Is there a large number of help_topic tests that need to be fixed?

@smustgrave,

Was previously tagged for issue summary update which still believe is needed.

I have updated the description.

Since this is fixing tests I'm wondering if it should just continue here. Is there a large number of help_topic tests that need to be fixed?

Maybe :-)
Per my comment above at #99, I would suggest to apply the change on #94, which cover most of the cases, and open at least one follow-up for the help_topic test.

To answer the question, it is only one edge case in one of the help topics tests failing, but since that test is walking over all help topics data in core, it may be worth a follow-up.

Also, I noticed I did not even mentioned the other two cases @longwave mentioned on #95, but I arrived to the same conclusion.

The latter two are explicit cases where we still need DOMDocument - loading XML instead of HTML and testing a specific serialization bug.

On core/tests/Drupal/KernelTests/AssertContentTrait.php case, that new DOMDocument object is only used for parsing xml content, and around it, it already uses the Html::load() helper that will use HTML5 version from Masterminds.
Here an extract:

// This is an XML document.
if (stripos(ltrim($content), '<?xml') === 0) {
  $dom = new \DOMDocument();
  $dom->loadXML($content);
}
else { 
  $dom = Html::load($content);
}

On core/tests/Drupal/Tests/Component/Utility/HtmlTest.php case, it also seems OK.
The use there is just a new empty object passed on the next line to Html::serialize(), of which the signature of the method requires the DOMDocument class.
In other words, it is not really used for parsing, so it is OK to leave it as it.

@marvil07 thanks for the explanation. Opened up a follow up for help_topics.

There's a broken test. And...

+++ b/core/tests/Drupal/KernelTests/AssertContentTrait.php
@@ -122,14 +122,21 @@ protected function setDrupalSettings($settings) {
-      // DOM can load HTML soup. But, HTML soup can throw warnings, suppress
-      // them.
-      $html_dom = new \DOMDocument();
-      @$html_dom->loadHTML('<?xml encoding="UTF-8">' . $this->getRawContent(), LIBXML_NOBLANKS);
-      if ($html_dom) {
+      $content = $this->getRawContent();
+
+      // This is an XML document.
+      if (stripos(ltrim($content), '<?xml') === 0) {
+        $dom = new \DOMDocument();
+        $dom->loadXML($content);
+      }
+      else {
+        $dom = Html::load($content);
+      }

Is this checking for <?xml<code> actually necessary? Before we were adding <code><?xml encoding="UTF-8"> to the content so how would have the content that starts with

<?xml<code> actaully work?

I've tried to simulate what would have occurred before if you passed XML to parse():
<code>
$text = "<note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body></note>";
$text = '<?xml encoding="UTF-8">' . $text;
$html_dom = new \DOMDocument();
$html_dom->loadHTML('<?xml encoding="UTF-8">' . $text, LIBXML_NOBLANKS);
$elements = simplexml_import_dom($html_dom);

Which results in the following SimpleXml element

> $elements = simplexml_import_dom($html_dom);
= SimpleXMLElement {#11412
    +"body": SimpleXMLElement {#11529
      +"note": SimpleXMLElement {#11525
        +"to": "Tove",
        +"from": "Jani",
        +"heading": "Reminder",
      },
    },
  }

Which is nonsense compared to the input. We've added a body - because we're treating it as HTML and removed the spurious body from the HTML.

I think parse has always been expecting HTML and nothing else.

I guess #94 is supposed to be the patch to commit. Can that be re-uploaded so it is the last patch on the issue otherwise it is very very confusing. The comment about AssertContentTrait::parse() from #106 still stand. I couldn't see any supporting evidence on the issue that we need to support XML in that method and if we do then we need to have some test coverage of it in AssertContentTraitTest.

I think parse has always been expecting HTML and nothing else.

@alexpott, that may be the case, I guess the changes were being cautious, trying to not change the logic more than needed.

I see that the actual parse() method was added at 0858e9350b8d99a8476b78a845e1531fb124acef in 2018, so it has been there for a while.
That method is part of AssertContentTrait, which is mainly used in KernelTestBase, an naturally on DrupalKernel by extension.

I do not see direct uses of parse().
The following is an attempt to search for that, which only leads a false positive, i.e. not using $this.

$ grep -F -- '->parse(' $(git grep \( -e KernelTestBase --or -e DrupalKernel \) --and -e extends --name-only)
core/tests/Drupal/KernelTests/Config/DefaultConfigTest.php:    $info = \Drupal::service('info_parser')->parse($file_name);

Even if no direct uses, parse() is used indirectly through the highly used xpath() method on the same trait.
Said that, I could not find anything, at least with the following search, of use with non-HTML.

$ grep -F -- 'this->xpath(' $(git grep \( -e KernelTestBase --or -e DrupalKernel \) --and -e extends --name-only)
core/modules/comment/tests/src/Kernel/Views/CommentUserNameTest.php:    $comment_author = $this->xpath('//div[contains(@class, :class)]/span[normalize-space(text())=""]', [
core/modules/field/tests/src/Kernel/FieldDisplayTest.php:    $elements = $this->xpath($css_selector_converter->toXPath('.visually-hidden'));
core/modules/history/tests/src/Kernel/Views/HistoryTimestampTest.php:    $result = $this->xpath('//span[@class=:class]', [':class' => 'marker']);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//a[@href=:path]/img[@src=:url and @width=:width and @height=:height]', [':path' => base_path() . $path, ':url' => $url, ':width' => $image->getWidth(), ':height' => $image->getHeight()]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//a[@href=:path]/img[@src=:url and @width=:width and @height=:height and @alt=""]', [':path' => base_path() . $path, ':url' => $url, ':width' => $image->getWidth(), ':height' => $image->getHeight()]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//a[@href=:fragment]/img[@src=:url and @width=:width and @height=:height and @alt=""]', [
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//img[@src=:url and @alt=""]', [':url' => $url]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//img[@src=:url]', [':url' => $url]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//img[contains(@class, class) and contains(@alt, :alt)]', [":class" => "image-with-regular-alt", ":alt" => "Regular alt"]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//img[contains(@class, class) and contains(@alt, :alt)]', [":class" => "image-with-attribute-alt", ":alt" => "Attribute alt"]);
core/modules/image/tests/src/Kernel/ImageThemeFunctionTest.php:    $elements = $this->xpath('//img[contains(@class, class) and contains(@alt, :alt)]', [":class" => "image-with-attribute-alt", ":alt" => "Attribute alt"]);
core/modules/system/tests/src/Kernel/Form/ElementsFieldsetTest.php:    $elements = $this->xpath('//fieldset[@id="' . $field_id . '" and @aria-describedby="' . $description_id . '"]//div[@id="edit-meta-default"]/following-sibling::div[@id="' . $description_id . '"]');
core/modules/system/tests/src/Kernel/Form/ElementsFieldsetTest.php:    $elements = $this->xpath('//fieldset[@id="' . $field_id . '" and @aria-describedby="' . $description_id . '"]//div[@id="edit-meta-before"]/preceding-sibling::div[@id="' . $description_id . '"]');
core/modules/system/tests/src/Kernel/Form/ElementsFieldsetTest.php:    $elements = $this->xpath('//fieldset[@id="' . $field_id . '" and @aria-describedby="' . $description_id . '"]//div[@id="edit-meta-after"]/following-sibling::div[@id="' . $description_id . '"]');
core/modules/system/tests/src/Kernel/Form/ElementsFieldsetTest.php:    $elements = $this->xpath('//fieldset[@id="' . $field_id . '" and @aria-describedby="' . $description_id . '"]//div[@id="edit-meta-invisible"]/following-sibling::div[contains(@class, "visually-hidden")]');
core/modules/system/tests/src/Kernel/Form/FormElementLabelTest.php:    $elements = $this->xpath($css_selector_converter->toXPath('.kitten'));
core/modules/system/tests/src/Kernel/Form/FormElementLabelTest.php:    $elements = $this->xpath($css_selector_converter->toXPath('label.meow'));
core/modules/system/tests/src/Kernel/Form/FormElementMaxlengthTest.php:    $elements = $this->xpath($css_selector_converter->toXPath('input[name=title][maxlength=255]'));
core/modules/system/tests/src/Kernel/Form/FormElementMaxlengthTest.php:    $elements = $this->xpath($css_selector_converter->toXPath('textarea[name=description][maxlength=255]'));
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath($header_xpath);
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath($footer_xpath);
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath($header_xpath);
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath($footer_xpath);
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath('//div[@class = "' . $view_class . '"]/header[1]');
core/modules/views/tests/src/Kernel/Handler/AreaEntityTest.php:    $result = $this->xpath('//div[@class = "' . $view_class . '"]/footer[1]');
core/modules/views/tests/src/Kernel/Handler/FieldFieldTest.php:    $field_values = $this->xpath('//div[contains(@class, "views-field-id")]/span[contains(@class, :class)]/div', [':class' => 'field-content']);
core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php:    $result = $this->xpath('//div[@class=:class]/a', [':class' => 'more-link']);
core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php:    $result = $this->xpath('//div[@class=:class]/a', [':class' => 'more-link']);
core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php:    $result = $this->xpath('//div[@class=:class]/a', [':class' => 'more-link']);
core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php:    $result = $this->xpath('//div[@class=:class]/a', [':class' => 'more-link']);
core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php:        $this->assertCount(5, $this->xpath("{$xpath}[not(text()) and not(node())]"), "Empty rows in theme '$theme', type '$type'.");
core/modules/views/tests/src/Kernel/Plugin/ExposedFormRenderTest.php:    $result = $this->xpath('//form//div[contains(@id, "edit-type--2--description") and normalize-space(text())="Exposed description"]');
core/modules/views/tests/src/Kernel/Plugin/StyleGridResponsiveTest.php:    $result = $this->xpath('//div[contains(@class, "views-view-responsive-grid") and contains(@class, :alignment)]', [':alignment' => 'views-view-responsive-grid--' . $expected['alignment']]);
core/modules/views/tests/src/Kernel/Plugin/StyleGridResponsiveTest.php:    $result = $this->xpath('//div[contains(@class, "views-view-responsive-grid") and contains(@style, :columns)]', [':columns' => '--views-responsive-grid--column-count:' . $expected['columns']]);
core/modules/views/tests/src/Kernel/Plugin/StyleGridResponsiveTest.php:    $result = $this->xpath('//div[contains(@class, "views-view-responsive-grid") and contains(@style, :min-width)]', [':min-width' => '--views-responsive-grid--cell-min-width:' . $expected['cell_min_width'] . 'px']);
core/modules/views/tests/src/Kernel/Plugin/StyleGridResponsiveTest.php:    $result = $this->xpath('//div[contains(@class, "views-view-responsive-grid") and contains(@style, :gutter)]', [':gutter' => '--views-responsive-grid--layout-gap:' . $expected['grid_gutter'] . 'px']);
core/modules/views/tests/src/Kernel/Plugin/StyleGridResponsiveTest.php:    $result = $this->xpath('//div[contains(@class, "views-view-responsive-grid")]/div[contains(@class, "views-view-responsive-grid__item")]/div[contains(@class, "views-view-responsive-grid__item-inner")]');
core/modules/views/tests/src/Kernel/Plugin/StyleGridTest.php:      $result = $this->xpath('//div[contains(@class, "views-view-grid") and contains(@class, :alignment) and contains(@class, :columns)]', [':alignment' => $alignment, ':columns' => 'cols-' . $columns]);
core/modules/views/tests/src/Kernel/Plugin/StyleGridTest.php:    $result = $this->xpath('//div[contains(@class, "views-col") and contains(@class, :columns) and starts-with(@style, :width)]', [':columns' => 'col-' . $columns, ':width' => 'width: ' . $width]);
core/modules/views/tests/src/Kernel/Plugin/StyleGridTest.php:    $result = $this->xpath('//div[contains(@class, "views-col") and contains(@class, :columns)]', [':columns' => 'col-' . ($columns + 1)]);
core/modules/views/tests/src/Kernel/Plugin/StyleGridTest.php:    $result = $this->xpath('//div[contains(@class, "views-col") and contains(@class, "name-John")]');
core/modules/views/tests/src/Kernel/Plugin/StyleGridTest.php:    $result = $this->xpath('//div[contains(@class, "views-row") and contains(@class, "age-25")]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-element-container"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-row"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-row"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-element-container"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-row"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $xpath = $this->xpath('//div[@class="views-row"]');
core/modules/views/tests/src/Kernel/ViewElementTest.php:    $this->assertCount(1, $this->xpath('//form[@class="views-exposed-form"]'));
core/tests/Drupal/KernelTests/Core/Form/ExternalFormUrlTest.php:    $elements = $this->xpath('//form/@action');
core/tests/Drupal/KernelTests/Core/Form/ExternalFormUrlTest.php:    $elements = $this->xpath('//form/@action');
core/tests/Drupal/KernelTests/Core/Form/FormActionXssTest.php:    $elements = $this->xpath('//form');
core/tests/Drupal/KernelTests/Core/Render/Element/TableTest.php:    $tableheader = $this->xpath("//script[contains(@src, 'tableheader.js')]");
core/tests/Drupal/KernelTests/Core/Render/Element/TableTest.php:    $tableheader = $this->xpath("//script[contains(@src, 'tableheader.js')]");

In other words, it likely makes sense to remove the support to try to parse XML, since all found uses are about HTML.
I see test results pass after the change, so you were probably right!

I guess #94 is supposed to be the patch to commit. Can that be re-uploaded so it is the last patch on the issue otherwise it is very very confusing.

Yes, I guess we have not been hiding files enough in this issue to make that clear.
I have just opened a new merge request with two commits, the first apply the patch in 94, and the second removes support for XML on the parse() method.
The interdiff would be the new commit, so let me point to that directly instead of uploading one here .

Only other test I see that has loadXML is HelpTopicsSyntaxTest which was broken off to a follow up. So remarking this one.

Committed and pushed 13883cc3808 to 11.x and ca47a29ef9f to 10.2.x. Thanks!

Backported to 10.2.x as this is making only test changes.