Interaction & Record Mode

Some elements only exist after an interaction (a slide-out cart, a dropdown menu, an accordion panel, a modal). They aren't on the page at first load, so you can't click to select them. Interaction & Record mode lets you click through the live page inside the editor to reveal those elements, optionally recording the path so your edit re-appears reliably when a visitor reaches the same state.

The Record interaction button sits in the editor's top bar, next to the Inspect / Browse toggle. You can also toggle it with ⌘/Ctrl + Shift + R. While recording, the button shows a REC label so the mode is never ambiguous.

The Visual Editor with Record mode active: the record button in the top bar is highlighted red with a REC label, a red recording banner sits over the page with a 'Nothing captured yet' status and a Stop button, and the Inspector's Interaction section repeats the prompt 'Click the page to reveal the hidden element. Each click is recorded' with its own Stop button. — Recording in progress: the top-bar button turns red and the Inspector tracks each recorded click until you press Stop.

How it works

Start recording

Click Record interaction (or press ⌘⇧R). A red banner appears over the page: "Recording interaction, click the element visitors must interact with first.", and the element picker is suspended so your clicks pass straight through to the page, exactly as a visitor's would.

Click to reveal

Open the menu, expand the accordion, launch the modal: the page reacts normally, so the real dropdown or panel opens in front of you. Each click is captured as a step: the banner keeps a running count and shows the last element captured, and the clicked element pulses briefly to confirm the capture. The full step list sits in the Inspector's recorder panel.

Stop and edit

Press Stop on the banner (or Esc, or the top-bar button again). The captured steps are kept as the precondition. Select the now-visible element and edit it as usual: every change you author while steps are pending is stamped with that recorded path, shown as Applies after in the Inspector. For visitors, those edits apply only after they perform the same interaction.

You can remove the last step or clear the whole path from the recorder panel at any time before you save.

Observational replay: never synthetic clicks

This is the part that makes record mode safe to ship to real visitors. At runtime the snippet does not re-click anything on the visitor's behalf. Instead it watches the page and applies your change only once the DOM reaches the recorded state, that is, once every recorded step's element is present. The check re-runs as the page mutates, so the moment the visitor opens the same menu, your edit appears.

Firing synthetic clicks on a live visitor could submit forms, toggle carts, or trip analytics you don't own. Waiting for the visitor's own interaction is both safer and more faithful to what they actually did, and it adds no measurable weight to the snippet.

The conceptual runtime logic looks like this:

TypeScript

interface InteractionStep {  // The runtime's ranked list of selectors for the recorded element. This  // explanation never looks inside it.  selectorChain: unknown}interface GatedChange {  appliesAfter?: InteractionStep[]}// The runtime's selector resolver: it reads the DOM and returns a match or null.declare function resolveSelector(selectorChain: unknown): Element | nullfunction preconditionMet(change: GatedChange): boolean {  // No recorded path? Apply as normal.  if (!change.appliesAfter || change.appliesAfter.length === 0) return true  // Every recorded step's element must be present in the live DOM.  // The runtime only READS the DOM here; it never clicks anything.  return change.appliesAfter.every((step) => resolveSelector(step.selectorChain) !== null)}// Re-checked on every DOM mutation. When the visitor opens the menu and the// element appears, the change applies once; an idempotency guard prevents// re-applying it on later mutations.

TypeScript24 lines

Reliability for visitors

If a visitor never performs the interaction, the change simply never applies: there is nothing to break and nothing on screen that shouldn't be. When they do reach the state, the same resilient selectors that power every other edit resolve the target and apply your change. If the page re-renders the revealed element, the edit re-applies automatically, just like a normal change.

Record the clicks that actually bring the target into the DOM: opening the menu that contains it, expanding the section it lives in. Clicks that don't change what's on the page add no value as steps. During QA, reproduce the visitor's path yourself to confirm the edit appears when expected.

Selectors: how the editor builds resilient selectors for the element you reveal.
Multi-page & Global Changes: scope the same change by page URL; URL scope and an interaction path stack on one change.
Execution order: where the precondition check sits in the snippet lifecycle.