gutenberg-mobile icon indicating copy to clipboard operation
gutenberg-mobile copied to clipboard

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

Open fluiddot opened this issue 4 years ago • 9 comments

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

https://user-images.githubusercontent.com/14905380/106916512-8fcde700-6707-11eb-849c-a6556b0073e8.mp4

Smartphone (please complete the following information):

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

fluiddot avatar Feb 04 '21 15:02 fluiddot

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

lukewalczak avatar Feb 10 '21 16:02 lukewalczak

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.

hypest avatar Feb 10 '21 16:02 hypest

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:

  • https://github.com/wordpress-mobile/gutenberg-mobile/issues/1663
  • https://github.com/wordpress-mobile/gutenberg-mobile/issues/1524
  • https://github.com/wordpress-mobile/gutenberg-mobile/issues/2863

Related PRs:

  • https://github.com/wordpress-mobile/AztecEditor-Android/pull/928
  • https://github.com/wordpress-mobile/WordPress-Android/pull/5711
  • https://github.com/WordPress/gutenberg/pull/27583
  • https://github.com/wordpress-mobile/gutenberg-mobile/pull/2877

chipsnyder avatar Feb 10 '21 16:02 chipsnyder

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

tiagomar avatar Apr 21 '23 13:04 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? 🙇

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 🙇 !

https://user-images.githubusercontent.com/14905380/233675984-e633a82a-fde6-4c93-b973-1d9eccae1692.mp4

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

fluiddot avatar Apr 21 '23 15:04 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 managed to reproduce the issue when I switched to Samsung Keyboard, and I could reproduce with several different themes.

Gboard vs Samsung Keyboard

https://user-images.githubusercontent.com/42008628/236927392-5c12f33d-9258-40d2-8c33-476cfd9e1646.mp4

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

tiagomar avatar May 08 '23 20:05 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'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.

fluiddot avatar May 09 '23 07:05 fluiddot

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

jhnstn avatar May 09 '23 18:05 jhnstn

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: https://github.com/wordpress-mobile/AztecEditor-Android/pull/928.
Masu theme Russell theme

derekblank avatar Sep 05 '23 03:09 derekblank