Tests / worker lifecycle
Worker startup
Check whether fresh workers respond within 250 ms, respond late, or remain silent for five seconds.
Keep this tab visible and close DevTools for the baseline. Run in three fresh browser processes per condition. Nothing runs until you press Start; export each capture before reloading or starting again.
Loading diagnostic… Reload if this message remains.
Results
No capture yet. A readiness timeout alone does not identify its cause.
| Case | Ready ≤250 ms | Ready later | No ready by cutoff | Errors / unsupported / stopped | 4 pongs ≤100 ms each |
|---|
Counts cover observed attempts. Late readiness and silence are separate. JSON retains each attempt, actual timer delays, messaging rounds, errors and focus/visibility changes. No result means “automation detected.”
How to confirm the issue
- Collect a native Chrome baseline and a normal product capture using the same page and matching fingerprint. Record the real host, executable versions and architecture separately from browser claims.
- Repeat from three fresh processes with a visible tab, unchanged settings and no DevTools. Keep the exports even when all cases pass.
- If the 250 ms case fails, inspect the extended Blob case. Late replies suggest a deadline/startup delay; silence for five seconds shows a longer failure within that observation window. Errors or CSP violations point to a different failure path.
- Compare main-thread MessageChannel controls and the 50 ms timer delays. Large delays, hidden tabs or lost focus weaken the timing comparison. Same-origin-only delays can include script fetching and caching.
- Have the controller owner repeat with
waitForDebuggerOnStart: falsewhile keeping other settings fixed, or with the controller detached. Label and export that separate capture. Do not open DevTools to alter the baseline midway.
Evidence needed to attribute the failure to CDP
Log Target.attachedToTarget with the target ID, worker name/URL, session ID and waitingForDebugger; record plugin start/end/error and the matching Runtime.runIfWaitingForDebugger command and response. Correlate with the exported worker names, UTC timestamps and attempt offsets.
Disabling startup pauses may also change initialization and spoofing. An improvement is evidence of controller involvement, not proof of one code defect. A missing or delayed resume on the matching session is the stronger confirmation.
Method and limits
Eight sequential classic workers use one Blob URL and the exact readiness/pong payload used by timing.worker-startup. The cutoff case terminates silent workers at its 250 ms timer; extended cases allow 5000 ms. Each ready worker receives up to four sequential pings with 100 ms deadlines. The same-origin case serves identical payload bytes from this application.
All durations use the parent clock. Actual callbacks can run later than their requested deadlines. The 50 ms timer adds a small observation load; worker names support controller tracing. This page omits the product signal’s overall three-second budget and runs no other collectors. It is a diagnostic, not an exact replay of a full capture. Fixed case order can warm caches; select one case in fresh processes to investigate order effects.
These checks do not cover nested, shared, module or service workers. Report captures that disagree rather than generalizing to every worker.