[dcalhoun]

What?

Expose entity save availability via new bridge event.

Why?

Close CMM-2552. Currently, hosts own post saving and rely on their own internal tracking for enabling UI for saving posts. In preparation for GutenbergKit managing post saving via Gutenberg's APIs, GutenbergKit must expose the current save availability status. This is opt-in functionality, not a breaking change.

How?

Introduce a new save availability event and callback for iOS and Android respectively. These are utilized anytime the editor's store modifies its relevant state.

Testing Instructions

1. Open an existing post
2. Insert an Image block
3. Verify the Save button is enabled
4. Upload a new image
5. Verify the Save button is disabled until the upload completes

Accessibility Testing Instructions

N/A, no navigation changes.

Screenshots or screencast

N/A, no navigation changes.

---

AI-generated details

Phase 2 of the CMM-2024 editor-driven saving plan. Hosts can now disable their save controls while the editor reports that saving is locked, e.g. during a media upload, instead of persisting temporary blob: URLs.

• JS: useSyncSaveAvailability sends onEditorSaveAvailabilityChanged { isSaveable, isSavingLocked } once the editor is ready and then on each change, deduplicated. isDirty/isSaving are left out until the editor saves posts. Adapted from feat: add real editor-driven save post mechanism #445 (co-authored).
• iOS: editor(_:didUpdateSaveAvailability:) with a default no-op implementation, so the change is non-breaking; EditorSaveAvailability struct.
• Android: setSaveAvailabilityListener(SaveAvailabilityListener?), delivering GutenbergView.SaveAvailability on the main thread.
• Demo apps: Save is disabled while saving is locked.
• After unmount: reporting stops when the editor unmounts. Hosts should disregard the last state after onEditorUnavailable.

What locks saving: block media uploads lock saving through the editor's mediaUpload setting. That includes uploads routed through the native upload server, since the middleware runs inside the same request. Media picked through the host's native media library doesn't lock the editor.

Testing: JS unit tests for the hook; Swift decoding test; Kotlin listener test. JS, Swift and Kotlin unit suites and lint pass locally.

🤖 Generated with Claude Code

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

_{Built from 381e1a4}

[crazytonyli]

I guess the idea is that the app should disable save button when isSavingLocked. But what if the save action is still triggered, in code, not by user tapping the save button, would/should the GBK throw an error somehow, or is that acceptable?

[dcalhoun]

I guess the idea is that the app should disable save button when isSavingLocked. But what if the save action is still triggered, in code, not by user tapping the save button, would/should the GBK throw an error somehow, or is that acceptable?

Good question. The lock is guidance, and hosts should check it before programmatic saves. I updated the documentation to better communicate this.

For comparison: the web editor disables various UI mechanisms (save button, keyboard shortcuts), but it does not prevent programmatic saves of in-flight uploads. Once saving moves to GutenbergKit, it will return a skipped result with a reason rather than throwing. This will take GutenbergKit beyond the web's behavior, but feels appropriate as the host cannot otherwise see the editor state.

Much of this is in a local plan document. I'll move those to a Linear project/issues for better visibility (Update: See P-CMM-11379). Thank you for the question.