fix(android): scope the editor globals and keep site pages out of the editor frame

[dcalhoun]

What?

Mitigate exposing editor globals to non-editor pages.

Why?

The editor globals contain configuration that should only be accessible to the editor HTML page and its scripts.

How?

• Remove logic allowing REST API endpoints to load directly in the WebView, fetch of these URLs works without this
• Narrow the asset path detection to matching schemes
• Disable editor globals and upload server for non-editor URLs

Testing Instructions

Manual testing on a device against wp-env, in both configurations, using chrome://inspect to reach the editor WebView's console:

1. Production path — with GUTENBERG_EDITOR_URL unset in android/local.properties, open a post. window.GBKit is defined.
2. Edit, save, upload an image, and open the inserter's Patterns tab. All work; the API is reached by fetch, and pattern previews by blob: frames, neither of which the policy gates.
3. In the console, each of these opens in the OS browser instead of replacing the editor:
   • window.top.location.href = location.origin + '/wp-json/wp/v2/posts'
   • window.top.location.href = location.origin + '/?rest_route=/wp/v2/posts&rest_route=' (on trunk, the themed front page)
   • On an https site (not wp-env), window.top.location.href = 'http://' + location.host + '/wp-json/wp/v2/posts'
4. Add a temporary android/app/src/main/assets/probe.html, rebuild, and navigate to location.origin + '/assets/probe.html'. It loads, and in its console window.GBKit is undefined (on trunk, the object).
5. Dev server — set GUTENBERG_EDITOR_URL=http://10.0.2.2:5173/, run make dev-server, open a post. window.GBKit is defined.
6. With the dev server still configured, navigate to http://10.0.2.2:8888/ — the wp-env site on another port of the same host. It opens in the OS browser rather than being taken for the dev server.

Accessibility Testing Instructions

N/A, no user-facing changes.

Screenshots or screencast

N/A, no user-facing changes.

---

AI-generated details

Problem

onPageStarted received the URL of the page that had begun loading and discarded it, so window.GBKit — the site credential and the local upload server's port and token — was injected into whatever loaded in the main frame. Separately, the navigation policy admitted the REST API into the main frame, recognizing it by substring: any path containing /wp-json/ or any query containing rest_route=.

Impact

Since #181 the Android editor loads from the site's own origin, so the pages those substrings admit are ordinary pages that WordPress serves with the site's theme, plugins and third-party scripts — rendered inside the editor's frame, and handed the credential in a readable global. /blog/wp-json/a-post and /a-page/?utm_campaign=rest_route=x both qualify. iOS is unaffected: it blocks all main-frame navigation outside the editor.

Both behaviors reproduce on trunk; the Robolectric cases added here fail against it.

Mechanism

• onEditorPageStarted takes the loaded URL and advertises the globals, and starts the upload server, only for the editor document. Readiness still resets for any page, since navigating away leaves the editor unusable either way. The dev server is matched with fix(android): match the dev server by host and port #729's isDevServerUrl, by authority, so a local site on another port of the same host is not mistaken for the editor.
• The main frame no longer admits the REST API, site or WordPress.com. The editor reaches it by fetch, which never passes through shouldOverrideUrlLoading, so the allowlist only ever admitted navigations — and matching WordPress's URL parsing proved open-ended: a duplicate or empty rest_route, or http on an https site, still let a page replace the editor.
• The editor's assets match only the scheme the asset loader serves; the same path over the other scheme reaches the site over the network. The editor document itself is matched by its exact index path, since the asset loader also serves the host app's other bundled pages.
• The new cases live in GutenbergViewNavigationTest rather than GutenbergViewTest, which Detekt flags as LargeClass once they are added.

Testing

Unit and lint, both green, and each commit passes on its own:

make test-android-library-unit
make lint-android

Manual testing on a device against wp-env, in both configurations, using chrome://inspect to reach the editor WebView's console:

1. Production path — with GUTENBERG_EDITOR_URL unset in android/local.properties, open a post. window.GBKit is defined.
2. Edit, save, upload an image, and open the inserter's Patterns tab. All work; the API is reached by fetch, and pattern previews by blob: frames, neither of which the policy gates.
3. In the console, each of these opens in the OS browser instead of replacing the editor:
   • window.top.location.href = location.origin + '/wp-json/wp/v2/posts'
   • window.top.location.href = location.origin + '/?rest_route=/wp/v2/posts&rest_route=' (on trunk, the themed front page)
   • On an https site, window.top.location.href = 'http://' + location.host + '/wp-json/wp/v2/posts'
4. Add a temporary android/app/src/main/assets/probe.html, rebuild, and navigate to location.origin + '/assets/probe.html'. It loads, and in its console window.GBKit is undefined (on trunk, the object).
5. Dev server — set GUTENBERG_EDITOR_URL=http://10.0.2.2:5173/, run make dev-server, open a post. window.GBKit is defined.
6. With the dev server still configured, navigate to http://10.0.2.2:8888/ — the wp-env site on another port of the same host. It opens in the OS browser rather than being taken for the dev server.
7. make test-android-library-e2e on an emulator.

Not verified on a device: asset paths over the other scheme, covered by a unit case.

The localStorage copy of the globals is removed separately in #613.

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/730")

_{Built from a219102}