>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3613862. --> Reported by: [abhisekmazumdar](https://www.drupal.org/user/3557964) >>> <p>Title: Harden Answer block DOM id generation against duplicated-placement collisions</p> <h2>Problem/Motivation</h2> <p><code>AnswerBlock::build()</code> derives the block's root DOM id from a persisted <code>instance_uuid</code> setting, minted once per block placement on first save:</p> <pre><pre>$blockId = (string) ($config['instance_uuid'] ?? '');<br>$id = $blockId !== ''<br>&nbsp; ? Html::cleanCssIdentifier('ai-answers-answer-' . $blockId)<br>&nbsp; : Html::getUniqueId('ai-answers-answer');</pre></pre><p>This is already correct for the common case: two independently placed Answer blocks, even pointed at the same agent, get distinct <code>instance_uuid</code>s and therefore distinct DOM ids and <code>drupalSettings</code> buckets. There is no agent-id-based collision.</p> <p>There is a narrower, real edge case, already flagged in the block's own doc-comment: a <strong>duplicated placement</strong> (for example, via Layout Builder's "duplicate block" action) copies the <code>instance_uuid</code> verbatim into the new placement's configuration. Until that new placement is saved through <code>blockSubmit()</code> (which mints a fresh UUID), both placements render with the identical id &mdash; colliding <code>id</code> attribute, colliding <code>drupalSettings.aiAnswers.answer</code> key, and colliding citation anchor ids (<code>${root.id}-ref-${index}</code>).</p> <p>The <code>$blockId !== ''</code> branch bypasses <code>Html::getUniqueId()</code> entirely by calling <code>Html::cleanCssIdentifier()</code> instead. Verified directly against core (<code>core/lib/Drupal/Component/Utility/Html.php</code>): <code>getUniqueId()</code> sanitizes through the internal <code>getId()</code> helper, then checks a static <code>$seenIds</code> registry for the current request and appends a <code>--2</code>, <code>--3</code>, &hellip; suffix on collision &mdash; exactly the mechanism needed here, and it's already used one line below in the empty-<code>instance_uuid</code> fallback branch. Core's own docblock on <code>getId()</code> is explicit about the anti-pattern this issue describes: <em>"Only use this function when you want to intentionally skip the uniqueness guarantee of self::getUniqueId()."</em> Calling <code>cleanCssIdentifier()</code> directly has the same effect &mdash; no dedup registry involved &mdash; which is precisely the bug.</p> <h2>Steps to reproduce</h2> <ol> <li>Place an AI Answers Answer block on a page.</li> <li>Using Layout Builder (or any block-duplication path that copies configuration including <code>instance_uuid</code>), duplicate that block placement on the same page.</li> <li>Render the page before the duplicated placement has been independently saved through the block's configuration form.</li> <li>Observe both placements render with the identical <code>id</code> attribute and the same <code>drupalSettings.aiAnswers.answer</code> key, so only one of the two blocks initializes correctly client-side.</li> </ol> <h2>Proposed resolution</h2> <p>Route the <code>instance_uuid</code>-derived id through <code>Html::getUniqueId()</code> instead of <code>Html::cleanCssIdentifier()</code>:</p> <pre><pre>$blockId = (string) ($config['instance_uuid'] ?? '');<br>$id = $blockId !== ''<br>&nbsp; ? Html::getUniqueId('ai-answers-answer-' . $blockId)<br>&nbsp; : Html::getUniqueId('ai-answers-answer');</pre></pre><p><code>Html::getUniqueId()</code> sanitizes through <code>getId()</code> before deduplicating, which is not byte-for-byte identical to <code>cleanCssIdentifier()</code>: <code>getId()</code> additionally lowercases the string (<code>mb_strtolower()</code>) and does not special-case double underscores. In practice this is a no-op here &mdash; <code>instance_uuid</code> values are lowercase UUIDs &mdash; but worth calling out explicitly since it's a real, if inconsequential, difference in generated markup for anyone auditing the diff. The important behavioral change is deliberate: this only alters output when the exact same base id is requested twice in one request, which is precisely the collision this issue describes. This closes the gap without needing to explicitly detect "was this placement duplicated" &mdash; it fixes the observable symptom (id collision) regardless of cause.</p> <h2>Remaining tasks</h2> <ul> <li>Change the <code>Html::cleanCssIdentifier()</code> call to <code>Html::getUniqueId()</code> in <code>AnswerBlock::build()</code>.</li> <li>Add a test rendering two Answer block instances sharing the same <code>instance_uuid</code> in one request and asserting the resulting ids differ.</li> <li>Confirm citation anchor ids and <code>drupalSettings</code> keys (both derived from <code>root.id</code> in <code>js/ai_answers.answer.js</code>) correctly follow the deduplicated id with no further JS changes needed.</li> </ul> <h2>User interface changes</h2> <p>None visible; this only affects internal DOM id generation in the rare duplicated-and-unsaved-placement case.</p> <h2>API changes</h2> <p>None.</p> <h2>Data model changes</h2> <p>None.</p>