script-utils/linters/eslint-rules/no-untrusted-input-events
ESLint rule: no-untrusted-input-events
Reports an integration test that drives the UI by dispatching an INPUT event — el.dispatchEvent(new KeyboardEvent(...)), new MouseEvent(...), and friends.
Such an event is untrusted (isTrusted === false), and Obsidian and CodeMirror routinely gate on exactly that: Obsidian 1.13’s markdown viewport menu opens from a listener guarded by e.isTrusted, so a dispatched contextmenu reaches nothing. The test then exercises NOTHING while still passing whatever weaker assertion it makes — a false-confidence failure, not a flake.
The trusted alternatives — pressKey, clickElement, clickMouse, hoverElement, typeIntoEditor — are seeded into the evalInObsidian callback’s lib bag, and are also importable from obsidian-dev-utils/obsidian/desktop-trusted-input.
NOTIFICATION events are deliberately NOT reported. new Event('input') after setting an element’s .value is telling the app about a change rather than pretending to be a user, and nothing gates it on isTrusted.
Not every dispatch is wrong, so the rule is meant to be disabled — with a reason — at the sites that have one: a drag sequence, which sendInputEvent cannot express at all; an Android file, which has no window.electron to reach the helpers through; and a listener that is the plugin’s own and checks nothing but the key. require-description makes that reason mandatory, which is the point: the rule turns an invisible assumption into a written one.
Variables
Section titled “Variables”| Variable | Description |
|---|---|
| MESSAGE_ID | Message ID reported when an integration test drives the UI with a dispatched input event. |
| noUntrustedInputEvents | ESLint rule disallowing untrusted input events in integration tests, where they can silently exercise nothing. |