Resizing the viewport restarts an in-progress interactive instrument

[CMonnin]

Reported downstream in DouglasNeuroInformatics/CPPQ#103.

What happens

Resizing the Google Chrome window while an interactive instrument is in progress restarts the task, returning the participant to the instructions page. Observed on TMB_VISUAL_PA_STUDY and TMB_MATRIX_REASONING.

Why this is a data-integrity bug, not a cosmetic one

For TMB_VISUAL_PA_STUDY a restart means the participant sees the image pairs a second time. That instrument is the study phase of a paired-associates memory test — a second exposure invalidates the subsequent recall score, and nothing in the recorded data indicates it happened. The affected record looks like a normal, valid one.

So the failure is silent: the score is wrong and nothing flags it. Same shape of problem for any timed or exposure-limited task.

Evidence it's host-side, not in the tasks

Neither task source contains any resize or viewport handling — no resize listener, no ResizeObserver, no window.innerWidth / innerHeight / clientWidth reads, no matchMedia, no orientationchange:

$ grep -in "resize\|innerWidth\|innerHeight\|clientWidth\|matchMedia\|orientationchange\|ResizeObserver" \
    lib/interactive/TMB_VISUAL_PA_STUDY/index.ts lib/interactive/TMB_MATRIX_REASONING/index.ts
(no matches)

(in DouglasNeuroInformatics/ODC_instruments, 371 and 569 lines respectively)

The tasks have no way to react to a resize themselves, so the remount is coming from the interactive-instrument host — something in the render path keyed on viewport dimensions, remounting the task component on a size change.

Expected behaviour

Resizing the viewport must not remount, restart, or reset an in-progress interactive instrument. The task should keep its state across viewport changes.

Questions

• Can the remount be confirmed in the interactive instrument host? (@joshunrau — this was your read on CPPQ#103 too)
• Is the state loss recoverable, or does it need the host to stop remounting in the first place?
• Can already-affected sessions be identified retrospectively? If a restart leaves any trace at all, existing CPPQ records may need auditing.

🤖 Generated with Claude Code