Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

I gave this a spin and in general, it's working ok, but there are still some edge cases:

• If you try to write something like I like to be <strong>bold</strong> and the auto-save occurs in the middle of writing the strong element you will get some strange HTML generation.

• When you switch back to the visual mode you will see the unsupported block but when you tap to remove it you see:

It says: Remove Classic is this expected/wanted?

@SergioEstevao Thanks for giving it a go. I do think Remove Classic is expected as it corresponds to the classic block. I have updated the PR to reflect that on the unsupported block ui.

If you try to write something like I like to be bold and the auto-save occurs in the middle of writing the strong element you will get some strange HTML generation.

Yeah that's a problem, maybe we could update the autosave in WP apps to be triggered less often? We can't do much on the RN side as we just react to the native-editor.persist-html action.

We can't do much on the RN side as we just react to the native-editor.persist-html action.

One thing we could do though is send the HTML as it is whenever the parent apps asks for it, no need to parse and serialize back while we're in the HTML mode. If the post is reloaded and some HTML is invalid the block parser will try to fix that (which may fail but there are always the possibility of falling back to aztec in that case)

@SergioEstevao I did just that. Could you give it another go please?

One thing we could do though is send the HTML as it is whenever the parent apps asks for it.

I feel that that'd be the expectation. When in html mode, the user has direct access to the raw post and I think it has to be the source of truth and stay unaltered. Switching back and forth between visual and html mode might be a different deal, but while editing in html mode I'd expect the edits to be kept as is.