Verify field labels are escaped properly

+++ b/src/Tests/IntegrationTest.php
@@ -88,6 +93,39 @@ class IntegrationTest extends WebTestBase {
+    $field_name = '^6%{[*>.<"field';
…
+    $this->assertRaw($field_name);

Doesn't this test exactly the opposite of what it should – i.e., that the field name occurs in the raw HTML as-is instead of escaped?
I think assertText($field_name) or assertRaw(Html::escape($field_name)) would be correct instead.

Looks better, thanks.
However, would it be possible to instead integrate it into the existing test*() method, so it won't run separately (and require its own site install). I know it's rather bad practice, but I can't really see it does much harm, and it certainly keeps the test run time down.

Also, it would be nice to also go to the "Processors" tab and verify that neither content type (for the "Rendered item" processor) nor field name appear unescaped there. (We should add that for the existing tests, too – it should appear escaped, and should not appear unescaped. Otherwise, it might just be escaped in one place, but unescaped in another. And we might even want to check it doesn't appear double-escaped. Maybe use a helper method for that.)

Third item: We should also change the index and server name to something with & in it and check whether this is always escaped properly. This is something we actually had problems with, having the index name unescaped inside the <title> tag, I think.

Finally, also verifying everything is properly escaped in Views would be ideal – but probably a bit too much. Even if we'd add it to the Views test, where Views is already enabled anyways, we'd still need to enable Views UI. We might want to at least add a separate issue for that, though.

Do you want to make those changes yourself or should I?

Great job, thanks!
And even better if this actually found something!

I also agree with you, the view stuff can and should follow in a separate issue.

Regarding the fix for the problem, though:

+++ b/src/Item/FieldTrait.php
@@ -317,7 +318,7 @@ trait FieldTrait {
         try {
-          $this->labelPrefix = $this->getDatasource()->label();
+          $this->labelPrefix = Html::escape($this->getDatasource()->label());
         }
         catch (SearchApiException $e) {
           watchdog_exception('search_api', $e);
@@ -325,7 +326,7 @@ trait FieldTrait {

@@ -325,7 +326,7 @@ trait FieldTrait {
         $this->labelPrefix .= ' » ';
       }
     }
-    return $this->labelPrefix . $this->getLabel();
+    return $this->labelPrefix . Html::escape($this->getLabel());

I don't think that's the proper place to fix that, it's not the job of the field object to return sanitized labels (especially if it's not documented that way).
Where is that actually used and displayed unsanitized? The escaping should be done there – and, optimally, in a way that avoids double-escaping. I think Html::escape() should usually not be used, since this doesn't mark the string as "sanitized", leading to potential double-escaping.

+++ b/src/Tests/IntegrationTest.php
@@ -640,4 +726,16 @@ class IntegrationTest extends WebTestBase {
+   * Test for how well a string is escaped.

The first line of a function/method doc block (same for classes/interfaces/traits) should start with a verb in third person. I'd rename that method to assertHtmlEscaped(), though, and document it with something like "Ensures that all occurrences of the given raw string in the page are properly escaped."

Nice job, looks great. Thanks!
Committed.
(After re-arranging the test methods to be in the same order as called, and adding a single "s".)