Bolding text using the toolbar causes whitespace to be lost

[guarani]

Description

When bolding text using the toolbar button on iOS or Android, any whitespace present at the beginning of the line is removed causing the the text to jump to the left and the whitespace to be lost. This affects the pre-formatted block, the verse block, and, to a lesser extent, the paragraph block. This issue is not present on Gutenberg web.

On iOS, bolding through the native iOS edit menu (the toolbar menu that displays selection options) is not affected by this bug.

The same bug is present for italics or strikethrough.

Steps to Reproduce

There are two distinct scenarios where this bug is present.

Scenario 1: Styling non-selected text

In a paragraph block, type some spaces, then tap the toolbar bold button and observe that the cursor jumps back to the start of the line. The cursor should stay put when the bold button is tapped.

Scenario 2: Styling selected text

1. In a paragraph (or verse or pre-formatted) block, type some spaces and then text, such as:

    Hello

2. Bold the Hello portion of the line using the toolbar bold B button (on iOS, don't use the native iOS edit menu)
3. Observe the text has shifted to the left and the whitespace has disappeared
4. The same occurs for the toolbar italics and strikethrough options

iOS	Android

Expected Behavior

Applying bold/italics/strikethrough to text should not affect leading whitespace or reposition the text in any way.

Devices

	iOS	Android
Device	iPhone 7	Google Pixel Emulator
OS	iOS	Android 10
OS Version	13.3.1	API 29 Version Q

Additional Context

This bug is present in the Gutenberg editor in the WordPress for iOS app and in the Gutenberg example iOS and Android projects in this repo. It is not present on the Aztec for iOS example app or the WordPress for iOS Classic editor.

[guarani]

I've seen this 💥 while reproducing this bug on Android. It seems to happen when you shift text to the right, bold it, and repeat. On the second iteration I've seen this crash often.

[hypest]

This bug is present in the Gutenberg editor in the WordPress for iOS app and in the Gutenberg example iOS and Android projects in this repo

I see the Android demo app is not mentioned. Does the issue happen there too?

From the looks of this, I'd suspect something on the RN/JS level is trimming the whitespace? Have you investigated there @guarani ? In particular, find out if trimming does happen intentionally or not, under which circumstances or assumptions and whether we can suppress that in this case.

[guarani]

I see the Android demo app is not mentioned. Does the issue happen there too?

Are you referring to the Gutenberg demo/example Android project? Then yes – but let me know if you're referring to something else.

It's been a while since I debugged this so I'll do that and write up a summary here.

[guarani]

Where is this bug present?

Where	Is present?
WordPress for iOS/Android	Yes
Gutenberg Mobile Demo App for iOS/Android	Yes
Aztec Editor for iOS/Android	No

Scenario 1 above – where tapping the bold button moves the cursor back to the beginning of the line – is "fixed" by commenting out the following code:

https://github.com/WordPress/gutenberg/blob/master/packages/rich-text/src/component/index.native.js#L119

[guarani]

Reopening to fix issue where whitespace is deleted on second and subsequent lines within a block. Fix coming here: wordpress-mobile/AztecEditor-iOS#1285

[guarani]

Fixed by wordpress-mobile/AztecEditor-iOS#1285

[fylgjur]

Device: Samsung Galaxy S9+
Version: WordPress Android beta 15.0-rc-1
Theme: P2 (A8c Personal)

Although bolded text with spaces before it doesn't jump to the left in block editor, spaces are removed when viewing in the app or on web, though all is fine again in the P2 front edit:

It appears correctly in the Reader:

HTML:

If you need any different info, please say (first post!).
Here's the post in question: https://fylgjurtrialp2.wordpress.com/2020/06/04/testing-post/

[guarani]

@fylgjur thanks a lot for uncovering this – the root cause seems to be an autosave issue, which is now being tracked here: #2349