Block editor: Keyboard is not always shown when a new block is added #16167

twstokes · 2022-03-24T17:29:17Z

Expected behavior

When a block has focus and a blinking cursor the keyboard is shown.
After inserting a new block such as a Paragraph or List (step 3 below) the keyboard is shown.

Actual behavior

Sometimes a block added from the Inserter has focus and a blinking cursor, but no keyboard is shown.

Steps to reproduce the behavior

Create a new Blog post.
Tap the default Paragraph block ("Start writing..."). There is a blinking cursor and the system's keyboard appears.
Tap the "+" to open the Inserter and choose a Paragraph or List block (other blocks may be affected as well).
Observe that the keyboard is no longer showing, but the input cursor is blinking inside the block.

Inserter.Keyboard.mp4

At the end of the video I tapped into Area A (see Extra discussion below).

Extra discussion

I initially thought that you couldn't show the keyboard on the block without toggling its focus, but then learned there's a couple hit areas that behave differently. On the Pixel 4a, at least, it felt like I needed to be extra precise to hit Area A and present the keyboard.

Tested on Pixel 4a, Android 12, WPAndroid 19.5

fluiddot · 2022-03-25T08:37:17Z

This issue looks related to WordPress/gutenberg#29048 and WordPress/gutenberg#28748.

antonis · 2022-04-29T11:57:47Z

I confirm that the issue is still reproducible on 19.7

RenanLukas · 2022-07-18T20:58:47Z

Reproducible on 20.2 using emulator, but not reproducible using a real device (XT1926-3).

thehenrybyrd · 2022-07-19T13:55:01Z

I was able to reproduce on my Samsung Galaxy S21, using Android 12, WP Android 20.3-rc-1.

Screen_Recording_20220719-165032_WordPress.mp4

RenanLukas · 2022-07-20T17:43:06Z

I wasn't able to understand why is it not reproducible on some devices 🤔
More info on the devices I wasn't able to reproduce the issue:

Galaxy A11 (SM-A115M/DS) - Android 11 - WP Android 20.3-rc-1

Moto G6 Plus (XT1926-3) - Android 9 - WP Android 20.3-rc-1

AjeshRPai · 2022-08-22T11:22:25Z

During the Groundskeeping I was able to reproduce this issue on the Android 12 Pixel emulator. I couldn't find a particular pattern which might be the cause of this issue. This issue happens on Android 11/Android 12 when I tried to reproduce it. I could see the below log message when the keyboard gets dismissed. Hope it helps

W/InputMethodManager: Ignoring showSoftInput() as view=org.wordpress.mobile.ReactNativeAztec.ReactAztecText is not served.

ravishanker · 2022-09-26T06:07:50Z

I'm unable to reproduce this on Pixel 4a - Android 13 - WPAndroid v20.8

Given the issue is not consistent and seems to be device dependent. I'm going to reduce the priority of this to Medium.

The focus callback triggered by Aztec-based programmatic focus events can result in focus loops between rich text elements. Android: This intentional no-op function prevents focus loops originating when the native Aztec module programmatically focuses the instance. The no-op is explicitly passed as an `onFocus` prop to avoid future prop spreading from inadvertently introducing focus loops. The user-facing focus of the element is handled by `onPress` instead. See: wordpress-mobile/gutenberg-mobile#302 iOS: Programmatic focus from the native Aztec module is required to ensure the React-based `TextStateInput` ref is properly set when focus is *returned* to an instance, e.g. dismissing a bottom sheet. If the ref is not updated, attempts to dismiss the keyboard via the `ToolbarButton` will fail. See: wordpress-mobile/gutenberg-mobile#702 The Android keyboard is, likely erroneously, already dismissed in the contexts where programmatic focus may be required on iOS. - #28748 - #29048 - wordpress-mobile/WordPress-Android#16167 Programmatic swapping focus from element to another often leads to focus loops, only delegate the programmatic focus if there are no elements focused. See: wordpress-mobile/WordPress-iOS#18783

pachlava · 2023-01-20T13:09:26Z

Something very similar happens to me on WPA 21.5-rc-1 | Samsung A31 | Android 12:

az_recorder_20230120_143349.mp4

The focus callback triggered by Aztec-based programmatic focus events can result in focus loops between rich text elements. Android: This intentional no-op function prevents focus loops originating when the native Aztec module programmatically focuses the instance. The no-op is explicitly passed as an `onFocus` prop to avoid future prop spreading from inadvertently introducing focus loops. The user-facing focus of the element is handled by `onPress` instead. See: wordpress-mobile/gutenberg-mobile#302 iOS: Programmatic focus from the native Aztec module is required to ensure the React-based `TextStateInput` ref is properly set when focus is *returned* to an instance, e.g. dismissing a bottom sheet. If the ref is not updated, attempts to dismiss the keyboard via the `ToolbarButton` will fail. See: wordpress-mobile/gutenberg-mobile#702 The Android keyboard is, likely erroneously, already dismissed in the contexts where programmatic focus may be required on iOS. - #28748 - #29048 - wordpress-mobile/WordPress-Android#16167 Programmatic swapping focus from element to another often leads to focus loops, only delegate the programmatic focus if there are no elements focused. See: wordpress-mobile/WordPress-iOS#18783

* Mobile - Update changelog * fix: Avoid iOS block appender focus loop The focus callback triggered by Aztec-based programmatic focus events can result in focus loops between rich text elements. Android: This intentional no-op function prevents focus loops originating when the native Aztec module programmatically focuses the instance. The no-op is explicitly passed as an `onFocus` prop to avoid future prop spreading from inadvertently introducing focus loops. The user-facing focus of the element is handled by `onPress` instead. See: wordpress-mobile/gutenberg-mobile#302 iOS: Programmatic focus from the native Aztec module is required to ensure the React-based `TextStateInput` ref is properly set when focus is *returned* to an instance, e.g. dismissing a bottom sheet. If the ref is not updated, attempts to dismiss the keyboard via the `ToolbarButton` will fail. See: wordpress-mobile/gutenberg-mobile#702 The Android keyboard is, likely erroneously, already dismissed in the contexts where programmatic focus may be required on iOS. - #28748 - #29048 - wordpress-mobile/WordPress-Android#16167 Programmatic swapping focus from element to another often leads to focus loops, only delegate the programmatic focus if there are no elements focused. See: wordpress-mobile/WordPress-iOS#18783 * fix: Programmatic Aztec input focus only updates internal ref Programmatically swapping input focus creates an infinite loop if the user taps a different input in between the programmatic focus and the resulting update to the React Native TextInputState focused element ref. To mitigate this, the Aztec now updates the focused element ref, but does not call the native focus methods. See: wordpress-mobile/WordPress-iOS#18783 * Mobile - AztecView - Check for isFocused before forcing the focus * Mobile - DefaultBlockAppender and BlockList Footer placeholders - Removes inline functions and other minor code style changes * Mobile - AztecView - Trigger _onFocus within _onAztecFocus to prevent having a RichText component focused while another block is selected --------- Co-authored-by: David Calhoun <438664+dcalhoun@users.noreply.github.com>

* Release script: Update react-native-editor version to 1.100.1 * Release script: Update with changes from 'npm run core preios' * Update `react-native-editor` changelog * Release script: Update react-native-editor version to 1.100.2 * Release script: Update with changes from 'npm run core preios' * Mobile - Fix iOS Focus loop for RichText components (#53217) * Mobile - Update changelog * fix: Avoid iOS block appender focus loop The focus callback triggered by Aztec-based programmatic focus events can result in focus loops between rich text elements. Android: This intentional no-op function prevents focus loops originating when the native Aztec module programmatically focuses the instance. The no-op is explicitly passed as an `onFocus` prop to avoid future prop spreading from inadvertently introducing focus loops. The user-facing focus of the element is handled by `onPress` instead. See: wordpress-mobile/gutenberg-mobile#302 iOS: Programmatic focus from the native Aztec module is required to ensure the React-based `TextStateInput` ref is properly set when focus is *returned* to an instance, e.g. dismissing a bottom sheet. If the ref is not updated, attempts to dismiss the keyboard via the `ToolbarButton` will fail. See: wordpress-mobile/gutenberg-mobile#702 The Android keyboard is, likely erroneously, already dismissed in the contexts where programmatic focus may be required on iOS. - #28748 - #29048 - wordpress-mobile/WordPress-Android#16167 Programmatic swapping focus from element to another often leads to focus loops, only delegate the programmatic focus if there are no elements focused. See: wordpress-mobile/WordPress-iOS#18783 * fix: Programmatic Aztec input focus only updates internal ref Programmatically swapping input focus creates an infinite loop if the user taps a different input in between the programmatic focus and the resulting update to the React Native TextInputState focused element ref. To mitigate this, the Aztec now updates the focused element ref, but does not call the native focus methods. See: wordpress-mobile/WordPress-iOS#18783 * Mobile - AztecView - Check for isFocused before forcing the focus * Mobile - DefaultBlockAppender and BlockList Footer placeholders - Removes inline functions and other minor code style changes * Mobile - AztecView - Trigger _onFocus within _onAztecFocus to prevent having a RichText component focused while another block is selected --------- Co-authored-by: David Calhoun <438664+dcalhoun@users.noreply.github.com> --------- Co-authored-by: Derek Blank <derekpblank@gmail.com> Co-authored-by: Carlos Garcia <fluiddot@gmail.com> Co-authored-by: David Calhoun <438664+dcalhoun@users.noreply.github.com>

fluiddot · 2024-01-18T16:07:59Z

Closing this issue as it should be fixed via WordPress/gutenberg#57069 in version 24.0

twstokes added the gutenberg-mobile label Mar 24, 2022

twstokes changed the title ~~Keyboard is not always shown when a new block is added~~ Block editor: Keyboard is not always shown when a new block is added Mar 24, 2022

twstokes added the Posting/Editing label Mar 24, 2022

twstokes added the [Type] Bug label Mar 28, 2022

thehenrybyrd added the [Pri] High label Apr 15, 2022

derekblank self-assigned this Sep 9, 2022

ravishanker added [Pri] Medium and removed [Pri] High labels Sep 27, 2022

dcalhoun mentioned this issue Oct 14, 2022

fix: Avoid iOS block appender focus loop WordPress/gutenberg#44988

Closed

dcalhoun added Gutenberg Editing and display of Gutenberg blocks. and removed gutenberg-mobile labels Apr 24, 2023

fluiddot closed this as completed Jan 18, 2024

github-project-automation bot added this to Mobile Gutenberg Aug 27, 2024

github-project-automation bot moved this to Done (keep clean, manually) in Mobile Gutenberg Aug 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block editor: Keyboard is not always shown when a new block is added #16167

Block editor: Keyboard is not always shown when a new block is added #16167

twstokes commented Mar 24, 2022

fluiddot commented Mar 25, 2022

antonis commented Apr 29, 2022

RenanLukas commented Jul 18, 2022

thehenrybyrd commented Jul 19, 2022

RenanLukas commented Jul 20, 2022

AjeshRPai commented Aug 22, 2022

ravishanker commented Sep 26, 2022 •

edited

Loading

pachlava commented Jan 20, 2023

fluiddot commented Jan 18, 2024

Block editor: Keyboard is not always shown when a new block is added #16167

Block editor: Keyboard is not always shown when a new block is added #16167

Comments

twstokes commented Mar 24, 2022

Expected behavior

Actual behavior

Steps to reproduce the behavior

Extra discussion

Tested on Pixel 4a, Android 12, WPAndroid 19.5

fluiddot commented Mar 25, 2022

antonis commented Apr 29, 2022

RenanLukas commented Jul 18, 2022

thehenrybyrd commented Jul 19, 2022

RenanLukas commented Jul 20, 2022

AjeshRPai commented Aug 22, 2022

ravishanker commented Sep 26, 2022 • edited Loading

pachlava commented Jan 20, 2023

fluiddot commented Jan 18, 2024

ravishanker commented Sep 26, 2022 •

edited

Loading