nesquena/hermes-webui

Browser race: _autoScrollFollow can be undefined before settings initialization

Closed

#6,606 opened on Jul 29, 2026

 (1 comment) (0 reactions) (0 assignees)Python (2,386 forks)github user discovery
bughelp wantedprioritysprint-candidate

Repository metrics

Stars
 (17,368 stars)
PR merge metrics
 (Avg merge 14h 31m) (314 merged PRs in 30d)

Description

Summary

The browser golden path can throw an uncaught ReferenceError: _autoScrollFollow is not defined while rendering a user message or opening a new session after a message. This is a real page-exception class even though it is timing-sensitive and the ordinary navigation smoke often passes.

Reproduction

Against exact v0.52.76 with the private browser golden-path harness:

Running 33 items
1 failed, 32 passed
[user-message-render] uncaught JS exception(s):
  _autoScrollFollow is not defined

Against exact exp-v0.52.106:

Running 33 items
2 failed, 31 passed
[user-message-render] _autoScrollFollow is not defined
[new-session] _autoScrollFollow is not defined

The same exp-v0.52.106 tree passed the independent 23-check desktop/mobile CDP smoke from a clean browser profile, which confirms this is timing/order-sensitive rather than a permanent page brick.

Likely mechanism

Consumers in static/ui.js read the unqualified global _autoScrollFollow (for example in scroll-follow and DOM-replacement paths), while settings/bootstrap paths initialize window._autoScrollFollow asynchronously. A render path can run before the global property exists.

Fix shape

Initialize the runtime flag synchronously before any consumer can run, with the same default currently used by the settings fallback, then let settings overwrite it:

window._autoScrollFollow = true;

Keep all consumers on one explicit ownership convention (window._autoScrollFollow or a guaranteed top-level initialization), and add a browser regression test that delays /api/settings while sending/opening a session so the pre-settings render path is exercised deterministically.

Stable-channel disposition

This is present on the prior stable v0.52.76, so it is not a newly introduced regression in exp-v0.52.106. It should still be fixed because uncaught page exceptions are not acceptable browser behavior.

Contributor guide