What Galileo is working on this week

Galileo is moving on three fronts right now: web compatibility, extensions, and the browser shell. The short version is that more browser behaviour is being filled in and tested, while the product around the engine is becoming less like a development harness. That is progress, but it is not a release.

Web compatibility, one behaviour at a time

The current compatibility work covers a broad set of small but visible browser behaviours: dialogs and close handling, forms and focus, drag-and-drop, native file selection, stream and fetch timing, and layout details such as clipped text.

Some of this work reaches outside the page itself. File selection and file drops, for example, have platform-specific paths on Linux, Windows, and Android. Each change needs a focused contract and a reproducible check; a method existing in the code is not enough to call it compatible.

The active batch is still on a development branch. It has not been merged and qualified as one release unit, so we are treating it as work in progress rather than a new compatibility score.

Extensions need useful APIs and firm boundaries

The second large workstream is WebExtensions. Recent work includes permission-aware network requests, request-blocking behaviour, package asset handling, navigation and context filters, native messaging discovery, and a wider set of extension events.

The important part is not simply exposing more APIs. Host access, content settings, package review, and failure behaviour must remain browser-controlled. An extension should only receive the access a person has reviewed, and a failed or malformed package should not quietly gain a broader path through the browser.

The public Galileo Extensions catalog now carries reviewed packages with fixed digests, including a uBlock Origin compatibility package. Packages remain disabled until their permissions are reviewed and they are explicitly enabled. uBlock Origin is still a compatibility preview, not a claim of full Firefox or Chrome parity.

The shell is becoming a browser

The main branch has also received practical product work: Android favourites and menu polish, media enablement, harder Servo startup paths, extension manifest localisation, and more accurate tab queries. These are the details that turn engine capability into something a person can actually use.

Galileo still derives its engine work from Servo. We want generally useful engine fixes to remain suitable for upstream contribution, while Galileo-specific product work stays behind a clear browser boundary.

What has not changed

There is no public Galileo Browser release yet. The latest main-branch automation snapshot is not green, and the two large active workstreams still need review, integration, and wider qualification. We will not use a commit count as a substitute for passing tests.

The next meaningful gate is straightforward: restore a trustworthy green workflow, review and merge bounded slices, run the focused Web Platform Tests and browser journeys attached to them, and publish both the passes and the remaining failures.

That is where Galileo stands this week: substantial engineering movement, clearer browser boundaries, and evidence still being assembled before the next public claim.