Address review: `updateHistory` re-serialized the whole query string,
so the `password` parameter was written back into the address bar and
into the browser history on every pan and zoom. The password is already
copied into the internal `url` variable at startup, so requests keep
working without it in `window.location`. This matches
`programs/server/schema.html` and `programs/server/play.html`, which
also do not keep the password in generated URLs.
The initial view was reset to the top-left corner of the image whenever
the URL contained any query string, such as `?user=play`, because the
position was read even if `x`, `y` and `zoom` were not present. Now the
view is moved only if the position is specified.
`updateHistory` rebuilt the query string from scratch, so the `host`,
`user` and `password` parameters were dropped on the first move, and all
subsequent requests were sent without authentication. Now the position
parameters are updated in place, keeping everything else.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The "user" input on `play.html` and on the other web pages
(`dashboard.html`, `jemalloc.html`, `merges.html`, `binary.html`,
`webterminal.html`) previously came pre-filled with the literal text
`default`. Replace that with an empty value and a `user` placeholder
hint. When the value is empty, the page does not send a `user=` query
parameter (or, in the WebTerminal protocol, omits the `user` field
from the auth JSON), letting the server fall back to its configured
default user — which is not necessarily named `default`.
For the WebTerminal, `parseAuthMessage` now treats the `user` field as
optional: when omitted or empty, the caller-provided default is
preserved. The call site seeds it with `default`, mirroring the HTTP
fallback in `authenticateUserByHTTP`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Alexey Milovidov