Tags: Fix null reference error in tags input on render (closes #23044)

[AndyButland]

Description

Fixes a TypeError: Cannot read properties of null (reading 'style') thrown from UmbTagsInputElement.updated() when rendering the tags input.

The updated() lifecycle hook unconditionally dereferenced the #main-tag and #input-width-tracker query results:

this._mainTag.style.width = `${this._widthTracker.offsetWidth - 4}px`;

#main-tag (the "add tag" button) is only rendered when the control is not readonly — #renderAddButton() returns nothing in readonly mode — so @query('#main-tag') resolves to null. The query can also be transiently null while the element re-renders, e.g. when navigating between two pages that both host a tags editor (the scenario in the issue, since tags are used on a shared composition across most pages). Because updated() fires on every render, this surfaced as an error in the console.

Fix

Guard the references before touching the elements:

protected override updated(): void {
    if (!this._mainTag || !this._widthTracker) return;
    this._mainTag.style.width = `${this._widthTracker.offsetWidth - 4}px`;
}

Fixes #23044

Testing

I considered an automated unit test but it didn't feel like it added enough value to introduce a test class for what's just a guard.

To test manually, open up a couple of documents with a tags editor and navigate back and forth between them in the backoffice. Before I could clearly see the error, after the fix I don't.

Make sure adding and saving tags continues to work as expected.

[claude]

Claude finished @AndyButland's task in 2m 6s —— View job

---

PR Review

Target: origin/v17/dev · Based on commit: ab47ddf9

Guards null references in UmbTagsInputElement.updated() to prevent a TypeError crash when #main-tag is absent (readonly mode) or transiently null during re-renders.

---

Suggestions

• tags-input.element.ts:192–193: The comment spans two lines, which exceeds the project's "one short line max" policy (CLAUDE.md §8). The content is justified — non-obvious WHY — but it could be condensed. E.g.: // #main-tag is absent in readonly mode and can be transiently null during re-renders.

• tags-input.element.ts:231–238: #inputError() accesses this._mainTag.style without a null guard. It's only reachable via keyboard/input event handlers on the non-readonly input, so it's much less exposed than updated() (which fires on every render). Still worth a defensive guard for parity, in case the same transient teardown scenario ever applies.

• No test added: Per CLAUDE.md §9, a bug-fix test should fail before the fix. A component test that sets readonly and triggers updated() would verify the guard. Given this is a transient render-state scenario, it's admittedly tricky to test reliably — omitting is understandable for src/packages/* (Standard testing priority), but worth noting.

---

Approved with Suggestions for improvement

Good to go, but please carefully consider the importance of the suggestions.

Labels applied: area/frontend, category/ux

[Copilot]

Pull request overview

Fixes a runtime crash in the backoffice umb-tags-input web component by preventing updated() from dereferencing DOM queries that can be null (notably when the control is readonly and #main-tag isn’t rendered).

Changes:

• Added a guard in UmbTagsInputElement.updated() to return early when #main-tag or #input-width-tracker isn’t available.
• Documented why the guard is necessary (readonly rendering + transient re-renders).