Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Android keyboard is not displayed when adding a block #29048

Closed
dcalhoun opened this issue Feb 16, 2021 · 7 comments
Closed

Android keyboard is not displayed when adding a block #29048

dcalhoun opened this issue Feb 16, 2021 · 7 comments
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Type] Bug An existing feature does not function as intended

Comments

@dcalhoun
Copy link
Member

dcalhoun commented Feb 16, 2021 •
edited by fluiddot
Loading

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

  1. Launch Android app.
  2. Add new post.
  3. Add a paragraph block with text.
  4. 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
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 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 dcalhoun mentioned this issue Feb 16, 2021
Merged
3 tasks
@dcalhoun
Copy link
Member Author

This may be related or duplicative of #28748.

@mchowning 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 fluiddot mentioned this issue Mar 25, 2022
Closed
@fluiddot
Copy link
Contributor

fluiddot commented Apr 5, 2022

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?

@fluiddot fluiddot mentioned this issue Apr 5, 2022
Merged
4 tasks
@mchowning
Copy link
Contributor

@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.

@mchowning 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
Copy link
Contributor

fluiddot commented Apr 5, 2022

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.

@fluiddot 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 added a commit that referenced this issue Oct 14, 2022
@dcalhoun
fix: Avoid iOS block appender focus loop
de1d880 
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
@dcalhoun dcalhoun mentioned this issue Oct 14, 2022
Closed
geriux pushed a commit that referenced this issue Aug 2, 2023
@dcalhoun
fix: Avoid iOS block appender focus loop
5be930a 
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
geriux pushed a commit that referenced this issue Aug 2, 2023
@dcalhoun
fix: Avoid iOS block appender focus loop
5e37e0b 
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
geriux pushed a commit that referenced this issue Aug 3, 2023
@dcalhoun
Mobile - Fix iOS Focus loop for RichText components (#53217)
9020d4b 
* 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 <[email protected]>
geriux pushed a commit that referenced this issue Aug 3, 2023
@dcalhoun
Mobile - Fix iOS Focus loop for RichText components (#53217)
2b215b1 
* 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 <[email protected]>
geriux pushed a commit that referenced this issue Aug 3, 2023
@derekblank @fluiddot @dcalhoun
Mobile Release v1.100.2 (#53293)
af0beae 
* 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 <[email protected]>

---------

Co-authored-by: Derek Blank <[email protected]>
Co-authored-by: Carlos Garcia <[email protected]>
Co-authored-by: David Calhoun <[email protected]>
@annezazu annezazu removed the [Priority] High Used to indicate top priority items that need quick attention label Dec 19, 2023
@annezazu
Copy link
Contributor

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
Copy link
Member Author

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

@geriux
Copy link
Member

geriux commented Dec 19, 2023

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

@geriux geriux closed this as completed Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Type] Bug An existing feature does not function as intended
Projects
Mobile Apps
Status: Done
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dcalhoun @mchowning @geriux @fluiddot @annezazu