Android keyboard is not displayed when adding a block #29048

dcalhoun · 2021-02-16T20:38:09Z

Description

When adding a new block, both while having the keyboard open or closed, the Android keyboard ~~occasionally~~ will not display open, even though the cursor is shown to be in the newly added block. Contrastingly, iOS always appropriately open the keyboard.

UPDATE (made by @fluiddot ): As outlined in this comment, this issue is happening more often so it should no longer be considered an occasional.

Step-by-step reproduction instructions

Launch Android app.
Add new post.
Add a paragraph block with text.
Add another text block.

Expected behaviour

The Android keyboard is open to match the fact the cursor is placed in the new block and ready for text entry.

Actual behaviour

Occasionally, the Android keyboard is closed, even though the cursor is within the new block.

Screenshots or screen recording (optional)

Android

android-sporadic-keyboard-new-block.mp4

iOS

ios-keyboard-new-block.MP4

WordPress information

WordPress version: WP.com
Gutenberg version: TBD
Are all plugins except Gutenberg deactivated? Yes
Are you using a default theme (e.g. Twenty Twenty-One)? No

Device information

Device: Samsung Galaxy S20 5G FE
Operating system: Android 11
WordPress app version: 16.6

dcalhoun · 2021-02-16T20:38:45Z

This may be related or duplicative of #28748.

fluiddot · 2022-04-05T09:49:27Z

I'm experiencing this issue every time I insert a text block from the block picker in the latest version 19.6-rc-1, so maybe it shouldn't be considered as an occasional issue 🤔.

@mchowning I see we marked this issue as Low priority, however, since it's happening more often we might consider increasing the priority, wdyt?

mchowning · 2022-04-05T13:09:28Z

@mchowning I see we marked this issue as Low priority, however, since it's happening more often we might consider increasing the priority, wdyt?

That makes sense. I'll go ahead and bump it up to high priority in light of "I'm experiencing this issue every time I insert a text block from the block picker", but go ahead change that if you think that something else is more appropriate.

fluiddot · 2022-04-05T13:27:57Z

That makes sense. I'll go ahead and bump it up to high priority in light of "I'm experiencing this issue every time I insert a text block from the block picker", but go ahead change that if you think that something else is more appropriate.

Thanks for updating it @mchowning, I think high priority makes more sense as it's happening more often 🙇 . I'm also going to update the title and description of the issue to reflect this change.

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>

annezazu · 2023-12-19T16:09:22Z

I'm doing a sweep of high priority issues for the Gutenberg repo and noticed this issue has greatly stalled out despite the label. To keep these issues actionable and relevant, I've removed this high priority label. Feel free to add back if you all are able to replicate, confirm the widespread nature of the problem, and believe quick action is needed.

dcalhoun · 2023-12-19T16:14:34Z

👋🏻 @fluiddot @geriux. Do the recent usability improvements in #57069 and #57070 improve this absent Android keyboard on block insertion issue at all?

geriux · 2023-12-19T16:45:57Z

Hey @dcalhoun 👋 this should be fixed with those recent changes so I'll close this ticket 🚀

dcalhoun added the Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) label Feb 16, 2021

dcalhoun mentioned this issue Feb 16, 2021

Release 1.47.0 wordpress-mobile/gutenberg-mobile#3155

Merged

3 tasks

mchowning added [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Bug An existing feature does not function as intended labels Feb 18, 2021

fluiddot mentioned this issue Mar 25, 2022

Block editor: Keyboard is not always shown when a new block is added wordpress-mobile/WordPress-Android#16167

Closed

fluiddot mentioned this issue Apr 5, 2022

Release 1.73.0 wordpress-mobile/gutenberg-mobile#4719

Merged

4 tasks

mchowning added [Priority] High Used to indicate top priority items that need quick attention and removed [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later labels Apr 5, 2022

fluiddot changed the title ~~Android keyboard is occasionally not displayed when adding a block~~ Android keyboard is not displayed when adding a block Apr 5, 2022

dcalhoun mentioned this issue Oct 14, 2022

fix: Avoid iOS block appender focus loop #44988

Closed

annezazu removed the [Priority] High Used to indicate top priority items that need quick attention label Dec 19, 2023

geriux closed this as completed Dec 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Android keyboard is not displayed when adding a block #29048

Android keyboard is not displayed when adding a block #29048

dcalhoun commented Feb 16, 2021 •

edited by fluiddot

Loading

dcalhoun commented Feb 16, 2021

fluiddot commented Apr 5, 2022

mchowning commented Apr 5, 2022

fluiddot commented Apr 5, 2022

annezazu commented Dec 19, 2023

dcalhoun commented Dec 19, 2023

geriux commented Dec 19, 2023

Android keyboard is not displayed when adding a block #29048

Android keyboard is not displayed when adding a block #29048

Comments

dcalhoun commented Feb 16, 2021 • edited by fluiddot Loading

Description

Step-by-step reproduction instructions

Expected behaviour

Actual behaviour

Screenshots or screen recording (optional)

Android

WordPress information

Device information

dcalhoun commented Feb 16, 2021

fluiddot commented Apr 5, 2022

mchowning commented Apr 5, 2022

fluiddot commented Apr 5, 2022

annezazu commented Dec 19, 2023

dcalhoun commented Dec 19, 2023

geriux commented Dec 19, 2023

dcalhoun commented Feb 16, 2021 •

edited by fluiddot

Loading