{"id":171,"date":"2026-09-07T05:52:51","date_gmt":"2026-09-07T05:52:51","guid":{"rendered":"https:\/\/blogs.igalia.com\/mshin\/?p=171"},"modified":"2026-09-07T05:52:51","modified_gmt":"2026-09-07T05:52:51","slug":"extension-migration-progress-update-part-2","status":"publish","type":"post","link":"https:\/\/blogs.igalia.com\/mshin\/2026\/09\/07\/extension-migration-progress-update-part-2\/","title":{"rendered":"Extension Migration Progress Update \u2013 Part 2"},"content":{"rendered":"\n

This post walks through the process of bringing back an extension-focused \/\/extensions\/shell<\/code> in Chromium and enabling the \u201cAdd to Chrome\u201d<\/strong> button on the Chrome Web Store.<\/p>\n\n\n\n

If you haven\u2019t read it yet, I recommend starting with Extension Migration Progress Update \u2013 Part 1<\/a><\/strong>, where I described the initial stage of migrating extension installation formats and APIs out of the \/\/chrome<\/code> layer.<\/p>\n\n\n\n

After migrating the extension installation formats \u2014 CRX, ZIP, and Unpacked \u2014 into the \/\/extensions<\/code> layer, the next natural step was to enable embedders to install extensions directly from the Chrome Web Store.<\/p>\n\n\n\n

To achieve this, the Web Store Private APIs<\/strong> were an essential piece of the puzzle.<\/p>\n\n\n\n

Migrating Web Store Private APIs<\/h2>\n\n\n\n

The Web Store Private APIs had a relatively large dependency on \/\/chrome<\/code>. We started by migrating the relevant files and gradually replacing Chrome-specific dependencies with alternative implementations where necessary.<\/p>\n\n\n\n

In some cases, this meant introducing new interfaces, while in others it meant moving code to a more appropriate layer.<\/p>\n\n\n\n

After working through these dependencies, the final changes were eventually landed upstream: Chromium CL \u2013 Web Store Private API migration<\/a>.<\/p>\n\n\n\n

The changes are included in M152<\/strong>.<\/p>\n\n\n\n

However, after this migration was completed, we encountered an unexpected obstacle.<\/p>\n\n\n\n

Where did extensions\/shell<\/code> go?<\/h2>\n\n\n\n

Chromium originally had a lightweight embedder called \/\/extensions\/shell<\/code>, previously built as the app_shell<\/code> target.<\/p>\n\n\n\n

The idea was simple: provide an environment where extensions could be installed and run without bringing up the entire Chrome browser.<\/p>\n\n\n\n

However, the shell had originally been created about a decade ago for a different purpose. It was intended to provide an independent environment for ChromeOS platform applications without requiring the full Chrome browser.<\/p>\n\n\n\n

Platform apps were eventually deprecated, and the shell was later repurposed primarily as a lightweight environment for extension browser tests.<\/p>\n\n\n\n

Over time, the extension browser tests were moved into the \/\/chrome<\/code> layer. The shell was no longer used by any real product, and maintaining it became technical debt. As a result, app_shell<\/code> was eventually removed upstream.<\/p>\n\n\n\n

Why were the browser tests moved from \/\/extensions<\/code> to \/\/chrome<\/code>?<\/h3>\n\n\n\n

I asked an Extension owner about the reasoning behind this change.<\/p>\n\n\n\n

The key point was that the old shell-based browser tests did not provide a sufficiently realistic environment for testing extensions.<\/p>\n\n\n\n

There were two major problems.<\/p>\n\n\n\n

First, many extension APIs delegate part of their implementation to the embedder through interfaces such as ExtensionsApiClient<\/code>. Testing only the \/\/extensions<\/code> implementation with the shell meant that the actual embedding logic was not exercised. Bugs in the delegated implementation could therefore go unnoticed.<\/p>\n\n\n\n

Second, extensions depend on much more than the \/\/extensions<\/code> layer itself. UI, networking, rendering, process management, and other browser functionality all affect how extensions behave. The \/\/chrome<\/code> layer provides an important part of that environment.<\/p>\n\n\n\n

Therefore, the upstream direction was to move extension browser tests into the real Chrome browser environment rather than maintaining a separate shell.<\/p>\n\n\n\n

That reasoning makes sense for testing<\/strong>.<\/p>\n\n\n\n

In fact, we agreed that bringing the old shell back simply as a test environment would not be the right approach.<\/p>\n\n\n\n

<\/p>\n\n\n\n

But I had a different question:<\/p>\n\n\n\n

\n

What if we use a lightweight shell not as a test environment, but as a reference implementation and a demo environment for embedders?<\/p>\n<\/blockquote>\n\n\n\n

The answer was that Chromium currently does not plan to maintain such an embedder. The concern is that a simplified shell could itself become an inaccurate reference implementation. If its behavior diverged from the real Chrome integration, it could create more confusion rather than provide useful guidance.<\/p>\n\n\n\n

The suggested direction was instead to use extension-based Web Platform Tests (WPT)<\/strong> to provide consistency, while considering actual browsers as the reference implementations.<\/p>\n\n\n\n

That approach makes sense from the upstream perspective.<\/p>\n\n\n\n

However, for our migration work, we still needed something slightly different.<\/p>\n\n\n\n

We needed a small, working environment where we could demonstrate that extensions can actually be supported outside of the \/\/chrome<\/code> layer<\/strong>.<\/p>\n\n\n\n

So we decided to bring back an extension-focused shell \u2014 not as an upstream testing framework, but as a practical environment for integration and demonstration.<\/p>\n\n\n\n

Although this shell is not part of upstream Chromium, we are currently maintaining the implementation internally in the Igalia repository, with plans to open-source it in the future. It serves as a lightweight environment for demonstrating and validating Extension support outside of the \/\/chrome layer, rather than as a replacement for Chromium’s browser tests or an upstream reference implementation.<\/p>\n\n\n\n

Rebuilding the Extension Shell<\/h2>\n\n\n\n

The first step was to establish the basic structure of the shell.<\/p>\n\n\n\n

1. Building the skeleton<\/h3>\n\n\n\n

We created a custom ShellBrowserContext<\/code> directly derived from content::BrowserContext<\/code>, bootstrapped the Views environment, and added a simple placeholder window.<\/p>\n\n\n\n

On top of that, we connected the extension system through:<\/p>\n\n\n\n