Repository navigation
isHtmlString web part property: target="_blank" is now stripped from links (still present in serverProcessedContent) #11079
Description
Target SharePoint environment
SharePoint Online
What SharePoint Framework version are you using?
1.21.1
Developer environment
Windows
What browser(s) / client(s) have you tested
Chrome (latest)
Describe the bug / error
Our web part stores rich text in a web part property declared as an HTML string, so it gets indexed by search:
protected get propertiesMetadata(): IWebPartPropertiesMetadata {
return {
'items[*].value': { isHtmlString: true }
};
}Authors edit the value with CKEditor. They can add links and choose whether each link opens in a new tab, which produces <a href="..." target="_blank">.
We didn't change any code, and pages that used to work are affected. The target attribute is missing from the value the web part gets.
Value we save:
<a href="https://google.com" target="_blank">Google</a>Value the web part receives in this.properties after the page loads:
<a href="https://google.com">Google</a>- The page's stored
serverProcessedContent.htmlStringsfor this property still containstarget="_blank". - At runtime,
this.properties.items[n].valuedoes not contain it.
So the stored data is intact. The attribute is removed when the page loads and the processed HTML is passed back to the web part.
We know SharePoint sanitizes isHtmlString values and already strips several other attributes, and we've accepted that. target is different because it was kept until recently.
This isn't the page router behavior described in the hyperlinking docs (data-interception). The attribute isn't in the HTML the web part receives at all.
Steps to reproduce
- Create a web part with a property declared as
isHtmlString: trueinpropertiesMetadata. - Set the property to
<a href="https://google.com" target="_blank">Google</a>, then save and publish the page. - Look at the page's canvas content (for example
CanvasContent1from the REST API).serverProcessedContent.htmlStringscontainstarget="_blank". - Reload the page and log the property in the web part (
onInit/render). The value is<a href="https://google.com">Google</a>, sotargetis missing.
Expected behavior
target="_blank" is kept on <a> elements, as it was before.
Questions
- Is removing
targetintentional, for example as part of a sanitizer or security change? If so, was it announced anywhere? - If the concern is reverse tabnabbing, would
target="_blank"be kept when it comes withrel="noopener noreferrer"? - Is there a supported way to keep the attribute, such as a metadata option or an allow-list? Is the list of tags and attributes the sanitizer keeps documented anywhere?
Removing isHtmlString would probably avoid the sanitizer, but we'd lose search indexing and link fix-up, so that isn't a real option for us.
Activity
m365-agent-toolkit-assistant commentedon Oct 29, 2026
👋 Hi Alexander Klechshev (@SharePickle),
Thank you for reporting this issue. Here is an AI-generated initial response:
Classification: Bug — the reported loss of
target="_blank"on reload is consistent with a regression in processed web-part properties, though its cause and whether the change is intentional remain unconfirmed.targetin storedserverProcessedContent.htmlStringsbut not inthis.properties. That points to property processing rather than click-time page routing. SharePoint documents HTML processing; its hyperlink guidance addresses a different case wheretargetreaches the link but is ignored on click.rel="noopener noreferrer"exception, or fixing release for this behavior.What to do now:
rel, and provide the first affected date, tenant details, and both stored and runtime values for investigation.isHtmlStringfor indexing and link fix-up, but store the author’s new-tab choice separately and apply it to validated links in your web part’s rendering. Don’t render raw stored HTML to bypass processing.Useful links:
SharePickle commentedon Oct 29, 2026
I saved link as:
This is what I've got after publishing the page:
relattribute anddata-interceptionare both preserved on reload, buttargetis gone.Checking in
maintenancemodestill shows the original link markup is still there and got thetargetattribute.Ashlesha-MSFT commentedon Oct 30, 2026
Hi Alexander Klechshev (@SharePickle)
Thanks for reporting this and providing detailed reproduction steps. We were able to reproduce the behavior in SharePoint Online using SPFx 1.23.2: the persisted HTML retains target="_blank", while the corresponding isHtmlString property received by the web part after reload does not. Adding rel="noopener noreferrer" did not prevent the removal.
We’ll raise a bug with the engineering team to investigate and confirm whether this behavior is intentional or a regression. We’ll update this issue when we have more information.