https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41053

--- Comment #6 from Martin Renvoize (ashimema) 
<[email protected]> ---
Adding some history I found whilst digging into this.. I'm slightly concerned
we're removing sandboxing with this patch.

---

Bug 12123 (2014) - Iframe introduced
  - Problem: HTML notices with malformed HTML (unclosed tags, invalid nesting
like <blockquote> inside <p>) were breaking the notice viewer interface
  - Solution: Used <iframe srcdoc="..."> to sandbox the HTML content and
prevent it from affecting the parent page structure
  - Key quote: "Depending on the content of an html notice, it can cause the
notice to either not be collapsible, be uncollapsible, or to be permanently
collapsed."

  Bug 39410 (March 2025) - Shadow DOM added
  - Problem: Notice previews in the staff interface showed Bootstrap styles
that wouldn't actually appear in emails/prints sent to patrons
  - Solution: When displaying the notice modal, the content from the iframe's
srcdoc is loaded into a Shadow DOM to isolate CSS
  - Result: More accurate preview showing what patrons actually see

  Bug 41053 (This bug) - Changed the iframe to a hidden div
  - Problem: Browser search (Ctrl+F) couldn't find text in the iframe's srcdoc
attribute
  - Solution: Changed from iframe to <div style="display:none;"> with content
as innerHTML
  - Benefit: Search now works again - users can search notice content
  - Note: Shadow DOM is still used when displaying the modal, maintaining CSS
isolation

  Potential Disadvantages of the Current Approach

  1. Loss of HTML Isolation in the DOM
  The iframe provided complete sandboxing - malformed HTML couldn't escape and
affect the page. With a div, even though the content is HTML-escaped ([%
QUEUED_MESSAGE.html_content | html %]), there's theoretically more risk if:
  - The Template Toolkit escaping fails
  - There's a bug in the escaping mechanism
  - Extremely malformed HTML somehow breaks through

  2. Security Considerations
  - The iframe's srcdoc provided an additional layer of XSS protection
  - The current approach relies on Template Toolkit's | html filter being
robust

All in all, I "think" the Change is Likely Safe, but i want to test with some
really malformed notices before passing qa

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to