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.

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

iOS - Add ability to scroll to caret when typing goes under the keyboard #474

Merged
merged 10 commits into from
Jan 17, 2019

Conversation

pinarol
Copy link
Contributor

@pinarol pinarol commented Jan 15, 2019

Fixes: #464

This PR adds ability to follow caret when typing goes under the keyboard.

caret-follow3

caret-follow4

WPiOS PR: wordpress-mobile/WordPress-iOS#10826

Depends on PRs:
wordpress-mobile/react-native-aztec#112
WordPress/gutenberg#13323
wordpress-mobile/react-native-keyboard-aware-scroll-view#3

To Test

Prerequisites

  • Run yarn install <-- important yarn start yarn ios
  • Might need to remember the scrolling mechanism, reviewers can refer to the diagram from this PR.

Test 1 - Paragraph block - Add new text to end

  • Add new text at the end of the block until caret goes under the keyboard
  • Verify that it automatically refreshes the scroll position to show the caret and also the block toolbar

Note: it is also possible to scroll for only showing the caret without the block toolbar, I wanted to keep this consistent with what happens when we open the keyboard, however, we can still change it for typing case.

Test 2 - Paragraph block - Add new text in the middle

  • Add new text in the middle of the block until caret goes under the keyboard
  • Verify that it automatically refreshes the scroll position to show the caret

Test 3 - Repeat tests 1,2 for Heading block

Test 4 - Android

We don't expect any change on Android side.

  • Run yarn android
  • Make sure Android example app opens successfully and you can do basic operations on it

Copy link
Contributor

@etoledom etoledom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @pinarol for taking care of this. Great job!

Code looks good but I have one concern that I pointed out as a code comment.

If I understand correctly, what is happening is:

  • Aztec iOS wrapper adds the caret position info to the onSelectionChange bubbling event.
  • Aztec JS receive the event and calls a new onCaretVerticalPositionChange function added to its props.
  • Any component using aztec (rich-text, heading, paragraph) implement this props by passing it through.
  • Block holder also passes it through in the same way.
  • Block manager implement block-holder's onCaretVerticalPositionChange props calling a function on our keyboard-aware-flat-list.
  • keyboard-aware-flat-list reuses the logic used to scroll on focus to scroll te caret back to a visible area when it's necessary.

I did found an issue testing on WPiOS. At the beginning I wasn't sure what was the problem but I think it's related to the iOS version. Testing on iOS 11 (used by default by yarn ios it works fine, but using iOS 12, this happens:

scrolling

Apart of that, I noticed that the behavior is a bit different than how it works on Android.
With this implementation, when typing at the end of the block, on iOS the content will scroll until the inline toolbar is visible, as it does on focus (that's nice I think). On Android, it will scroll until the caret is visible but will keep the inline toolbar hidden (feels a bit more expected at the beginning)

caret-follow4

It would be good to make them both behave in the same way. I'm personally OK with any.
This is probably something to keep in mind for the future, and not to solve now.
Any opinion @iamthomasbishop ?

return;
}
if ( previousCaretY ) { //if this is not the first tap
this.scrollViewRef.props.refreshScrollForField( targetId );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be called just when running iOS, right? (referring to onCaretVerticalPositionChange)
If that's the case, wouldn't it be a bit confusing for someone from Android trying to understand/debug scroll behavior?

In the other hand, I'm not sure how could this be done differently 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes the scrollViewRef is null for Android and it will never run this code for Android. Maybe we can make it more explicit by putting an isIOS check, I can't think of any other solution either :(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved handling of this event to platform specific files, at least we can make it more obvious this way, let me know what you think

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

It would be good to make them both behave in the same way. I'm personally OK with any.
This is probably something to keep in mind for the future, and not to solve now.
Any opinion @iamthomasbishop ?

We can do this easily, actually I had already put a note about this in the PR description:

Note: it is also possible to scroll for only showing the caret without the block toolbar, I wanted to keep this consistent with what happens when we open the keyboard, however, we can still change it for typing case.

So it behaves that way only if caret is at the last line. I'll go and change it and request a second try from you @etoledom I can take it back if you feel like previous one was better, it is an easy change.

Just adding this link here to remind the decision mechanism of auto scrolling upon keyboard opening.

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

If I understand correctly, what is happening is:

All correct @etoledom

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

I did found an issue testing on WPiOS. At the beginning I wasn't sure what was the problem but I think it's related to the iOS version. Testing on iOS 11 (used by default by yarn ios it works fine, but using iOS 12, this happens:

Looking now

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

I did found an issue testing on WPiOS. At the beginning I wasn't sure what was the problem but I think it's related to the iOS version. Testing on iOS 11 (used by default by yarn ios it works fine, but using iOS 12, this happens:

Solved this one, ready for another check @etoledom

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

Just a small reminder before testing: you'll need to run yarn install again @etoledom

@pinarol
Copy link
Contributor Author

pinarol commented Jan 16, 2019

I've also made changes for this one #474 (comment)

# Conflicts:
#	src/block-management/block-holder.js
#	src/block-management/block-manager.js
Copy link
Contributor

@etoledom etoledom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @pinarol - The updates look good!

Personally, scrolling just to show the caret feels more natural in this particular case. But I still would go with what @iamthomasbishop says is the best. 😁

The scrolling problem on iOS 12 seems to be fixed 🎉
I did find another issue, probably related:

scrolling-new-line

This also happens only on iOS 12, and when the block is using all the viewable area.

As a tip, you can run this yarn ios --simulator "iPhone XS" to easily get the example project running on iOS 12.

@iamthomasbishop
Copy link
Contributor

iamthomasbishop commented Jan 16, 2019

when typing at the end of the block, on iOS the content will scroll until the inline toolbar is visible, as it does on focus (that's nice I think)

I agree with this – My hope is that the inline toolbar is visible in most cases, this one included. When I focus a block, it should align to the bottom of the inline toolbar, and as I proceed to type beyond that line, it should adjust to do the same with the added line.

I also agree that it should be the same between both platforms.

@pinarol
Copy link
Contributor Author

pinarol commented Jan 17, 2019

@etoledom I think that issue is related with #463 I've linked your comment under that issue. I'll be looking into it when I start to work on that.

Also I have reverted back the scrolling behavior to include the inner toolbar as @iamthomasbishop suggested. @iamthomasbishop you can compare 2 behaviors by trying iOS and Android at the same time, please let me once you have a chance to try it with the new build and if you think that sth needs to be changed don't hesitate to reach out! ( My opinions usually tend to change after trying :) )

Copy link
Contributor

@etoledom etoledom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the last issue was moved to another ticket, let's move on and 🚢 this.
Tested the last change on scrolling behavior and is ✅

Great job @pinarol! Thanks for taking care of this 🎉

Let's update the references before merging :)

@pinarol pinarol merged commit ad6ba7e into develop Jan 17, 2019
@pinarol pinarol deleted the issue/464-autoscroll-to-cursor branch January 17, 2019 18:42
@iamthomasbishop
Copy link
Contributor

Just got a chance to take a test build for a spin. While I think there are a couple of things that we should do to further improve the interaction, this particular PR seems to solve the originally stated issue. I'm fine with shipping this and making further refinements separately.

Related PR on Android: #427 , as we should make sure Android behavior is matching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants