demo · v139

Before vs After

Same code, two error handling strategies. The "v138 way" wraps new Worker() in try/catch. The "v139 way" attaches an onerror listener. Click the button to fire both against a script blocked by your CSP — see which one actually catches it.

v138 strategy: try/catch the constructor

try {
  const w = new Worker("/blocked.js");
} catch (e) {
  reportToOpsTeam(e);  // never reached in v139+
}

caught:

—

v139 strategy: onerror listener

const w = new Worker("/blocked.js");
w.addEventListener("error", e => {
  reportToOpsTeam(e);  // spec-compliant
});

caught:

—

why this matters

Pre-v139 Chromium threw SecurityError synchronously from new Worker() if CSP blocked the script URL. Per the W3C spec, CSP checks happen during fetch — asynchronously — so the constructor should return an inert Worker and then fire an error event. Firefox and Safari have always done this; Chromium aligning means cross-browser sites no longer need both code paths.

see also