Add the QTI associate interaction plugin by rtibblesbot · Pull Request #6113 · learningequality/studio

rtibblesbot · 2026-08-31T16:20:36Z

Summary

<qti-associate-interaction> had no plugin, so it fell back to the choice descriptor: header "Multiple Choice", no choices rendered, an associate pool holding no <qti-simple-choice>. The plugin parses the flat pool into correct pairs plus distractors, serializes a cardinality="multiple" base-type="pair" declaration, validates and renders.

Long formulas are unbreakable inline nodes that painted over the card border. The bound went into TipTapEditor's .editor-content, so every TipTap editor clips, legacy ones included.

References

Fixes #6101.

Reviewer guidance

749 QTI editor Jest tests pass. Sole axe-core violation: AddListItemButton label contrast, shared with the untouched ordering editor.

Open risks (XML rules 8, 9):

buildXML merges equal-text choices, bumping match-max; blank text exempt, else new pairs never round-trip.
Distractors are match-max minus correct-response uses, so oversized hand-written match-max invents them on import.

QA steps

Setup: pnpm devsetup data, then #/qti-demo in a channel, question 7.

Toggle Show answers: Connect pairs header, pool of all options plus both distractors, pairs green only when on.
Edit prompt and pair cards, close, reopen: text, order, numbering survive, nothing merged or dropped.
Add pair opens the new row's first card; Add distractor drafts below the pool — filled joins on close, blank is dropped, second press re-focuses, close abandons.
Keyboard-delete pairs and distractors, open row included: rows renumber, focus moves to the replacing row or Add pair, last delete disabled.
Trigger then clear each error: blank prompt, blank choice, self-matching pair, distractor repeating a distractor or a paired item (flags both), too few pairs — red borders, incomplete marker clears.
Switch a question's type to Associate and back: prompt survives, blank editor usable at once, card header label follows.

Evidence

View mode and Show answers

Answers off	Answers on

Editing and the XML round trip

Before edits	After edits

Adding pairs and distractors

Add pressed	After

Draft typed	On close

Committing an open editor

Open	Committed

Deleting pairs and distractors

Before delete	After delete

Validation

With errors	Cleared

Switching the response type

Before switch	After switch

Long content inside the card

Responsive layout

Wide	Narrow

An authored associate question, saved and reloaded

Authored	After reload

Deviations from the issue spec

Criterion	Why not
A new distractor is saved from the editor opened below the pool	Committed on editor close, no Save button, per review — matches the other RTEs

AI usage

Used Claude Code to implement the plugin test-first against a written plan, following the ordering interaction as the reference. Verified with the Jest suite, pre-commit, manual QA on the QTI demo page, and an axe-core audit.

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran pre-flight CI checks (lint, format, tests) and verified all pass
Rebased onto the target branch and resolved any conflicts
Reorganized commit history into clean, logical commits
Audited the diff to ensure only issue-relevant files are changed
Built PR body from the repository's PR template with evidence blocks

	⚪ Updating PR Last updated: 2026-09-23 22:53 UTC

associate-add-pair-and-distractors.webm

associate-edit-close-reopen.webm

associate-keyboard-delete.webm

associate-minimize-commits.webm

associate-resize-while-editing.webm

associate-show-answers-toggle.webm

associate-type-switch.webm

associate-validation-messages.webm

associate-validation.webm

clip-long-content-stays-inside-card.webm

AlexVelezLl

@rtibblesbot, from the screenshots, I can see that the padding of the chips is not the same as in the specs, and the colors of the pair rows are not the same as in the specs. Take a closer look at the images in the issue and check that everything is correctly aligned.

rtibblesbot · 2026-08-31T22:14:34Z

@AlexVelezLl Fixed, and I swept every element in the editor against the six mockups rather than only the two you named — eight divergences, all changed:

Pair rows — grey.v_100 → grey.v_50 with a fineLine border; cards now sit on surface instead of inheriting the row tint.
Pair cards — 40px tall with an 8px text inset; were 50px at the editor's default 24px inset.
Chips — padding: 4px 12px with an 8px gap before the delete control; were 0 4px 0 12px, so the × sat flush against the border. Dropping the editor's paragraph margins takes them from 50px to 34px.
Chip fill — a chip inverts against its container: tinted in the distractor pool, white in the shuffled pool. Both were white.
Shuffled pool box — grey.v_100 → grey.v_50.
Correct-answer chip border — green.v_500 → green.v_600, matching the mockup and the choice/ordering editors.
Pair validation message — aligned to the row's left edge; it was indented under the cards.
Copy — Matching pairs, Distractors (optional), Response pool (shuffled), Add distractor and both sublabels, verbatim from the mockups. The branch shipped the plan's provisional wording (Correct pairs, Additional options, Options (shuffled), Add option) — which is also why the labels in the PR body's screenshots don't match what the branch renders. The four below are current.

Two mockup details I left out, both more than styling — say the word and I'll add them:

the SAVE button on the new-distractor editor (the sibling editors commit on type and close via the minimize control)
the Answer placeholder in an empty pair card (TipTapEditor has no placeholder prop)

State	Screenshot
Edit
View, answers shown
Validation
Small screen

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

AlexVelezLl

Just few findings from a high-level overview.

AlexVelezLl · 2026-09-01T13:12:59Z

  },
+
+  associateLabel: {
+    message: 'Connect pairs',


Could you translate it to "Associate" instead?

Renamed to Associate.

AlexVelezLl · 2026-09-01T13:13:38Z

+    message: 'Connect pairs',
+    context: 'Display name for an associate question type shown in the question type selector',
+  },
+  associateDescription: {


Must associate pairs of items, or something similar

Now Learners must associate pairs of items.

AlexVelezLl · 2026-09-01T13:14:34Z

Let's add what we added for choice interaction, and let's prevent the removal of the last pair, also let's disable the remove button if its the last pair.

removePair is a no-op at one pair, matching removeChoice, and the delete button is disabled there. Spec gained that case plus a max-associations block mirroring choice's max-choices one. Checked the branch's other list mutators: removeDistractor is the only sibling, and distractors are optional, so it keeps no floor.

AlexVelezLl · 2026-09-01T13:19:41Z

+
+    it('appends a third pair when the add pair button is clicked', async () => {
+      renderEditor();
+      await fireEvent.click(screen.getByRole('button', { name: tr.$tr('addPairBtn') }));


Let's use userEvent.setup() instead.

Whole editor spec is on userEvent.setup() now — 43 interactions, no fireEvent left under interactions/associate/. It was the only spec on the branch using it; the parse, validate and composable specs call the units directly.

AlexVelezLl · 2026-09-01T13:23:22Z

+    it('appends a second distractor when the add distractor button is clicked', async () => {
+      renderEditor();
+      await fireEvent.click(screen.getByRole('button', { name: tr.$tr('addDistractorBtn') }));
+      expect(
+        screen.getByRole('button', { name: tr.$tr('deleteDistractorBtn', { number: 2 }) }),
+      ).toBeInTheDocument();
+    });


This behavior is incorrect. When the "Add distractor" button is clicked, it should show a TipTapEditor below the distractors pool, and it should be saved when the Save button is clicked.

If focus is lost and tiptap is closed, let's add a small "new distractor" label so that users can come back and edit it until they hit save. Once they hit save, then we can show the add distractor button again.

Reworked. Add distractor opens a TipTap editor below the pool with a Save button; the draft lives outside state, so nothing joins the pool and nothing is emitted until Save. Closing the editor (by clicking a pair, say) leaves a small New distractor chip that reopens it with the written content still there; Save turns it into a chip and brings the Add distractor button back.

Verified in the running editor, not only in jsdom — worth it, because the first version passed its tests and was dead in the browser: the click that opens the draft finishes bubbling after TipTap has mounted its outside-click listener, so the editor closed itself immediately. Add pair had the same bug (the new pair's editor never stayed open). Both add buttons now stop the click.

AlexVelezLl · 2026-09-01T13:38:44Z

+      expect(contentsOf(parse(ASSOCIATE_XML, [decl]).pairs)).toEqual([['Capulet', 'Montague']]);
+    });
+
+    it('drops a pair naming identifiers that only exist on Object.prototype', () => {


It's not clear to me what this tests for, is because these choices are not declared on ASSOCIATE_XML?

Right — constructor/toString are not declared in ASSOCIATE_XML, and the point is that the pool lookup must not resolve them off Object.prototype (it is a Map, not a plain object). Renamed the test to say that and added the reason as a comment on both prototype cases.

AlexVelezLl · 2026-09-01T13:47:10Z

+    it('counts a distractor repeat of paired content towards match-max', () => {
+      const distractors = [{ id: 'choice_zzz00000', content: 'Antonio' }];
+      const root = parseXmlString(build({ ...baseState, distractors }).bodyXml);
+      const antonio = choicesOf(root).filter(el => el.textContent === 'Antonio');
+      expect(antonio).toHaveLength(1);
+      expect(antonio[0].getAttribute('match-max')).toBe('2');
+    });
+
+    it('reassigns the id of a later choice that reuses an id with different content', () => {
+      const pairs = [
+        baseState.pairs[0],
+        [
+          { id: 'choice_aaa11111', content: 'Capulet' },
+          { id: 'choice_ddd44444', content: 'Montague' },
+        ],
+      ];
+      const { bodyXml, responseDeclarations } = build({
+        ...baseState,
+        pairs,
+        distractors: [],
+      });
+      const [capulet] = choicesOf(parseXmlString(bodyXml)).filter(
+        el => el.textContent === 'Capulet',
+      );
+      expect(capulet.getAttribute('identifier')).toMatch(/^choice_/);
+      expect(capulet.getAttribute('identifier')).not.toBe('choice_aaa11111');
+      expect(valuesOf(parseXmlString(responseDeclarations[0]))[1]).toBe(
+        `${capulet.getAttribute('identifier')} choice_ddd44444`,
+      );
+    });


Could you make some permutations of these to test what happens if: the first appearance is repeated, then a following has the same id but different content, etc. Also, lets test that the first appearance keep the id.

Added an id normalization block with four permutations: a repeat carrying a different id (the first id wins, the second never appears), a later choice reusing an id with different content (the first keeps the id), a repeat followed by an id conflict on the same choice (match-max="2" plus a fresh id for the conflict), and a third choice repeating already-reassigned content. Each asserts the pool and the <qti-value> list.

AlexVelezLl · 2026-09-01T13:50:19Z

+  describe('TOO_FEW_PAIRS', () => {
+    it('returns error when there are no pairs at all', () => {
+      expect(errorCodes(validateAssociateInteraction(makeState({ pairs: [] })))).toContain(
+        ValidationError.TOO_FEW_PAIRS,
+      );
+    });


This should test also valid pairs, if there is a pair, but its invalid, then show the too few valid pairs error.

Added: the only pair blank, the only pair holding the same content twice, every pair invalid for a different reason, and one valid pair among invalid ones (no error).

AlexVelezLl · 2026-09-01T13:54:46Z

+    pairedCount.set(id, (pairedCount.get(id) || 0) + 1);
+  }
+
+  const distractors = pool.flatMap(({ id, content, matchMax }) =>


Could we use 'lodash/flatMap' instead?

Done, and the rest of the branch with it — 6 sites: parse.js (3), validate.js (1), the editor (2). No native flat/flatMap left in the associate plugin.

AlexVelezLl · 2026-09-01T14:06:02Z

+  function shuffled(items) {
+    const result = [...items];
+    for (let i = result.length - 1; i > 0; i--) {
+      const j = Math.floor(Math.random() * (i + 1));
+      [result[i], result[j]] = [result[j], result[i]];
+    }
+    return result;
+  }


Could we use lodash/shuffle instead?

Done — the hand-rolled Fisher–Yates is gone.

AlexVelezLl · 2026-09-15T19:38:32Z

+            <KIconButton
+              icon="close"
+              size="mini"
+              :ariaLabel="deleteDistractorBtn$({ number: index + 1 })"
+              :tooltip="deleteDistractorBtn$({ number: index + 1 })"
+              :color="$themePalette.grey.v_800"
+              @click="onRemoveDistractor(index)"
+            />


Lets use size="small" and v_700 for the color

Done — size="small", $themePalette.grey.v_700.

Searched the editor for other KIconButtons: one more, the pair delete, which your other comment puts at base/gray/400 — also now size="small".

AlexVelezLl · 2026-09-15T19:47:02Z

+          <div
+            v-if="isDraftOpen"
+            class="draft-editor item-border"
+            :style="{ borderColor: $themeTokens.fineLine }"
+          >
+            <TipTapEditor
+              :value="draft.content"
+              mode="edit"
+              format="html"
+              :minHeight="'48px'"
+              autofocus
+              :imageProcessor="EditorImageProcessor"
+              :tabindex="-1"
+              class="editor"
+              @update="setDraftContent"
+              @minimize="closeOpenTarget"
+            />
+          </div>
+          <ClickableRegion
+            v-else
+            class="chip draft-chip is-tinted"
+            :style="{ borderColor: $themeTokens.fineLine }"
+            :aria-label="editNewDistractorLabel$()"
+            @click="openDraft"
+          >
+            {{ newDistractorLabel$() }}
+          </ClickableRegion>
+          <KButton
+            primary
+            :text="saveDistractorBtn$()"
+            @click="saveDraft"
+          />
+        </div>
+        <div
+          v-else
+          @click.stop
+        >
+          <AddListItemButton
+            :label="addDistractorBtn$()"
+            @click="onAddDistractor"
+          />
+        </div>


Let's make some UX changes here so that it's consistent with other RTEs where we don't need a save button.

Let's remove the save button. When the RTE is blurred or closed, it will automatically be added to the list (if it was new) or updated. If the content is empty, then remove it from the list.

The add distractor will always be present.

With this, no "new distractor" placeholder chip should be present at any point.

The remove button should always be present on the current editable row, no matter if it's a new distractor; this will be the "cancel" button in case the user regrets it after hitting the add distractor button.

Reworked, all four points:

Save gone. Closing the editor commits: a written draft joins the pool, and an existing distractor emptied then closed leaves it. Verified in the browser that TipTap's blur-time update lands before the click that closed the editor, so the committed content is the typed content.

Add distractor is always rendered.

newDistractorLabel / editNewDistractorLabel / saveDistractorBtn deleted.

The draft row carries the same remove button as a chip, which is also how you abandon it.

New distractor, running locally — no Save, Add distractor still there, remove button on the row:

AlexVelezLl · 2026-09-15T19:48:19Z

+            />
+          </div>
+
+          <ValidationMessage


Could we set the RTE border to red if it has an error? If it's an "Answers within a pair cannot be the same" error, then both RTEs should have a red border.

Done. pairItemStyle turns a card's border red for a blank member, for both members when the pair duplicates itself, and for a member a distractor repeats (your validate.js comment).

Swept the other bordered editors in the file for the same gap: distractor chips get the same treatment via distractorStyle; the prompt already had it.

AlexVelezLl · 2026-09-15T19:53:56Z

+            <ClickableRegion
+              class="chip-region"
+              :class="{ 'is-clickable': !isDistractorOpen(index) }"
+              :suppressed="isDistractorOpen(index)"
+              :aria-label="editDistractorLabel$({ number: index + 1 })"
+              @click="openDistractor(index)"
+            >
+              <TipTapEditor
+                :value="choice.content"
+                :mode="isDistractorOpen(index) ? 'edit' : 'view'"
+                format="html"
+                :minHeight="'48px'"
+                :autofocus="isDistractorOpen(index)"
+                :imageProcessor="EditorImageProcessor"
+                :tabindex="-1"
+                class="editor"
+                @update="html => setDistractorContent(index, html)"
+                @minimize="closeOpenTarget"
+              />
+            </ClickableRegion>
+            <KIconButton
+              icon="close"
+              size="mini"
+              :ariaLabel="deleteDistractorBtn$({ number: index + 1 })"
+              :tooltip="deleteDistractorBtn$({ number: index + 1 })"
+              :color="$themePalette.grey.v_800"
+              @click="onRemoveDistractor(index)"
+            />


We need a small gap between the remove button and the RTE content.

Lets also remove the li's padding, and the border color if the distractor is in edit mode.

Both done. The gap was only missing while editing — the chip class carried gap: 8px, the editing row had no rule of its own. It now shares gap: 8px with the chip, and drops the padding and the border colour while open, since the editor draws its own.

AlexVelezLl · 2026-09-15T19:59:00Z

+              :disabled="state.pairs.length <= 1"
+              :ariaLabel="deletePairBtn$({ number: index + 1 })"
+              :tooltip="deletePairBtn$({ number: index + 1 })"
+              :color="$themePalette.grey.v_800"


Let's use base/gray/400 as per the specs and size="small".

Done — $themePalette.grey.v_400, size="small".

AlexVelezLl · 2026-09-15T20:19:42Z

+    padding: 4px 12px;
+    background-color: v-bind('$themeTokens.surface');
+    border: 1px solid;
+    border-radius: 4px;


Radius of all chips is 8px

Done — 8px on .chip and on .chip-region, the two rules that round a chip. The pool box, pair rows and pair cards are cards rather than chips, so they stay at 4px; say if the specs put those at 8px too.

AlexVelezLl · 2026-09-15T20:22:12Z

+        const byId = new Map(
+          [...flatten(state.value.pairs), ...state.value.distractors].map(c => [c.id, c]),
+        );


There may be repeated IDs that are still valid, right? This Map will squash them. However, if the same response appears in two different pairs, they will see the response twice in the chips list.

Right, the Map was wrong. It now folds by content instead of by id, which is what buildAssociateInteractionXML does — same-content choices become one qti-simple-associable-choice with a match-max. So the preview shows exactly the options delivery renders: a response used in two pairs is one chip that can be used twice, not two chips.

If you meant it should show twice, say so and I will key it by position instead — the change is one line.

AlexVelezLl · 2026-09-15T20:22:36Z

+        >
+          <li
+            v-for="choice in shuffledPool"
+            :key="choice.id"


We cannot use choice.id if id may be repeated across several choices.

Fixed — keyed by position.

Swept the branch for the same assumption. Three :key on choices: the pair cards and the distractor chips already carried -${position} / -${index}, so only the pool needed changing. Three id-keyed lookups had the defect and are now matched on content: the blank-choice error set, the paired-ids set behind the green border in showAnswers, and the pool dedup above.

AlexVelezLl · 2026-09-15T20:29:01Z

+      }
+
+      function openDraft() {
+        if (props.mode === 'edit') openTarget.value = { kind: 'draft' };


Could we have a small constant for these kinds?

Done — module-level frozen OpenTarget with PROMPT / PAIR / DISTRACTOR / DRAFT, used by every read and write of openTarget.kind. No other bare-string discriminators in the branch.

AlexVelezLl · 2026-09-15T20:31:00Z

+          } else if (state.value.pairs.length > 0) {
+            openPairItem(0, 0);
+          }
+          emit('update:interaction', workingInteraction.value);


Why? This is different from what we have on other interaction editors, right?

No change — this is the ordering editor's pattern, OrderingInteractionEditor.vue:309 and :318-321, line for line. TextEntryEditor.vue:345 gates the same way.

The gate is deliberate: a mode="view" preview must not write back to the parent, so the entry emit moved into the mode watcher and the ongoing one is gated. ChoiceInteractionEditor is the odd one out — it emits in view mode too. Covered by the does not emit update:interaction in view mode test.

Happy to align all four either way if you want one rule.

Let's always emit only in edit mode, and only if the content changed, not just because the mode changed.

Done. The mode watcher no longer emits; workingInteraction is now compared with isEqual, so an emit needs a real change to bodyXml or responseDeclarations — reopening an editor or retyping the same text stays silent.

Tests follow: mount in edit mode asserts no emit, plus a case for moving the open editor between pair items.

Searched every update:interaction emit under QTIEditor/ — four editors, three others match the pattern: ChoiceInteractionEditor.vue:382 (immediate, no mode gate), OrderingInteractionEditor.vue:309 (mode watcher), TextEntryEditor.vue:349 (immediate). All three are outside this diff, so I filed #6136 rather than widening the PR.

AlexVelezLl · 2026-09-15T21:33:46Z

+                  class="editor"
+                />
+              </div>
+            </template>


When an item within a pair has duplicated content with distractors, the error message does not appear in the pair row.

We should have another message below the other pairErrorMessage.

Fixed — the pair row now stacks every applicable message instead of showing the first match.

Audited the class rather than the line: all five codes the associate validator emits, against every control the editor reddens (prompt wrapper, pair card, distractor chip).

One gap: pairItemStyle reddened a pair card for DUPLICATE_DISTRACTOR_CONTENT, but pairErrorMessage never named it — and it returned one message where two can apply.

No gap on distractors: a blank distractor has no text to duplicate, so EMPTY_CHOICE_CONTENT and DUPLICATE_DISTRACTOR_CONTENT are mutually exclusive there.

pairErrorMessage(index) is now a pairErrorMessages computed returning an array; the row renders one ValidationMessage per entry. Two new tests: the message reaches the pair row the distractor repeats, and both messages stack on a pair that repeats itself and a distractor.

AlexVelezLl · 2026-09-15T22:14:05Z

+    ::v-deep .editor-content {
+      overflow: hidden;
+    }


Should this be a default style within the TipTapEditor instead? Does anyone benefit from having it unbounded?

Agreed — moved to EditorContentWrapper's own .editor-content rule (770fabe). Toolbars and popovers are siblings of that element, so clipping there leaves them whole.

Searched the branch for the same class — every consumer-side copy of a style that belongs to TipTapEditor. grep -rn "editor-content" frontend/ gave 7 hits across 4 files: 3 were this identical ::v-deep .editor-content { overflow: hidden } override (ordering, text entry, associate), all now deleted. The other 2 associate hits set per-chip padding, which is genuinely that card's layout, so they stay.

Kept min-width: 0 on .editor in those three: that one is about the editor being a flex item in their row, not about the editor itself.

Choice was never in the set — it bounds at .choice-content, a level above, which also clips the non-editor parts of the card. Left alone.

The five legacy exercise editors (AnswersEditor, HintsEditor, AssessmentItemEditor, AssessmentItemPreview, ResourceDrawer) pick up the bound for free; none of them reaches into .editor-content, so nothing there relied on the overflow.

AlexVelezLl · 2026-09-16T13:51:41Z

+          <!-- Keyed by position: a choice id may repeat across the pool. -->
+          <li
+            v-for="(choice, index) in shuffledPool"
+            :key="index"
+            class="chip"
+            :style="poolChipStyle(choice)"
+          >
+            <TipTapEditor
+              :value="choice.content"
+              mode="view"
+              format="html"
+              :imageProcessor="EditorImageProcessor"
+              :tabindex="-1"
+              class="editor"
+            />
+          </li>


I'm still getting these de-duplicated. For example, I have these pairs. Test 2 and Test 1 should appear two times in the pool, but they only appear once.

Fixed — the pool now renders one chip per occurrence it walks, so a choice used in two pairs shows twice, and so does a distractor carrying match-max="2". It was keying the pool into a Map by content first. The count of chips now equals the sum of the emitted match-max values.

Searched the branch for the same content-keyed collapse: three other sites key on choiceText — pairedTexts (green highlight in showAnswers), the duplicate-distractor error set, and the blank check. All three are membership tests that never decide what is rendered, so none changed. buildXML still folds equal content into one choice, which is exactly what the repeated chips represent.

Covered by a view-mode test on a fixture whose two pairs share one choice.

AlexVelezLl · 2026-09-16T13:55:22Z

+      </div>
+
+      <ol
+        class="pairs-list"


Some screen sizes show the TipTapEditor toolbar overflowing the container. Could you show the stacked view for screen sizes !windowIsLarge only when the editor of that row is opened? Let's first test how that feels, if it feels bad, we can have all of these stacked for !windowIsLarge.

Done — below windowIsLarge a pair row stacks only while its own editor is open; the rest of the rows stay side by side, and nothing stacks on a large screen. The row was previously stacked on windowIsSmall regardless of what was open, which is what left the toolbar overflowing between the two breakpoints.

Searched the other responsive layout switches in the QTI editor: four files (QuestionTypeSelector, TextEntryEditor, ChoiceInteractionEditor, QTIEditor/index.vue) branch on windowIsSmall. None of them puts two editors side by side in one row, so none has this failure mode and none changed.

Two tests cover it: stacked row follows the open editor, and no row stacks when large.

AlexVelezLl · 2026-09-16T13:58:46Z

+              :class="{ 'chip is-tinted': !isDistractorOpen(index) }"
+              :style="distractorStyle(index, choice)"
+            >
+              <ClickableRegion


Could we not set the border radius to the TipTapEditor? It makes the focus outline look too round.

Removed — the chip's 8px radius now stops at the chip. The region wrapping the editor is square, so the focus ring it draws is square too.

Checked all eight ClickableRegions in the QTI interaction editors. The other seven wrap a card whose own visible border carries the 4px radius, so their focus ring traces a border that is actually there. This one was the only region whose radius existed solely to round the ring.

AlexVelezLl · 2026-09-16T15:29:43Z

+      // Two cards side by side leave an open editor too narrow to hold its
+      // toolbar on anything but a large screen, so the row being edited stacks.
+      function isPairRowStacked(index) {
+        return !windowIsLarge.value && isPairRowOpen(index);


If windowIsSmall these should always be stacked.

Fixed in a9317b0 (pushed before this round): isPairRowStacked is now windowIsSmall || (!windowIsLarge && isPairRowOpen(index)), and the spec asserts every row stacks on a small screen, open or not.

Swept the rest of the file for the same class — windowIsSmall / windowIsLarge have exactly one consumer here, that function. The two pools wrap rather than stack, so nothing else took a breakpoint guard.

AlexVelezLl · 2026-09-16T20:50:53Z

+        <div @click.stop>
+          <AddListItemButton
+            :label="addDistractorBtn$()"
+            @click="onAddDistractor"
+          />
+        </div>


There is a small bug on here, if we added a previous distractor (i.e. we had the draft opened), then if we hit the add distractor button again, it does not focus the draft RTE again.

Fixed in 5eaac1f. The draft editor is keyed by a counter the add button bumps, so each press mounts a new one: an editor only takes focus as it mounts, and Vue was patching the one already on screen instead. Covered by two tests (draft with content, empty draft) and checked in the browser — the written draft still commits to the pool and the caret lands in the new editor.

The mock now focuses on mount and on the view → edit switch, like the real component; without that no test could see this.

Searched for the same class across the QTI editors: the draft is the only TipTapEditor held permanently at mode="edit" (1 of 9 autofocus bindings). The other eight switch modes, where TipTapEditor's own mode watcher refocuses, so none needed the key.

AlexVelezLl · 2026-09-16T21:04:47Z

+              :class="{ 'chip is-tinted': !isDistractorOpen(index) }"
+              :style="distractorStyle(index, choice)"
+            >
+              <ClickableRegion


Could we make the Clickable region cover the entire chip container instead? So that the entire chip is clickable, and not only the text content. (In that case, we should bring back the border-radius to the clickable container). On top of that, could you also add a hover background change similar to how other TipTapEditor clickable regions do?

Done in bdc67d8. ClickableRegion is now the chip itself: the remove button sits inside it behind @click.stop, the 8px radius and focus ring are back on the chip, and hover paints fineLine across the whole of it like the other regions.

Verified in the browser — a click on the chip padding opens the editor, the remove button still only removes, and the focus ring wraps the chip rather than the text.

Checked every other ClickableRegion on the branch (8 across the four interaction editors): this was the only one covering a subset of its card. The rest already wrap the whole card with their controls inside, so none changed.

AlexVelezLl

We just merged #6095. Could you rebase on top of unstable? Also we did several architectural changes there, could you please adapt these changes to the new rules?

rtibblesbot · 2026-09-21T18:57:56Z

Rebased onto unstable (e0bee94) and moved the associate plugin onto #6095's rules.

Read the #6095 diff for every rule it introduced and checked associate against each. Ten touch this plugin; all ten are applied:

AssociateInteractionDescriptor.js / AssociateInteractionEditor.vue → Descriptor.js / Editor.vue; associate/index.js deleted
descriptor extends InteractionDescriptor via super({ type, questionTypes }); its matches() override dropped, the base default being the same test
registered in descriptors.js and in the editors map, so registry.spec.js's half-registration check passes
validate.js → validation.js
stripTags → hasRichTextContent / richTextComparisonKey at all 13 call sites: 5 in validation.js, the buildXML dedup key in parse.js, 7 in Editor.vue. A pair item that is only an image or a formula now counts as content.
parseXML / getPromptHTML imported from serialization/xml
placement through Placement.BLOCK
the editor emits update:errors, so an incomplete associate question marks its card
validation debounce gone: Editor.spec.js drops the fake timers and asserts on the next tick
section labels are <h4 class="field-label">, as the other three editors' headings became

validateItem.js, resolveDescriptor and QuestionTypeSelector all read the registry, so associate reaches them without a change of its own.

Also folded this branch's review-round commits into the commits they patched: five commits now, so the push force-updates.

Editor on the rebased branch:

The card's "Incomplete" flag is what update:errors buys — here a pair item cleared to blank:

rtibblesbot · 2026-09-21T20:37:16Z

Rebased history force-pushed — the conflict with unstable is cleared and the PR now carries the six commits described above.

One fix on top of that: deleting a pair or a distractor left focus on <body>, because the press unmounts the very button it landed on. Focus now moves to the row that takes the removed one's place, or to the add button when no row does.

Grepped every call site of removePair / removeDistractor / discardDraft — six. Three are button presses that unmount their own button (onRemovePair, onRemoveDistractor, onDiscardDraft); all three changed, five tests added. The other three are the empty-on-close cleanup and leaving edit mode, where focus is already moving by the author's own action. Folded into "Add associate interaction editor and register the plugin".

Keyboard-only, after Enter on Delete pair 3:

Whole run — delete the last pair, delete down to the one remaining pair, empty the distractor pool, cancel a draft:

assoc-focus.webm

axe-core on this state: 0 violations.

Splits the single flat pool of <qti-simple-associable-choice> elements into authoring state: `pairs` from the correct response, `distractors` from the match-max capacity the correct response does not consume. buildXML re-merges them, normalizing ids so equal content shares one pool entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rtibblesbot · 2026-09-21T21:02:15Z

One section label was still a <div> — the associate editor's response pool. It is now <h4>, like the other three.

That corrects my earlier comment, which said the section labels had become <h4>. This one had not.

Swept all four interaction editors for label markup: 10 elements carrying .field-label / .section-label across choice, ordering, textEntry, associate. Nine were already <h4>; the one above was not. The two .section-sublabels stay <div> — descriptive text under a heading, not headings.

No visual change: .section-label sets margin: 0; font-size: 12px; font-weight: 600, so the UA heading defaults never apply. Computed on the live page: tag=H4 margin=0px fontSize=12px fontWeight=600. axe-core AA on the demo page: 0 violations.

Also in this push, from a self-review pass over the branch:

a blank pair member no longer keys into the correct-answer set, so an unwritten pool chip is never drawn green
isBlank drops a redundant gate on the EMPTY_CHOICE_CONTENT flag — validateAssociateInteraction pushes that error for every unfilled choice, so the gate could not change the answer

Jest over QTIEditor, TipTapEditor and channelEdit: 1690 passed.

rtibblesbot · 2026-09-21T21:20:40Z

One more case in the focus-after-removal class: deleting a distractor that is open and left blank dropped focus to <body>.

Closing the editor is what commits a distractor, and a blank one is dropped there — so the indexOf after closeOpenTarget() returned -1 and the early return skipped the focus move along with the removal. The index is now resolved before the close, the row removed only if it survived it, and focus moved either way.

Swept the branch for the same shape, an index read across closeOpenTarget(). Two sites resolve a distractor index: openDistractor already re-resolved after the close, onRemoveDistractor did not. onRemovePair holds a pair index, which closeOpenTarget() cannot shift. One site changed, one test added.

Keyboard-only on the demo page — the last distractor, opened and cleared:

Enter on that delete button: pool empty, focus ring on Add distractor.

Both deletions in one run:

blank-distractor-focus.webm

axe-core AA on this state: 0 violations. Jest over QTIEditor and TipTapEditor: 1029 passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Toolbar buttons carry `@mousedown.prevent` so a formatting press keeps the caret, which means the blur that syncs content to the parent never happens when the author finishes by pressing minimize. A parent that acts on the close then reads the content as it stood before the last edit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Registering the descriptor does not populate QUESTION_TYPE_LABELS, so QTIItemEditor gets an explicit ASSOCIATE entry — without it every associate item's view-mode header reads "Unknown type". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A formula or a long URL is one unbreakable inline node, so it paints over whatever bounds the editor. Clipping on the editor's own content wrapper bounds every embed, not just the three that hit it. `min-width: 0` on the editor root is the other half: a flex row will not shrink it below that content without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

AlexVelezLl

LGTM! Code changes look good, new intearction feels visually polished, good test coverage. I just pushed a couple of small style fixes.

rtibblesbot force-pushed the issue-6101-e6feda branch 3 times, most recently from 6e5a1f4 to 2c9fff3 Compare August 31, 2026 16:53

rtibblesbot marked this pull request as ready for review August 31, 2026 16:54

AlexVelezLl requested changes Aug 31, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch from e0394dd to 6ce2d00 Compare August 31, 2026 22:18

AlexVelezLl requested changes Sep 1, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch from 6ce2d00 to 366bf77 Compare September 1, 2026 15:12

AlexVelezLl self-assigned this Sep 8, 2026

AlexVelezLl requested changes Sep 15, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch 2 times, most recently from 26fe418 to 7ce8f7c Compare September 15, 2026 21:07

rtibblesbot mentioned this pull request Sep 15, 2026

[RTE] Emit update:interaction only when the built interaction content changes #6136

Open

5 tasks

rtibblesbot force-pushed the issue-6101-e6feda branch from 113ae56 to 89ce19e Compare September 15, 2026 21:34

AlexVelezLl requested changes Sep 15, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch 2 times, most recently from f0e8e7f to 72ed32a Compare September 15, 2026 22:07

AlexVelezLl reviewed Sep 15, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch from 770fabe to 43e9240 Compare September 15, 2026 22:24

AlexVelezLl requested changes Sep 16, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch from 43e9240 to 1fcd447 Compare September 16, 2026 14:17

AlexVelezLl requested changes Sep 16, 2026

View reviewed changes

AlexVelezLl requested changes Sep 21, 2026

View reviewed changes

rtibblesbot force-pushed the issue-6101-e6feda branch from 6188498 to add74ca Compare September 21, 2026 20:32

rtibblesbot requested a review from a team September 21, 2026 20:32

rtibblesbot force-pushed the issue-6101-e6feda branch from add74ca to 8fcd4fc Compare September 21, 2026 20:48

rtibblesbot force-pushed the issue-6101-e6feda branch from 8fcd4fc to b6adc33 Compare September 21, 2026 21:13

rtibblesbot and others added 5 commits September 21, 2026 14:26

Add associate interaction descriptor and composable

de9d9f7

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Add an associate item to the QTI demo page

179cc2a

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rtibblesbot force-pushed the issue-6101-e6feda branch from b6adc33 to f531292 Compare September 21, 2026 21:27

Fix chip min width and pair border colors

c741964

AlexVelezLl approved these changes Sep 23, 2026

View reviewed changes

AlexVelezLl merged commit 1cbdce8 into learningequality:unstable Sep 23, 2026
27 checks passed

rtibblesbot deleted the issue-6101-e6feda branch September 23, 2026 22:55

Uh oh!

Conversation

rtibblesbot commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

References

Reviewer guidance

QA steps

Evidence

View mode and Show answers

Editing and the XML round trip

Adding pairs and distractors

Committing an open editor

Deleting pairs and distractors

Validation

Switching the response type

Long content inside the card

Responsive layout

An authored associate question, saved and reloaded

Deviations from the issue spec

AI usage

⚪ Updating PR

Uh oh!

AlexVelezLl left a comment

Choose a reason for hiding this comment

Uh oh!

rtibblesbot commented Aug 31, 2026

Uh oh!

AlexVelezLl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

rtibblesbot commented Aug 31, 2026 •

edited

Loading