Closed (won't fix)
Project:
Drupal core
Version:
9.3.x-dev
Component:
forms system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
2 Oct 2014 at 11:44 UTC
Updated:
18 Apr 2022 at 06:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
attiks commentedComment #2
larowlanPatch is good but if you want to rely on this behavior, I'd recommend adding a test.
Comment #3
jelle_sNew patch with test
Comment #4
attiks commentedTest is looking good
Comment #5
fabianx commentedCould we get #2324371: Fix common HTML escaped render #key values due to Twig autoescape in first, then this one could use SafeMarkup::checkAdminXss() and prevent double escaping of strings?
It is not a big deal if not, because filterAdminXss() is pretty much re-entrant, so more asking ...
Comment #6
damien tournoud commentedYes, isn't this type of thing supposed to be automatically handled by Twig autoescape now? I don't like seeing more
Xss::filterAdmincalls in preprocess functions.Comment #7
fabianx commentedWell, yes it escapes it.
So probably we could also say, if you need #title to have HTML, admin XSS escape it yourself.
Like:
#title => SafeMarkup::checkAdminXss('
mytitle
');
In this case this would be a won't fix.
Comment #8
attiks commented#7 Sounds good to me, but just wondering if this is documented somewhere, I guess a lot of people will otherwise waist time trying to figure out why they don't see their HTML.
Comment #9
fabianx commented#8 When you do that, does it strip the HTML tags or just output verbatim as:
<h1>Title</h1>?
In case it is output verbatim, I think people could know, in case its stripped, we should probably fix it.
The test is still very useful here.
Comment #10
attiks commented#9 Verbatim output
Comment #11
alexpottNeeds work for #5, #6, #7, #8, #9, #10 :)
Comment #12
attiks commentedMaybe this just has to be "won't fix"? Or will this complicate it for developers?
Comment #23
larowlanOn the basis of the last comment and lack of activity