HTML is escaped in "all languages" in UI after SafeMarkup change

It could be one of the methods in #2501975: Determine how to update code that currently joins strings in SafeMarkup::set() will fix it.

Ha - I didn't actually test it. Could you provide steps to reproduce. I know little about content translation. How do I get that HTML to appear?

@cilefen I think your solution there is fine, but the real problem is further down the stack.

Xss::filterAdmin in template_preprocess_form_element_label().

Should be using SafeMarkup as they are now separated nicely for their appropriate domains:)

I didn't need the extra parens in there and twig with strict off doesn't need to initialize the variables, so this is a bit cleaner.

Since @alexpott worked hard on the other one, it would be good to get his opinion here. Also SafeMarkup::checkAdminXss() looks like a good use case here but it's been deprecated also.

Here's some manual testing on simplytest.me:

+++ b/core/includes/form.inc
@@ -191,7 +191,10 @@ function template_preprocess_fieldset(&$variables) {
+    $variables['legend']['title'] = SafeMarkup::xssFilter($element['#title'], Xss::getAdminTagList());

@@ -489,7 +492,10 @@ function template_preprocess_form_element(&$variables) {
+    $variables['title'] = SafeMarkup::xssFilter($element['#title'], Xss::getAdminTagList());

I don't think we need to be doing the escaping here ['#markup' => $element['#title']] should make the render system do this later.

Here's the updated patch and a screenshot.

I think this addressed the feedback from @alexpott, but we still need review.

We can probably just add some assertRaw statements to the existing content translation UI tests?

Added the test (as suggested in #10).

How is this different from #2501975: Determine how to update code that currently joins strings in SafeMarkup::set()? It looks like the source of this is the concatenation in ContentTranslationHandler::addTranslatabilityClue().

Fixed the failing tests.

Rerolled and inverted the flag.

Fixes the rendered html and tests pass now.

This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed bfb0580 and pushed to 8.0.x. Thanks!

I'm still having this issue in the details field using Drupal 8.0.4. HTML is escaped in the details title. See attached screenshot.

The bug is not fully resolved as you forgot to also fix the template_preprocess_details(9 function. I made a patch. This should be fixed aswell

Thanks for the new patch @ayalon. I've re-rolled it and set version to 8.1.x. Let's see if it passes tests.

Try to avoid re-opening issues, it will get confusing to what the issue was trying to solve. Instead create a follow-up. But first try to see if an existing issue exists.

This exact patch is here #2652850: Title for details form elements is not set as '#markup' and it will be escaped, but all other form elements use '#markup' and are not escaped. It's good to post a comment to cross-reference if they are related.

The last patch did not completely fix the issue, if you tried to go and modify content (a page with a form field) or edit any form an error occurs that causes the site to break. Fixed.

on date fields the label problem still exists. For more details follow the issue linked in #24