jkleinsc

#55739: fix: set up DevTools extension API before the extension page runs

Merged
Created: Nov 11, 2026, 3:29:08 PM
Merged: Nov 12, 2026, 10:29:01 AM
4 comments
Target: main

Description of Change

Fixes #55394.

chrome extensions > devtools extensions > loads a devtools extension flaked on linux-x64 because InspectableWebContents::DidFinishNavigation() injected the DevTools extension API into the extension frame with ExecuteJavaScriptForTests(). That races the extension page's own scripts; when the page wins, chrome.devtools is undefined (Cannot read properties of undefined (reading 'panels')), the devtools_page never creates its panel, and the test times out.

This moves the setup to ReadyToCommitNavigation() and hands the script to Blink via content::DevToolsFrontendHost::SetupExtensionsAPI(), matching Chrome's DevToolsUIBindings. Blink then runs it from DevToolsFrontendImpl::DidClearWindowObject(), before any page script. (The old comment said SetupExtensionsAPI seemed to be a no-op; that was because it was being called after commit, once the window object had already been cleared.) The stale "var chrome" rewrite is dropped too: the frontend now emits const chrome = window.chrome || {}, so it no longer matched anything.

Spec changes:

  • spec/extensions.spec.ts now runs with { retry: 0 }.
  • The devtools extension test awaits loadExtension() before opening DevTools.

Verified locally on macOS: all extensions.spec.ts tests pass on the first attempt with retries disabled, and loads a devtools extension passed 15/15 isolated runs.

Checklist

🤖 Generated with Claude Code

Notes: Fixed a race where a DevTools extension's devtools_page could run before chrome.devtools was available.

Backports

44-x-y
Pending
Waiting for a manual backport
45-x-y
Pending
Waiting for a manual backport
46-x-y
Merged
PR Number
#55762
Merged At
Nov 12, 2026, 11:56:39 AM
Released In
Not yet
Release Date
Not yet

Semver Impact

Major
Breaking changes
Minor
New features
Patch
Bug fixes
None
Docs, tests, etc.

Semantic Versioning helps users understand the impact of updates:

  • Major (X.y.z): Breaking changes that may require code modifications
  • Minor (x.Y.z): New features that maintain backward compatibility
  • Patch (x.y.Z): Bug fixes that don't change the API
  • None: Changes that don't affect using facing parts of Electron