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

Focus Loop when deleting content and blocks #302

Closed
daniloercoli opened this issue Nov 30, 2018 · 3 comments
Closed

Focus Loop when deleting content and blocks #302

daniloercoli opened this issue Nov 30, 2018 · 3 comments
Assignees
@daniloercoli

Comments

@daniloercoli
Copy link
Contributor

daniloercoli commented Nov 30, 2018 •
edited
Loading

I can reproduce both on emulators and real devices a focus loop that makes the editor (and the app) unusable, since you cannot do much to recover from it, except looking at the screen and see the logic giving and moving the focus between blocks in the editor.

Made a video of the problem https://cloudup.com/chW89JFycRS

Steps to reproduce the issue:

  • Start the demo app
  • Tap into the first Para block (Hello World!)
  • Tap Enter and add a new empty block after
  • Write something in the block
  • Repeat the step above by adding more blocks quickly

Sometime the issue start here, otherwise:

  • on the last added block, press delete and keep it pressing for remove the content and the block.

I was also able to reproduce the issue by just adding one block and deleting it.
@koke koke mentioned this issue Nov 30, 2018
Closed
12 tasks
@daniloercoli
Copy link
Contributor Author

cc @mzorz

@mzorz
Copy link
Contributor

mzorz commented Nov 30, 2018

I can reproduce both on emulators and real devices a focus loop

Interesting! Can you add steps to reproduce here please? thanks

@daniloercoli
Copy link
Contributor Author

Added testing steps in the description.

@daniloercoli daniloercoli self-assigned this Dec 3, 2018
This was referenced Dec 4, 2018
Merged
Merged
@etoledom etoledom mentioned this issue Mar 19, 2019
Closed
etoledom added a commit that referenced this issue Mar 26, 2019
@etoledom
AztecView: Propagete onFocus event from Native on iOS.
b93c092 
And keep avoiding that propagetion on Android to avoid regression of #302
dcalhoun added a commit to WordPress/gutenberg 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 to WordPress/gutenberg 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 to WordPress/gutenberg 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 to WordPress/gutenberg 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 <438664+dcalhoun@users.noreply.github.com>
geriux pushed a commit to WordPress/gutenberg 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 <438664+dcalhoun@users.noreply.github.com>
geriux pushed a commit to WordPress/gutenberg 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 <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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@daniloercoli daniloercoli

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@daniloercoli @mzorz