Repository navigation
Linux: /evaluate that WRITES document.cookie times out (reads work) — WebKitGTK #7
Description
Activity
Refined: NOT deterministic — it reproduces under contention, not on a healthy daemon
Follow-up discrimination on a fresh container (v1.8.1, same WebKitGTK stack), all instant:
- control plain eval → ok
- cookie write only, no read (
(function(){document.cookie="c=1"; return "written"})()) → ok — the assignment itself never blocks - write then read in the same task (the original "failing pattern") → ok —
c=1; d=1returned fine - first evaluate on a freshly-navigated session = cookie write → ok
So the original characterization ("every cookie-WRITE evaluate times out") was wrong — it was measured on a container whose Xvfb was actively dying (it crashed with
cannot open displayminutes later), plus one CI run on a contended runner. The refined picture:A
document.cookiewrite stalls past the 20 s evaluate timeout when the web-process/event-loop is under heavy contention (software rendering on a dying/slow X server, or a saturated CI disk — the write path flushes the cookie jar synchronously). Plain evaluates never touch disk and stay fast in the same conditions — which is why the pattern looked content-dependent.Candidate mitigations, in order of preference:
- Make the eval timeout configurable (
NAVETTE_EVAL_TIMEOUT_SECS, default 20) — agents on slow VMs get to choose slow-success over fast-false-timeout. - Keep 20 s but retry once at 45 s on timeout (costs up to 65 s worst case).
- Nothing — document that cookie writes prefer
/sessions/loadon weak environments.
Not urgent: on healthy daemons (the normal case) everything passes.
- added a commit that references this issue
on Oct 8, 2026 Closing as upstream-wontfix, documented. Reproduced cleanly today (arm64 container, WebKitGTK + xvfb):
document.cookie = …via evaluate hangs past 15 s on a REAL http origin (reads fine) — a WebKitGTK behavior when injected JS writes cookies against the ephemeral data store. The supported path isPOST /sessions/load(WKWebsiteDataStore-level, works everywhere — every recipe in this repo uses it); evaluate stays read-only for cookies on Linux/macOS parity where it works. Reopen if an upstream WebKitGTK release changes this.
Found while building the session-isolation CI probe (ceef773) and reproduced independently — on WebKitGTK, any
/evaluatewhose script writesdocument.cookiehangs to its 20 s timeout, while read-only evaluates on the same session return in milliseconds. Deterministic across environments:document.cookie="navette_iso=42; path=/"; document.cookie→evaluate timeout(3/3 attempts, two sessions);JSON.stringify(1+1),location.hostname,document.cookiereads → instant.Repro
What it is NOT
Suspects
eval_jswraps the expression and POSTs the result through the ipc shim (window.ipc.postMessage). The hang means the script itself never reaches the postMessage — i.e. thedocument.cookie = …assignment blocks inside WebKitGTK on this path. Possibly an interaction between the synchronous cookie-manager write in the web process and the ipc/script context (both WKGTK quirks we've met before: the NSNumberdescriptionstringification, the with_callback-returns-empty transport).Workarounds in place
The CI isolation probe uses
state_import/state_export(backend cookie APIs) instead of page JS — immune to this. Agents on Linux hitting it can use/sessions/loadfor cookie writes too.Worth checking whether a
setTimeout(...,0)split (assign, then postMessage in a task) unblocks it — that would also pin down whether the assignment itself or the same-task postMessage is the blocking part.