Heading block stops being rendered as a header when deleting the first word

[fluiddot]

Describe the bug
While testing the writing flow, specifically the test case "Splitting and merging - TC002 - Merge after selection", I spotted that selecting and deleting the first word, the block stops being rendered as a header, instead it looks like a regular paragraph.

I managed to reproduce it also by selecting and deleting the first letter of the content.

To Reproduce
Steps to reproduce the behavior:

1. Go to a post/page
2. Add a Heading block
3. Write some text
4. Select the first word (it should include the first letter of the content)
5. Tap Backspace key for deleting it
6. Observe that the block stops being rendered as a header instead it's rendered as a regular paragraph

NOTE: This issue can only be reproduced using the Samsung Keyboard (factory default). With the Gboard it works as expected.

Expected behavior
Heading block should be always rendered as a header (bigger font size and spacing).

Screenshots

heading-block-issue-android.mp4

Smartphone (please complete the following information):

• Device: Samsung Galaxy S20 FE 5G
• OS: Android 10
• Version: 16.5 and Pre Alpha - Build 94309

[lukewalczak]

Hello @fluiddot, after the initial investigation I can say it's related not only with the header but generally with rich text (aztec).

Please notice that first backspace press removes only the selected text style and then second press removes the selected text. The same happens in paragraph when you try to remove first styled word (bold or italic), however it doesn't remove the style layer visually but unselects toolbar buttons responsible for text styles.

From the code perspective JS part is correct, looks like native changes are required. Text comes from nativeEvent within method onSelectionChange initially is correct (wrapped in tags <h2>Example text</h2>), however the same text in that function received after backspace press doesn't have tags (Example).

I've checked the result of getText in method propagateSelectionChanges in file and actually it has the incorrect value (text without html tags), so imo something has to be wrong within methods responsible for handling backspace key in AztecText.

cc: @chipsnyder @hypest

[hypest]

Reminds me of Aztec level issues indeed (see this one and this one for instance) where the issue stems from how Aztec-Android uses Spans to implement the rich-text functionality, deleting markup in the process when hitting backspace(s).

We need to "go back to Aztec" and try to fix the various different writing flow issues that seem to have the same root cause, but until then I think it's fine to keep this ticket open but not actively working on it at the time being.

[chipsnyder]

Thanks for that analysis @lukewalczak. There is a lot of history on the heading block and deleting text at the start. I'll add dump of the related issues and PRs

There have been a few issues in this area that might be related to why this one is occurring:

• Deleting Heading Block content requires extra backspace to show placeholder #1663
• [Android] Extra backspace in paragraph blocks with formatting #1524
• Heading Block: cannot highlight and replace content or highlight and press backspace to add new text to a heading when it is inside a cover block #2863

Related PRs:

• [Gutenberg] Account for the end of buffer marker AztecEditor-Android#928
• Clear the ZWJs from Aztec's title string WordPress-Android#5711
• [Mobile] Treat a string that only contains the formatting marker as empty for block formatting WordPress/gutenberg#27583
• Treat a string that only contains the formatting marker as empty for block formatting #2877

[tiagomar]

👋 @fluiddot, I'm not able to reproduce this issue on 22.2-rc-2. Do you mind checking if it's still a thing? 🙇

[fluiddot]

👋 @fluiddot, I'm not able to reproduce this issue on 22.2-rc-2. Do you mind checking if it's still a thing? 🙇

Hey @tiagomar, I can still reproduce it in 22.2-rc-2 (see attached video). Note that the Heading block is not transformed but the font size is that part that changes. If you can't reproduce it, maybe it's related to the theme used, could you try with Masu? Thanks 🙇 !

Screen_Recording_20230421_172917_Jetpack.mp4

Tested on Samsung Galaxy S20 FE 5G (Android 13) - Simple site - Theme: Maus

[tiagomar]

Hey, @fluiddot, that's interesting!
I did try Masu theme and couldn't reproduce it but, after further investigation, now I think I understand why. I don't use the Samsung Keyboard (factory default), but the Gboard instead. I managed to reproduce the issue when I switched to Samsung Keyboard, and I could reproduce with several different themes.

Gboard vs Samsung Keyboard

keyboards.mp4

Tested on Samsung Galaxy Note 20 (Android 12) - Simple site - Theme: Maus

[fluiddot]

Hey, @fluiddot, that's interesting!
I did try Masu theme and couldn't reproduce it but, after further investigation, now I think I understand why. I don't use the Samsung Keyboard (factory default), but the Gboard instead. I've managed to reproduce the issue when I switched to Samsung Keyboard, and I could reproduce with several different themes.

Ah, good catch 🙇 . I'll update the issue's description with this information.

[jhnstn]

FYI I am able to recreate this issue on a Pixel 6 using Hacker's Keyboard

[derekblank]

I was able to replicate this issue on a Samsung Galaxy S20 FE 5G, and noted some additional observations:

• In addition to the Masu theme, I was able able to replicate it using the Russell theme, but it is a bit less noticeable.
• In addition to the Samsung Keyboard, the issue can also be replicated with the Microsoft Swiftkey keyboard. I could not replicate the issue using the Gboard keyboard.
• The Editor HTML remains correct when the text size changes: <h2 class="wp-block-heading"></h2>, so the issue appears to be purely visual. Also, when toggling between the HTML and Visual modes, the text size returns to the larger "Heading" size.
• The issue may not be entirely related to the backspace or selection events: the text size also renders the smaller size when the block is initially created and the placeholder text is shown. When typing starts, the text jumps to the larger size. I tried manipulating some of the selection events in ReactAztecBackSpaceEvent.java, but the changes didn't appear to affect behavior. The issue could possibly be related to the logic when accounting for the end of buffer marker: [Gutenberg] Account for the end of buffer marker AztecEditor-Android#928.

Masu theme	Russell theme
Heading.Test.mov	Heading.Test.mp4