Electron 45 lands Chromium 156, Node 24.22 and V8 15.6 — and every breaking change sits on a sandbox boundary

Three breaking changes: sandboxed preload scripts lose events/timers/url and the Buffer globals, Workers created inside iframes no longer inherit Node integration, and extension pages stop receiving preload scripts unconditionally.

Electron 45.0.0 shipped on October 21, moving to Chromium 156.0.8078.48 / Node 24.22.0 / V8 15.6. A stack bump is not usually worth a post, but this release’s breaking changes are unusually focused: all of them sit on sandbox and injection boundaries.

One: sandboxed preload scripts lose six things

The change comes from #54048, titled “reduce sandboxed renderer startup work for preload scripts that do not use Buffer”:

  • remove the events, timers and url modules from sandboxed preload scripts;
  • remove the Buffer, setImmediate and clearImmediate globals;
  • sandboxed renderers without a preload script start faster;
  • sandboxed preload scripts start faster — unless webviewTag is enabled, Electron no longer evaluates its own JS bundle in sandboxed renderers.

The logic is plain: sandboxed preload scripts used to preload a small Node compatibility layer so older code kept working. That layer was itself the startup cost. Now it is gone by default; polyfill it if you need it.

// previously available inside a sandboxed preload
const { EventEmitter } = require('events');
const buf = Buffer.from('hello');

// after 45: bring your own
// require a polyfill at the top of preload.js, or pass capabilities over contextBridge

The Electron v45.0.0 release page

This genuinely breaks older apps: some preload scripts will throw Cannot find module 'events' after the upgrade. And a broken preload usually looks like “the page renders fine but no IPC works” — harder to diagnose than a blank window.

Two: Workers no longer inherit Node from the process

The second change is more interesting:

With nodeIntegrationInWorker: true, a Worker created from an <iframe> used to get Node.js integration even though the iframe itself had none.

The criterion moves from “is it enabled in this process” to “does the frame that created it have it”. Now only Workers created by the main frame — or by any frame when nodeIntegrationInSubFrames is enabled — get Node.

This is a narrowing of privilege, in the right direction: an iframe is an isolation boundary, and inheriting capabilities merely by sharing a process defeats it.

Three: extension pages no longer get preloads unconditionally

Also a narrowing:

A chrome-extension:// document used to receive the window’s preload script (and session preloads) wherever it was embedded. Now only when it is a top-level frame or hosted inside the DevTools front-end (devtools_page or panel); an extension frame embedded in an ordinary page is treated like any other subframe and follows nodeIntegrationInSubFrames.

For apps that load third-party extensions, this matters: an extension page used to be a door into the main world’s privileges.

Electron’s sandbox docs: what a preload script can reach

Two smaller changes

  • chromeMediaSource: 'desktop' now only accepts screen and window source ids from desktopCapturer.getSources. Passing a WebContents id fails with Invalid state. To capture a WebContents, use chromeMediaSource: 'tab' with webContents.getMediaSourceId(), or setDisplayMediaRequestHandler.
  • The experimental contentTracing.enableHeapProfiling() API is removed. Only profiling tools used it, so the blast radius is small — but those fail to compile.

Upgrade advice

My read: 45 is worth upgrading to, but schedule it. Because:

  1. Chromium 156’s security fixes are non-negotiable, especially for products that embed web content;
  2. All three breaking changes require code edits — polyfills for sandboxed preloads, Worker permission logic, assumptions about extension page injection;
  3. The preload failure mode is silent (page fine, IPC dead), so you need a regression test that opens the app and clicks something requiring IPC.

My order: upgrade on a branch, walk every preload load path, then audit any combination of webviewTag and nodeIntegrationInSubFrames. The risk in a release like this is not the new features; it is the “happened to work” assumptions in old code.

Electron’s breaking changes doc

On cadence: 45 is stable and 46 already has alpha.1 (October 23). Electron holds an eight-week major cadence, so upgrading needs a fixed time budget — skip it and you face three majors’ worth of changes at once in six months.

← Back to all posts

Comments

…