-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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.
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
[Mobile] Remove Keyboard Aware Flatlist #48791
Conversation
- Remove usage of onCaretVerticalPositionChange - Add support for adding a listener when the caret Y coordinate position changes
…AutoScrollEnabled in the state of the component
…the caret position's changes for iOS
- Removes usage of the react-native-keyboard-aware-scroll-view library - Adds custom implementation to scroll to the focused TextInput element
Size Change: 0 B Total Size: 1.37 MB ℹ️ View Unchanged
|
Flaky tests detected in a080674. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4656911993
|
…rs and prevent scrolling if the scroll reference doesn't exist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! The experience seems to be a solid improvement. 👏🏻
This is unfamiliar, complex code to me, so it will likely take me a bit to review and comprehend the logic. I plan to review again next week, but wanted to provide initial findings and questions in the meantime. Of course, if others are more familiar with this code, don't feel a need to await my specific review.
I noticed that with these changes, the calculations for larger text blocks — e.g. Heading blocks — feels a bit off. The Heading block text is partially obscured. I didn't test other blocks with larger text.
RPReplay_Final1678482187.MP4
packages/components/src/mobile/keyboard-aware-flat-list/index.ios.js
Outdated
Show resolved
Hide resolved
packages/components/src/mobile/keyboard-aware-flat-list/index.ios.js
Outdated
Show resolved
Hide resolved
packages/react-native-editor/__device-tests__/gutenberg-editor-block-insertion-@canary.test.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested using long paragraphs and noticed that the scroll sometimes doesn't go to the proper position, specifically I found the following issues:
1 - Moving the caret to the first line of a block moves the scroll to the wrong position
As you can see in the video, when I move the caret to the first line (i.e. caretY = 0
) the scroll moves to a different position than where the caret is.
Kapture.2023-03-14.at.11.38.19.mp4
2- Moving the caret up doesn't move the scroll
Moving the caret down moves the scroll to keep the caret visible on the screen. However, moving the caret up doesn't have this behavior.
Kapture.2023-03-14.at.11.44.18.mp4
packages/components/src/mobile/keyboard-aware-flat-list/index.ios.js
Outdated
Show resolved
Hide resolved
if ( scrollEnabled ) { | ||
RCTAztecView.InputState.addCaretChangeListener( onCaretChange ); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If scrollEnabled
is set to false
, the caret change listener won't be removed upon component unmount. Hence, we could consider removing it in this case:
if ( scrollEnabled ) { | |
RCTAztecView.InputState.addCaretChangeListener( onCaretChange ); | |
} | |
if ( scrollEnabled ) { | |
RCTAztecView.InputState.addCaretChangeListener( onCaretChange ); | |
} else { | |
RCTAztecView.InputState.removeCaretChangeListener( onCaretChange ); | |
} |
const onCaretChange = useCallback( | ||
( { caretY } ) => { | ||
const isFocused = | ||
!! RCTAztecView.InputState.getCurrentFocusedElement(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could check the focus status by calling the isFocused
function instead, WDYT?
!! RCTAztecView.InputState.getCurrentFocusedElement(); | |
!! RCTAztecView.InputState.isFocused(); |
…veral hooks, it also fixes a few cases that weren't working correctly.
Hey @fluiddot thank you again for testing and I'm sorry I missed the most important issue which is what this PR is supposed to be fixing 😅 I've introduced a few changes to solve the issues you reported:
Test casesMoving the caret to the first line of a block moves the scroll to the wrong positionTestIssue1.mp4Moving the caret up doesn't move the scrollTestIssue2.mp4Splitting a long paragraph doesn't scroll to the correct positionTestIssue3.mp4Selecting text after opening/closing the keyboard doesn't scroll to the correct positionTestIssue4.movEditor jumps when inserting a new blockTestIssue5.mp4Adding a text block should scroll and auto-focusTestIssue6.mp4Opening the inserter with a text block focused and closing the inserter shouldn't reset the scrollTestIssue7.mp4Landscape 1TestIssue8.mp4Landscape 2TestIssue9.mp4iPad 1 (Hardware Keyboard)TestIssueiPad1.mp4iPad 2 (Hardware and external Keyboard)TestIssueiPad2.mp4Hopefully, all issues are now solved, let me know! Thanks again! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎊 ! Awesome job @geriux 🏅 !
I tested again with the last changes and confirm that they are addressed 🎊 :
- [RNMobile] [iOS] Editor jumps when inserting a new block #40029 ✅
- [iOS] Media & Text Block: Keyboard covers the text field after rotating from Landscape to Portrait wordpress-mobile/gutenberg-mobile#4894 ✅
Apart from the tests, I added some comments but none should block the PR. From my side the PR is ready ✅ 🥳 .
UPDATE: As a side note, it would be great to update the CHANGELOG to include this change as it's a user-facing change.
packages/components/src/mobile/keyboard-aware-flat-list/test/use-keyboard-offset.native.js
Outdated
Show resolved
Hide resolved
packages/components/src/mobile/keyboard-aware-flat-list/test/use-keyboard-offset.native.js
Show resolved
Hide resolved
packages/components/src/mobile/keyboard-aware-flat-list/test/use-keyboard-offset.native.js
Show resolved
Hide resolved
clearTimeout( timeoutRef.current ); | ||
timeoutRef.current = setTimeout( () => { | ||
setKeyboardOffset( 0 ); | ||
}, 200 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that 200ms would be enough to wait for a change in the focus, but I'm wondering if it will cover the case of slow/old devices. In the future, it would be great to investigate if we can prevent the keyboard to open/close when the focus changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely, I think that would be a great improvement for the mobile editor!
packages/components/src/mobile/keyboard-aware-flat-list/use-keyboard-offset.native.js
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stopping by to say "thank you" to both of you for carrying this forward so well while I was unable to dedicate time for reviewing. The refactor to separate logic into individual Hooks improves comprehensibility immensely. I think this PR is a big improvement. Thank you for completing that. 🙇🏻
I left a couple of comments, but none are blockers.
packages/components/src/mobile/keyboard-aware-flat-list/test/use-keyboard-offset.native.js
Show resolved
Hide resolved
packages/components/src/mobile/keyboard-aware-flat-list/use-text-input-offset.native.js
Outdated
Show resolved
Hide resolved
…nt keyboard height end coordinates to check different offset value
Thank you all for your valuable feedback and time for the reviews and testing! I can't wait to ship this 🚢 I'll start merging the PRs 🎉 🚀 |
4f843a6
to
6e7556f
Compare
00e9a18
to
a519085
Compare
packages/components/src/mobile/keyboard-aware-flat-list/use-text-input-offset.native.js
Outdated
Show resolved
Hide resolved
See Gutenberg commit 4454e829372874130c29b62ba9f04e03ea180480, WordPress/gutenberg#48791
See Gutenberg commit 4454e829372874130c29b62ba9f04e03ea180480, WordPress/gutenberg#48791
Fixes #40029
Fixes wordpress-mobile/gutenberg-mobile#4894
Related PRs:
What?
This PR fixes a high-priority bug on iOS where the scroll would jump to the top and then scroll back to the currently focused text input.
Why?
Because it affects the basic writing flow, and after several attempts to try to workaround that library I went to a different route by implementing it within the project and stop using our fork for react-native-keyboard-aware-scroll-view.
How?
BlockList
OnCaretVerticalPositionChange
context and provider since it won't be used anymore.KeyboardAwareFlatList
component.isFloatingToolbarVisible
since it was not returning the correct value.RichText (Block-editor)
useNativeProps
since it won't be used anymore.KeyboardAwareFlatList
This component got a full refactor, it will leverage on the
InputState
fromRCTAztecView
for different cases by using new hooks:scrollToTextInputOffset
function to scroll to the currently focused TextInput depending on where the caret is placed.VisualEditor
isAutoScrollEnabled
state value which is no longer needed.AztecInputState
AztecView
onCaretVerticalPositionChange
and now it will only set the value inAztecInputState
.E2E Tests
getTitleElement
helper and the block insertion canary test.Testing Instructions
Test case 1
Test case 2
Testing Instructions for Keyboard
N/A
Screenshots or screencast
## Test case 1
TestCase1Before.mov
TestCase1After.mov
## Test case 2
TestCase2Before.mov
TestCase2After.mov