fix(android): load the editor same-origin on sites with a non-standard port

[dcalhoun]

What?

The editor document was served from the site's host without its port, so on a site with a non-standard port it ran on a different origin than the site and every REST request became cross-origin — the opposite of what the surrounding code intends.

Why?

An origin is scheme + host + port, so a site at http://10.0.2.2:8888 produced an editor at http://10.0.2.2 (implicit port 80).

Users on a self-hosted site with a non-standard port — behind a reverse proxy, on alternate-port hosting, or an internal deployment — get an editor that cannot read site data. Blocks that fetch from the REST API to render, such as Latest Posts, Categories List, and Terms List, fail. Requests only succeed at all if the site adds server-side CORS configuration that a same-origin editor never needs. Even then, response headers outside the CORS safelist stay unreadable, because core's rest_send_cors_headers() only exposes X-WP-Total, X-WP-TotalPages, and Link.

Sites on default ports (:80/:443) are unaffected, since their URLs carry no port. That covers WordPress.com and most self-hosted sites, which is why this went unnoticed.

It is also invisible in day-to-day development: setting GUTENBERG_EDITOR_URL makes the WebView load the dev server instead of the bundled assets, so the affected value is computed and discarded. The bug only surfaces in bundled builds — the configuration that ships.

Against wp-env, this blocked the entire editor bootstrap: settings, taxonomies, global styles, block patterns, blocks, media, pages, and the theme's webfont.

How?

Derive the asset origin from the site URL's authority (host and port) rather than its host. WebViewAssetLoader matches on authority, so a port-bearing value still resolves assets correctly.

The comparisons in shouldInterceptRequest and shouldOverrideUrlLoading move to authority in the same change — a port-bearing value would otherwise stop matching and break asset interception entirely.

Deliberately left alone:

• cachedAssetHosts is a caller-supplied host allowlist, not an origin comparison. WordPress-Android passes bare hosts (s0.wp.com, the site host), so converting it would silently break those callers.
• LOCAL_HOSTS is likewise a host allowlist.
• DEFAULT_ASSET_DOMAIN keeps its name as a public top-level const, and is already a valid authority.

Not a breaking change for consumers: the renamed field is private, and the public EditorConfiguration API is untouched.

Testing Instructions

The bug is only reachable in a bundled build, so GUTENBERG_EDITOR_URL must be unset.

1. make wp-env-android — installs the URL-remap mu-plugin and starts wp-env with the site URL remapped to http://10.0.2.2:8888 for the emulator.
2. Comment out GUTENBERG_EDITOR_URL in android/local.properties so the app uses the bundled build.
3. Build and install the Android demo app on an emulator.
4. Open Local WordPress (wp-env), enable Enable Network Logging, and tap Start.
5. Insert blocks that depend on REST API requests to render:
   • Latest Posts
   • Categories List
   • Terms List

Expected: each block renders its content. Before this fix they fail, because the requests backing them are blocked cross-origin.

Also confirm the editor bootstrap itself is clean — adb logcat should show no blocked by CORS policy errors, and the console source should be http://10.0.2.2:8888/assets/index.html (with the port), matching the site origin.

To see the failure for comparison, check out trunk and repeat from step 3: the same blocks fail and logcat fills with CORS errors against origin 'http://10.0.2.2'.

Regression check on the unaffected path: open a WordPress.com or default-port self-hosted site and confirm the editor still loads normally. Host and authority are identical there, so behavior should be unchanged.

Accessibility Testing Instructions

N/A — no user interface changes.

[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/599")

_{Built from 57f373a}

[nbradbury]

@dcalhoun I asked Claude for a review, and it seems like at least the first issue needs to be addressed.

review-pr599-android-editor-origin-2026-08-24.pdf

[dcalhoun]

@nbradbury I addressed the two findings from your PDF. Ready for your re-review.

[dcalhoun]

@nbradbury to clarify, I fixed the issues as described by your PDF. I did not replicate the described problem, but addressed them a defense in depth. Did you replicate the reported issue on a site? Particularly first finding.