fix(android): reset readiness when the editor crashes

[dcalhoun]

What?

Android never reset isEditorLoaded, so calls into the editor kept reaching the web view after it crashed.

Why?

The Android half of CMM-2008.

After a crash, history and content commands throw inside the web view, content reads fail with a JSON error rather than reporting the editor unavailable, and hosts can't tell the editor is gone.

isEditorLoaded was set in onEditorLoaded and never cleared, and several calls into the editor didn't check it.

How?

• onEditorUnavailable clears isEditorLoaded, dismisses an open block inserter, and notifies the new EditorUnavailableListener, set with setEditorDidBecomeUnavailable.
• Calls into the editor go through evaluateIfLoaded, which refuses them until the editor loads, logs refusals at debug level, and runs them on the main thread. Content reads report EditorNotReadyException.

Note for review

Robolectric needs merged resources to show the block inserter, so the module's unit tests include Android resources, and GutenbergViewTest no longer sets manifest = Config.NONE.

Testing Instructions

In the demo app, trip the boundary from chrome://inspect, in either the visual or code editor:

const editor = wp.data.select("core/editor");
editor.getEditorMode = () => {
  throw new Error("repro");
};
wp.data.dispatch("core/editor").updateEditorSettings({});

1. adb logcat | grep GutenbergView shows EditorUnavailable received in native code.
2. Tap Undo or Redo — no TypeError appears in the web view console.
3. Repeat with the block inserter open — it closes.

Regression check, in a fresh session with no crash: editing, undo/redo, block insertion and saving are unchanged.

Accessibility Testing Instructions

N/A — no UI changes.

Screenshots or screencast

N/A

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y7VSMTRz2D8MPhuziM7CG5

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

_{Built from f9338dd}

[adalpari]

It looks good to me, so I'm approving it.

Claude found a few points. I think some of them are worth noting for you to have a look:

1. Permanent spinner when the editor crashes before it loads — HIGH
   GutenbergView.kt:973 — onEditorUnavailable() resets isEditorLoaded and dismisses the inserter, but never transitions the UI phase. showReadyPhase() only runs inside the didFireEditorLoaded guard in onEditorLoaded() (line 944), so if the crash lands first, spinnerView stays visible and webView.alpha stays 0f forever. The error boundary’s “The editor has encountered an unexpected error.” message is rendered but invisible behind the alpha-0 WebView, and there’s no reload path to escape. The user sees an infinite spinner. This is the exact case the new KDoc calls out. iOS has the same gap (EditorViewController.swift:937).

2. setMediaUploadAttachment loses the context id on refusal — MEDIUM
   GutenbergView.kt:1050-1061 — currentMediaContextId = null now runs unconditionally after evaluateIfLoaded(...). When the call is refused, the attachment is dropped and the id is gone, so any retry fails with “called without contextId”. The pre-PR early return preserved it.

3. textEditorEnabled still bypasses the central guard — MEDIUM
   GutenbergView.kt:214-221 — the setter calls handler.post { webView.evaluateJavascript("editor.switchEditorMode('$mode');") } directly. It’s the one remaining raw editor.* call and will throw a TypeError after a crash, which undercuts the PR’s stated goal of refusing editor calls in one place. One-line fix: route it through evaluateIfLoaded.

[adalpari]

LGTM

[dcalhoun]

@adalpari thank you for the review.

1. Permanent spinner when the editor crashes before it loads — HIGH

Given this is not a regression in #640 and is also fixed in #642, I suggest we let the latter address it.

2. setMediaUploadAttachment loses the context id on refusal — MEDIUM

This appears to accurately describe the diff but the issue is benign.

The retained ID is dead as the JS callbackRegistry entry is deleted when the media upload hook unmounts, and a reload resets both the registry and the ID counter. Preserving the ID only swaps one failure for another: No callback found for contextId from JS instead of called without contextId from Kotlin. Neither recovers the attachment, so discarding the stale ID seems like the better of the two. I suggest we leave it.

3. textEditorEnabled still bypasses the central guard — MEDIUM

This is addressed in #642. Given it has no user impact in this branch, I suggest we let #642 deliver the fix.