feat: trigger editor savePost() lifecycle from native hosts

[dcalhoun]

What?

Note

This stacks atop #433. The ability to edit existing posts is required for testing the savePost() lifecycle.

Adds a savePost() lifecycle bridge so native hosts can trigger the WordPress core/editor store's save flow without persisting content via the editor.

Why?

Ref CMM-2024.

Plugins like VideoPress need to fire side-effect API calls (e.g., metadata syncing) when the editor's save lifecycle runs. Given the native host app, not the web editor, manages saving, those side-effects never ran.

Exposing the lifecycle as a bridge method that hosts can call allows host-driven saves to trigger the same core/editor store flow that plugins subscribe to, so plugin side-effects fire as expected.

The bridge is lifecycle-only: it does not persist post content. Hosts remain responsible for reading content via getTitleAndContent() and PUTting it through their own REST API calls. The existing filterEndpointsMiddleware (hardened in #432) already swallows the editor's own post-save HTTP request, so calling savePost() does not cause a duplicate REST round-trip.

How?

• JS dispatches dispatch('core/editor').savePost() and removes the editor-save notice in a finally block. The call is added to the host bridge's exposed window.editor API and cleaned up on hook unmount.
• iOS uses callAsyncJavaScript so the Promise returned by editor.savePost() is awaited natively. A documented contract clarifies that lifecycle ≠ persistence and that plugin failures must not block saves.
• Android can't await Promises through evaluateJavascript, so the bridge dispatches the call with a UUID request ID, captures completion in editorDelegate.onSavePostComplete(requestId, success, error), and routes it back to the per-request callback. onDetachedFromWindow() drains any pending callbacks with success = false so coroutines awaiting the bridge don't hang on view teardown.

Testing Instructions

This PR is best tested by editing a post that contains a VideoPress block, since VideoPress is the canonical plugin that depends on the save lifecycle for metadata sync.

Prerequisites:

• A WordPress.com (or Jetpack-connected) site with VideoPress enabled

• An existing post on that site containing at least one VideoPress block

• The site added to the demo app via OAuth¹ (WP.com) or Application Passwords (self-hosted)

• Temporarily allow the VideoPress block type:

  diff --git a/src/utils/blocks.js b/src/utils/blocks.js
  index 52a39f97..fd47f2ab 100644
  --- a/src/utils/blocks.js
  +++ b/src/utils/blocks.js
  @@ -17,7 +17,10 @@ export function unregisterDisallowedBlocks( allowedBlockTypes ) {
  
    const unregisteredBlocks = [];
    getBlockTypes().forEach( ( block ) => {
  -		if ( ! allowedBlockTypes.includes( block.name ) ) {
  +		if (
  +			! allowedBlockTypes.includes( block.name ) &&
  +			block.name !== 'videopress/video'
  +		) {
        unregisterBlockType( block.name );
        unregisteredBlocks.push( block.name );
      }
  

Steps:

1. Open the demo app (iOS or Android) and authenticate with the test site
2. From the site preparation screen, select Post as the Post Type and tap Browse
3. From the posts list, tap the post containing the VideoPress block
4. In the editor, tap the VideoPress block to select it, then open the block inspector
5. Change the Rating from its current value (e.g., G → PG-13)
6. Tap the Save button in the top-right toolbar
7. Wait for the save to complete (the button briefly disables)
8. Open the same post in the WordPress site's web editor
9. Inspect the VideoPress block — verify the Rating reflects the value you set in step 5

Accessibility Testing Instructions

N/A, no navigation changes.

Screenshots or screencast

gbk-save-post-lifecycle.mov

Footnotes

1. Certain VideoPress requests fail with when using the dev server due to CORS, use make build instead. ↩

[dcalhoun]

Noting that invoking savePost() may mean we cannot remove the filterEndpointsMiddleware as referenced in #432 (comment) and #434.

It may still be worthwhile to properly seed the content, but I believe invoking savePost() triggers a PUT request for the same endpoint. There may also be defense in depth by retaining the middleware.

[dcalhoun]

Rebased now that #433 merged.