feat: surface editor crashes natively and offer a reload

[dcalhoun]

What?

A crashed editor leaves only a web error message on screen, with no way back other than closing the post.

Why?

Completes CMM-2008 by making the crashed state clear and recoverable.

The message replaces a React tree that just crashed, so recovery belongs in native code.

How?

• iOS — a notice covers the editor with a Reload Editor button, in a SwiftUI view shared with the load failure message. The button takes the tint hosts set on the editor's view hierarchy, read undimmed so a presentation over the editor at crash time can't leave it gray. While the notice shows, the web view is hidden from VoiceOver.
• Android — EditorErrorView gains an optional action button: a MaterialButton under Material themes, and a platform button otherwise. It makes the web view invisible, so the web view receives no touches or TalkBack focus. Both states use a bundled error icon tinted from the theme, and localized strings.
• Both — notice and load failure titles are accessibility headings that take VoiceOver and TalkBack focus when they appear, which is what announces them. Reload resets readiness, shows the loading indicator, and restores content from editorDidRequestLatestContent / LatestContentProvider. Readiness returns on the next onEditorLoaded, which reapplies code editor mode when the host enabled it, and leaves autofocus to the first load so a reload can't raise the keyboard over restored content. A crash arriving in the moment after a load keeps the notice up rather than losing it to the ready phase.
• iOS — a terminated web content process reloads the same way, dismissing the block inserter and reporting both open dialogs closed and the editor unavailable.
• Android — readiness resets whenever a page starts, and reads still pending when a reload starts fail.
• Docs — the unavailable callbacks tell hosts to re-enable their controls on the next editorDidLoad(_:) / onEditorAvailable. editorDidRequestLatestContent / LatestContentProvider ask for the newest content the host holds, including anything saved this session; nil reloads the content the editor was opened with.
• Demo apps — the overflow menu can trigger a crash, and history, the menu and Save are disabled while the editor is crashed. Close stays available.

Decisions worth reviewing

The notice promises nothing about saved work. Whether anything was persisted depends on the host, which GutenbergKit can't see. Hosts that mirror content can override editorCrashedDescription / gbk_editor_crashed_description.

Reload is user-initiated. Automatic retries would loop when the post's own content causes the crash, and would silently discard edits since the last autosave.

Reloading is not public API. Only the notice and iOS web content process termination reload the editor, both after a page has loaded. Retrying after a load failure would need its own API that fetches dependencies again.

Testing Instructions

Note

Observing autosave requires WordPress-iOS or WordPress-Android rather than GBK's demo app.

Trip the boundary from the web inspector (iOS) or chrome://inspect (Android), on a post with at least one block, in either the visual or code editor. In GBK's demo app, Trigger editor crash in the editor's overflow menu does the same.

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

1. The editor is covered by "The editor stopped working" with a Reload Editor button.
2. Tap Reload Editor — content up to the host's last autosave is intact, and the keyboard stays down rather than opening over it.
3. Editing works normally afterwards — typing, undo/redo, block insertion and save.
4. Crash in the code editor and reload — the editor comes back in the code editor.
5. In the demo app, Undo, Redo, the overflow menu and Save are disabled while the notice shows, and Close stays enabled.

Regression check, in a fresh session with no crash: loading, load failures and normal editing are unchanged.

Accessibility Testing Instructions

With VoiceOver (iOS) or TalkBack (Android) on, trigger a crash:

1. Focus moves to the notice's title, which is announced once, as a heading.
2. Swiping through elements doesn't reach the editor behind the notice.
3. Reload Editor is announced as a button and reloads the editor.

Screenshots or screencast

Before	After

🤖 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/642")

_{Built from 90377e2}

[adalpari]

The PR looks good to me.

Here are two findings from Claude, but they seem to be related to iOS. So I leave them to you and @crazytonyli

Findings, most severe first

1. iOS reload reverts host configuration updates — ios/Sources/GutenbergKit/Sources/EditorViewController.swift:1045 (PLAUSIBLE)

reloadEditor() calls webView.reload(), which re-runs the WKUserScript that was built once in loadEditor(dependencies:). Any updateConfiguration(_:) the host applied after the first load is silently reverted. Android does not have this problem — it rebuilds window.GBKit from the live configuration in onEditorPageStarted(), so the two platforms diverge.

Failure scenario: host saves a new draft and calls updateConfiguration to record the postID → editor crashes → user taps Reload → the page comes back with the original GBKit.post (stale id/status/restBase) while title/content come from editorDidRequestLatestContent. Rated PLAUSIBLE rather than CONFIRMED only because updateConfiguration has no in-repo caller, so it depends on host usage.

2. iOS crash notice leaves the spinner running underneath — ios/Sources/GutenbergKit/Sources/EditorViewController.swift:970 (CONFIRMED, low severity)

didLoseEditor() shows the crash notice but never calls hideActivityView(). For a crash before the first onEditorLoaded — a post whose own content throws on first render, which is the exact case the PR description calls out — the waitingView spins forever under the opaque notice. Worse, every Reload tap calls displayActivityView() again on the same view, re-activating a duplicate constraint set. Android’s showErrorView fades the spinner out for this case; iOS has no equivalent.

[dcalhoun]

Here are two findings from Claude, but they seem to be related to iOS.

Thanks for sharing this, @adalpari. I investigated both.

1. Reload reverts host configuration updates. I'm leaving this as is. updateConfiguration(_:) only sets a property and never reaches the running page. After a reload, the editor has the same GBKit it had before the crash, so nothing gets reverted. The method is left over from #114, where it set the configuration before startEditorSetup() started the load. #250 removed startEditorSetup() but kept updateConfiguration(_:). WordPress-iOS stopped calling it in January. Android behaves the same way: its configuration is a val set at construction, so both platforms reload with the configuration the editor opened with. Trunk's reload after the web content process ends already works like this too. Deprecating updateConfiguration(_:) could be a separate PR.

2. Spinner running under the crash notice. Fixed in 90377e2. The notice now removes the loading indicator. That stops each Reload tap from adding another set of constraints, and leaves no indicator behind the notice for VoiceOver to find.

[dcalhoun]

@crazytonyli will review when you have time please? 🙇🏻‍♂️