Close RTE dropdowns on mousedown instead of click

[akolson]

Summary

• RTE dropdown menus (font, paste, "More" overflow) now close when clicking anywhere outside them — including in the editor content area, on toolbar buttons, or outside the editor entirely

Root cause: Two separate preventDefault() calls suppress the click event inside the editor, per the HTML spec:

1. ToolbarButton.vue uses @mousedown.prevent on every toolbar button — this prevents click from firing after any toolbar button press
2. ProseMirror calls preventDefault() on mouseup when repositioning the cursor — this prevents click from firing when clicking into the editor content area

How it works: Switched the document-level handleClickOutside listener from 'click' to 'mousedown' in useDropdowns.js (font & paste dropdowns) and EditorToolbar.vue (More overflow dropdown). The mousedown event always propagates to the document regardless of any preventDefault() calls, making dropdown closing reliable for all interactions.

Screen.Recording.2026-05-20.at.11.09.34.mov

References

Fixes #5886

Reviewer guidance

• Open an exercise and click into an answer RTE
• Open the format dropdown (heading selector) — click anywhere outside it (editor text area, Bold/Italic buttons, padding, outside editor) — dropdown should close immediately
• Same for the paste dropdown and the "More" overflow dropdown (narrow the window to trigger it)
• Verify clicking inside an open dropdown does not close it
• Verify Bold, Italic, and other toolbar buttons still apply formatting normally

AI usage

Implemented with Claude Code. I reviewed the generated diff and confirmed the root cause analysis (ProseMirror mouseup preventDefault + ToolbarButton @mousedown.prevent both suppressing click events).

[rtibblesbot]

Clean fix with a thorough root cause analysis.

CI passing. No UI files changed — visual inspection not applicable.

• praise: see inline

[rtibblesbot]

praise: The root cause analysis here is excellent — tracing the missing click events to two independent preventDefault() paths (ProseMirror's mouseup and ToolbarButton's @mousedown.prevent) and choosing mousedown as the fix point is well-reasoned. The change is minimal and precise.

[rtibblesbot]

---

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

How was this generated?

Reviewed the pull request diff checking for:

• Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
• Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
• Architecture: duplicated concerns, minimal interfaces, composition over inheritance
• Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
• Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
• Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[AlexVelezLl]

Changes make sense to me, and manual QA confirms. The only small nitpick is that in the useDropdowns composable, we check all open dropdowns to confirm the click is outside, which leads to the dropdown not being closed if you are opening another dropdown (which should be)

Grabacion.de.pantalla.2026-05-21.a.la.s.10.10.34.a.m.mov

In general, I wonder whether we should use KDropdownMenu here, which already handles many of these things? cc: @marcellamaki @rtibbles. (not that we should do it in this PR to hotfixes, but in a follow-up to unstable, or in #5707 where we'll also need to make some decisions around these dropdowns)

[rtibbles]

Yes - I think that's reasonable, and having it be able to handle the specific styling/layout constraints that would be required for it in the RTE seems like good disciplining for the component!