feat: Recover content on WebView refresh via pull model

[dcalhoun]

What?

Adds a pull-based content recovery mechanism that allows the web editor to request the latest content from the native host during initialization.

Why?

Ref CMM-1123.

When the WebView reinitializes (due to OS memory pressure or page refresh), the editor previously loaded stale content from window.GBKit.post which was injected at original load time. The host apps have fresher content from autosave events (~1s intervals), but this wasn't being used on WebView recovery.

Related WordPress app PRs:

• WordPress-iOS: feat: Implement editorRequestsLatestContent for WebView recovery WordPress-iOS#25144
• WordPress-Android: feat: Implement LatestContentProvider for WebView recovery WordPress-Android#22493

How?

Implements a pull model where the web editor always requests content from the native host during initialization:

1. Web bridge (src/utils/bridge.js): Added requestLatestContent() function that calls the appropriate native bridge method
2. iOS (EditorViewController.swift): Implements WKScriptMessageHandlerWithReply to respond to content requests via a new delegate method editorRequestsLatestContent
3. Android (GutenbergView.kt): Adds LatestContentProvider interface and @JavascriptInterface method that returns JSON content
4. Editor initialization (src/utils/editor.jsx): getPost() now requests content from native host first, falling back to window.GBKit.post only when bridge is unavailable

Testing Instructions

1. Open a post with existing content in the editor
2. Make edits to the content (wait 2+ seconds for autosave)
3. Trigger a WebView refresh:
   • Safari DevTools: Cmd+R while WebView is inspected via the Safari Inspector
   • iOS Simulator: Open Activity Monitor, force quit "com.apple.WebKit.WebContent"
   • Android: Cmd+R while WebView is inspected via the Chrome Inspector by visiting chrome://inspect
4. Verify the editor recovers with the edited content, not the original

Accessibility Testing Instructions

No UI changes - this is a data recovery mechanism that happens during initialization.

Screenshots or screencast

N/A - No visual changes

🤖 Generated with Claude Code

[dcalhoun]

@claude

[claude]

Claude finished @dcalhoun's task in 1m 53s —— View job

---

Code Review Complete ✅

This PR implements a solid pull-based content recovery mechanism. The implementation is well-structured across all three platforms with comprehensive test coverage. Below is my detailed review.

---

Overall Assessment

Strengths:

• ✅ Clear architecture with consistent patterns across iOS, Android, and web
• ✅ Excellent test coverage (406 lines of new tests)
• ✅ Well-documented code with helpful comments
• ✅ Proper fallback behavior when bridge is unavailable
• ✅ Demo implementations in both sample apps

Architecture: The pull model is the right approach here. Having the web layer request content rather than push it eliminates timing issues and makes the recovery mechanism more reliable.

---

Detailed Findings

1. Code Quality ⚠️

JavaScript (bridge.js:256-278)

• Error handling uses debug() instead of error() for actual failures (violates CLAUDE.md logging guidelines)
• iOS bridge check could be more defensive with runtime type validation
• See inline comments for suggested improvements

Swift (EditorViewController.swift:665, 749)

• Delegate method return is optional, which could mask integration issues in production
• Return type doesn't distinguish between "no content" vs "error" scenarios
• Consider adding debug logging when delegate is nil

Kotlin (GutenbergView.kt:672)

• JSON serialization lacks error handling for edge cases
• Could crash if content contains problematic characters
• Should wrap in try-catch (see inline comment)

2. Security ✅

No security concerns identified:

• ✅ Content is properly URL-encoded on both platforms
• ✅ No injection vulnerabilities in bridge communication
• ✅ JSON parsing has appropriate error handling (except one case noted above)
• ✅ No authentication/authorization changes

3. Performance ✅

Performance impact is minimal and positive:

• ✅ Async/await pattern prevents blocking UI thread
• ✅ Single content request during initialization (no polling)
• ✅ Fallback to cached GBKit.post is instant when bridge unavailable
• ✅ No additional network requests

Measurement suggestion: Consider adding timing metrics to measure recovery speed in production.

4. Testing ⭐

Excellent test coverage:

• ✅ 406 lines of new tests in bridge.test.js
• ✅ Tests cover iOS bridge, Android bridge, fallbacks, and priority
• ✅ Edge cases well covered (null, empty string, malformed JSON, errors)
• ✅ Test for iOS priority over Android when both available

Minor suggestion: The priority test at line 182 is great but could use a comment explaining why iOS has priority.

5. Documentation ✅

Documentation is thorough:

• ✅ JSDoc comments on new functions
• ✅ Swift documentation comments on delegate method
• ✅ Kotlin interface documentation
• ✅ PR description explains the "why" clearly
• ✅ Testing instructions are comprehensive

---

Recommendations

High Priority

1. Fix logging per CLAUDE.md guidelines - Use error() for actual errors in bridge.js:262, 272
2. Add error handling to Android JSON serialization - See inline comment on GutenbergView.kt:672

Medium Priority

3. Improve error observability - Distinguish between "no content" vs "error" in iOS implementation
4. Add resilience to editor initialization - Wrap getPost() in try-catch in editor.jsx:46

Low Priority

5. Add debug logging - Log when delegate is nil to help integrators discover missing implementation
6. Add runtime type checks - More defensive iOS bridge validation

---

Pre-Merge Checklist

Before merging, please ensure:

• Run make format to format JavaScript code
• Run make lint-js-fix to auto-fix linting errors
• Run make lint-js to verify linting passes
• Run make test-js to ensure all tests pass

(Per CLAUDE.md pre-commit checklist)

---

Summary

This is a well-implemented feature that solves a real problem. The architecture is sound, test coverage is excellent, and the code is generally high quality. The issues identified are mostly minor improvements around error handling and observability.

Recommendation: Approve with suggested improvements for error handling.

---

[dcalhoun]

It remains true we need a -1 fallback ID for draft posts, but this appears unrelated to auto-save. We now use the AutosaveMonitor in the GutenbergKit project.

For posterity, this comment was first added in 444de49.