v139 · security

Fire error event instead of throwing for CSP blocked worker

When blocked by CSP, Chromium currently throws SecurityError from constructor of Worker and SharedWorker. Spec requires CSP to be checked as part of fetch and fires error event asynchronously instead of throwing exception when script runs "new Worker(url)" or "new SharedWorker(url)". This aims to make Chromium spec conformant, which is no

concepts

  1. CSP Error Handler

    When CSP blocks a worker script from loading, Chrome now fires an error event on the Worker object instead of throwing synchronously from the constructor. Lets sites recover gracefully.

  2. Before vs After

    Side-by-side: try/catch the constructor (the v138 pattern, now silent in v139+) vs an onerror listener (spec-compliant, fires asynchronously). See which catches a blocked-script load.

  3. try/catch vs onerror Matrix

    A behaviour matrix of every CSP-blocked worker case, three runnable buttons that simulate the v138, v139, and bridged paths, and a copy-paste-ready makeWorker() helper that handles both.

  4. SharedWorker CSP Lab

    Focuses on SharedWorker specifically. Two test panels — blocked (data: URI, tests sync throw vs async error event) and allowed (Blob URL, happy path). Includes a migration guide from v138 try/catch to v139 onerror, and the universal guard pattern that handles both browser versions.

why it shipped

When the url is blocked by Content Security Policy, script code “new Worker(url)” and “new SharedWorker(url)” currently throws exception. According to spec, the CSP check is done as part of fetch which happens asynchronously and the constructor should not throw. Instead an error event should fire after the object is returned. This feature aligns Chromium behavior with spec.

references