Fix editor exit hang when GutenbergView never finishes loading

[jkmassel]

Summary

If GutenbergView never finishes loading (e.g. an upstream 404 on wp-block-editor/v1/settings, network failure mid-init, or any other case where the JS bridge never becomes available), the editor activity gets stuck — back press doesn't dismiss it, the "saving" progress dialog stays open, and the only way out is to force-stop the app.

Fixes #22878.

Root cause

GutenbergKitEditorFragment.getTitleAndContent blocks on CountDownLatch.await() with no timeout. The save-on-exit flow (savePostAndOptionallyFinish → updateAndSavePostAsyncOnEditorExit → updateAndSavePostAsync → updateFromEditor → getTitleAndContent) sits on this latch waiting for TitleAndContentCallback.onResult to fire from JS. When GutenbergView hasn't finished loading, the bridge call is dropped silently — GBKit internally guards on its private isEditorLoaded field and logs "You can't change the editor content until it has loaded". latch.countDown() never fires; the activity never finishes.

Introduced incidentally by #22764 ("Upgrade GutenbergKit from v0.11.1 to v0.15.2"), which switched the bridge call from sync to async-with-latch.

Fix

GBKit doesn't currently expose a public ready-state property — only the setEditorDidBecomeAvailable {} callback. Three layers, all host-side.

1. Track ready state in the fragment

@Volatile var editorReady flipped inside the setEditorDidBecomeAvailable {} listener we already register; reset to false in onCreateView so a stale true doesn't leak across config changes. @Volatile is required because the field is written from the JS bridge thread and read from bgDispatcher (via EditPostRepository.updateAsync). Exposed publicly via isEditorReady().

2. Bound the latch

Replace latch.await() with latch.await(5, TimeUnit.SECONDS). On timeout (or InterruptedException), getTitleAndContent throws EditorFragmentNotAddedException rather than returning a sentinel empty Pair.

3. Short-circuit the save flow before it mutates the PostModel

GutenbergKitActivity.updateFromEditor checks isEditorReady() before calling getTitleAndContent. When false (or when the timeout path throws), it returns UpdateFromEditor.Failed(...). StorePostViewModel.updatePostObjectWithUI treats Failed as a no-op — updatePostContentNewEditor is never called, the in-memory PostModel is not mutated, _postChanged does not fire, and the auto-save observer at GutenbergKitActivity.kt:1158-1162 does not run.

This last step is load-bearing. An earlier draft of this PR returned Pair("", "") from getTitleAndContent on stall, on the assumption that "empty post → no save attempted." That assumption was wrong. _postChanged fires whenever the in-memory PostModel changes, and editPostRepository.postChanged.observe calls storePostViewModel.savePostToDb regardless of shouldSavePost(). For an existing draft, the in-memory overwrite to empty would have been persisted to SQLite, silently wiping the user's content.

Incidental: exception-class mismatch in updateFromEditor's catch

The pre-existing catch was catch (e: EditorFragmentAbstract.EditorFragmentNotAddedException), but GutenbergKitEditorFragment throws GutenbergKitEditorFragmentBase.EditorFragmentNotAddedException — two unrelated inner classes sharing the same simple name, descending separately from Exception. The catch was dead code. Changed to match the actually-thrown class so the new timeout-throw is caught.

Net behaviour

Editor stall → Failed returned → no PostModel mutation → no DB write → activity finishes via ActivityFinishState.CANCELLED within ~5s. Existing draft on disk is preserved.

The underlying 404 / route-detection asymmetry on Atomic sites is a separate concern, owned by #22812 / capability-detection territory. This PR is specifically about the host's failure mode when the editor doesn't load, regardless of why it didn't load.

Test plan

• On WP.com simple site, open a post in the editor, type, and exit — content saves and the activity finishes as before.
• On an Atomic site (I suggest using automatticwidgets.wpcomstaging.com), the editor stalls with Theme Styles and Third-Party Blocks enabled (you'll need to turn these on in Site Settings to see it), open a post in the editor, wait for the stall, press the back button or X — the activity finishes within ~5 seconds instead of hanging indefinitely.
• Open an existing draft with non-empty content on a stalling site, wait for the stall, exit, then reopen the post in a working session — the original content is still there (not overwritten with empty).
• No savePostToDb call is made when exiting from a stalled session (verify in logs).

Related

• Surfaced during testing of Integrate Gutenberg Preloading #22579 (Integrate Gutenberg Preloading).

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 26.8. The due date for this milestone has already passed. Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Android by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr22882-8e8b670
	Build Number	1488
	Application ID	com.jetpack.android.prealpha
	Commit	8e8b670
	Installation URL	0d1gsvmap41u8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Android by scanning the QR code below to install the corresponding build.

	App Name	WordPress Android
	Build Type	Debug
	Version	pr22882-8e8b670
	Build Number	1488
	Application ID	org.wordpress.android.prealpha
	Commit	8e8b670
	Installation URL	0smsge74i4plg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

[nbradbury]

LGTM