Minor Changes

• #3741 c0da89493d819abe2120c8a1340b1a4048b11247 Thanks @jodeleeuw! - Add the jsPsych.adaptive module with createStaircase() and createInterleaved() for adaptive staircase procedures (n-up/m-down rules, unequal and shrinking step sizes, bounds, stopping rules including discontinue and ceiling rules for span tasks, and interleaved tracks that use the seeded random number generator). Procedures share a common AdaptiveProcedure interface, so later procedures (such as QUEST) can be added and interleaved with staircases without changing the existing API.

Patch Changes

• #3730 4a94750ace33e619f65564f0957ae3986fdca939 Thanks @SohamXYZDev! - Changes to trial.data made in on_start are now saved in the trial's data (#3727). This also changes when functions in a trial's data parameter are evaluated: they are now called right before the trial starts, like other dynamic parameters, so on_start sees their values. Before, they were called after the trial ended, when the data was saved. Values that depend on the response should be added in on_finish.

• #3722 f764a2b5117528d7d2b211edba48b7dd59a0e7e5 Thanks @rmz-oz! - save_trial_parameters now works with the parameters that are available in all plugins, such as css_classes and post_trial_gap. Before, they were ignored with a "Non-existent parameter" warning and their values were not saved to the data.

  Functions passed to these parameters are now called when the trial starts, before on_start, so on_start and the plugin see their values. Before, they were called when the parameter was used; for example, a function passed to post_trial_gap was called after the trial ended.

Minor Changes

• #3718 dfdfb5ef09cc30fa43aec6af63a157093d52430f Thanks @jodeleeuw! - New extension for sending data to DataPipe. Registering it in initJsPsych is the whole integration: it stages each trial as it finishes, so an abandoned session can be recovered, and submits the complete dataset when the experiment ends — including after abortExperiment(), which a save trial never reaches.

Minor Changes

• #3719 7a2bee7ce54e16eb3ab3d060767ee928cd4a6078 Thanks @jodeleeuw! - Require Node 20 or later. Node 18 reached end of life in April 2025, and parts of the ecosystem have moved past it — the Firebase v12 SDK, for one, declares node >= 20 throughout, so a package depending on it could not be installed in a repository that still claimed Node 18 support.

  A minor rather than a major: raising a runtime floor is breaking in the strict sense, but @jspsych/config is a build-time dependency of jsPsych's own packages and never reaches an experiment, so a major here would churn every package in the monorepo for an advisory field.

Minor Changes

• #3708 a69d7ad7aca8a0b0d97c5893ab09a368bd9dda25 Thanks @jodeleeuw! - Added a CSS style to jspsych.css that renders <kbd> elements (or any element with class "jspsych-key") as a visual keycap. Wrapping a key name in <kbd> inside a trial renders it as a keycap, e.g. Press <kbd>space</kbd> to continue.

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.

Minor Changes

• #3707 f14e9784fd49f36ac9051c6d5cdbd7223f391a9b Thanks @jodeleeuw! - The keyDown() and keyUp() helpers accept an optional second argument that sets the code property (the physical key) on the dispatched KeyboardEvent, in addition to the existing key argument. A new windowBlur() helper dispatches a blur event on window and flushes pending promises, for testing behavior that depends on the page losing focus.

Minor Changes

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.

Minor Changes

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.

Minor Changes

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.

Minor Changes

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.

Minor Changes

• #3707 a9f454ee58fda69173dbaa1ecfa4aa7797920031 Thanks @jodeleeuw! - Added the ability to measure how long a response key was held down. The getKeyboardResponse() method of the keyboard plugin API gains an optional wait_for_key_release option; when true, the callback_function fires at key release instead of key press, and its payload includes an rt_key_duration field (the press-to-release duration in milliseconds) alongside the usual key and rt. The five *-keyboard-response plugins (html, image, audio, video, canvas) expose a matching wait_for_key_release trial parameter (default false) and record the new rt_key_duration data field. The release is matched to the press by the physical key (KeyboardEvent.code), so changing the shift state while holding a key (which changes e.key) does not prevent the release from being detected, and the key reported to the callback is always the value from the original keydown event. If the window loses focus while a key is held (a blur event), the browser stops delivering the eventual keyup; in that case the pending release is resolved with rt_key_duration: null (the hold duration cannot be measured) and the held-key state is cleared so it does not leak into the next trial.