Notifications: Add htmlMessage for opt-in HTML rendering in toasts

[andrejd22]

Allows notifications/toasts to render HTML via a new opt-in htmlMessage field, so backend EventMessages can contain clickable links (the original goal of this PR).

How it works

• UmbNotificationDefaultData.htmlMessage?: string | TemplateResult — takes precedence over message. String values are sanitized (DOMPurify) before rendering; TemplateResults render as-is since Lit escapes their bindings. Mirrors UmbConfirmModalData.content.
• message keeps its plain-text contract — no behavioural change for existing peek()/stay() call sites or package developers.
• Backend EventMessages (the umb-notifications header) opt in via the API interceptor and render through umb-peek-error-notification. The plain message is kept markup-free because it is read aloud by the screen-reader announcer.
• Documented in docs/security.md; unit tests added for both notification layouts.

Why not render all messages as HTML (the original approach): sanitization silently strips angle-bracket plain text (e.g. IEnumerable<T> → IEnumerable), and sanitized markup from user-controlled strings (links, images, styled elements) would still render — a phishing/UI-spoofing vector. Making HTML opt-in scopes that trust decision to deliberate call sites.

Testing

1. Return an EventMessage from the server containing HTML, e.g. <a href="/umbraco">a link</a> → the toast renders a clickable link (scripts/event handlers are stripped).
2. Existing notifications (save, publish, errors, etc.) render exactly as before.

Taken over and reworked by HQ — thanks @andrejd22 for the contribution and the original implementation!

[github-actions]

Hi there @andrejd22, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR updates notification rendering to allow HTML content inside toast notifications by using Lit’s unsafeHTML directive.

Changes:

• Render default notification data.message as HTML via unsafeHTML.
• Render peek-error notification message as HTML when the message is a string, otherwise render the template as-is.
• Add unsafeHTML imports in relevant notification elements.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Umbraco.Web.UI.Client/src/packages/core/notification/layouts/default/notification-layout-default.element.ts	Switches default notification message rendering from text interpolation to unsafeHTML.
src/Umbraco.Web.UI.Client/src/packages/core/notification/controllers/peek-error/peek-error-notification.element.ts	Uses unsafeHTML for string messages while preserving non-string/template rendering.

[iOvergaard]

This is a good idea, but we need to sanitize the HTML first. Towards that purpose, you can import the sanitizeHTML function and use that.

import { sanitizeHTML } from '@umbraco-cms/backoffice/utils';

const sanitizedMessage = sanitizeHTML(this.#message);

return unsafeHTML(sanitizedMessage);

[andrejd22]

@iOvergaard added sanitizeHTML function. Thank you!

[adavidovic92]

@iOvergaard Is it possible to have this in Umbraco v17?

[iOvergaard]

Is it possible to have this in Umbraco v17?

It's a new feature, so generally I'd say no. It depends on how stable it is; that is probably the most I can promise at this point.