Additional alignment of focus and selection logic with the web's #1076
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For better coordination with animations. This way the RichText does get focus properly when for example a new paragraph block is added.
5 tasks
That way, the view doesn't jump around when merging blocks.
No need for fixed delay, at least when testing this on a Pixel 2XL.
|
👋 @daniloercoli , I removed the delay |
mkevins
reviewed
Jun 6, 2019
...native-aztec/android/src/main/java/org/wordpress/mobile/ReactNativeAztec/ReactAztecText.java
Show resolved
Hide resolved
|
Hey @hypest it's offtopic but just curious. Is it possible to do a similar approach with |
mkevins
reviewed
Jun 6, 2019
|
Hey @hypest, nice work here :) Here are the issues that I have found and which I can't confirm on develop branch. 1. Red screen
Video:
Result: Red screen
2. Keyboard not dismissed
Video:
Result: Keyboard is not dismissed Issues that don't have a clear scenario (and maybe not affected by this PR)
|
|
I was able to reproduce the above red screen on the demo app. I cannot reproduce the same on develop. I was able to reproduce it with less steps. Simply moving a rich text block and then selecting it (tap anywhere in the recently moved block) seems to trigger the error. I reproduced this on heading, paragraph, and image caption. If a different block is tapped after moving the block, and then the moved block is tapped, the error does not occur. Here is the logcat: |
1 task
|
I've addressed the crash on selection with WordPress/gutenberg@c034c1a. |
|
I have tested this via demo app and the crash has been fixed. 🎉 Also:
I agree, this is looking and feeling a lot better after this fix. |
|
Thanks for the review @mkevins ! FWIW, I'm still trying to address the |
|
I did a tests run on iOS and it looks good! Tried to reproduce the issues mentioned above and I couldn't. I also test various scenarios and everything seems to be in order on iOS 👍 |
|
If everyone is OK, I'd propose to update this PR from develop and merge, leaving the UX issues Marko brought up to follow up PR. Cool? |
|
Hey, @hypest let me try to test if from my side again, I am having some problems with building the WPAndroid due to the latest changes on develop. update: let me try from |
|
Hey @hypest, I can't reproduce above issues on demo application, so I guess we are ok to merge this one :) |
|
Thanks y'all! I'll continue with merging 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1029
Gutenberg PR: WordPress/gutenberg#15999
This PR makes changes to the Aztec wrapper (Android) as well as the RN app to bring it closer to the web as far as focus and selection logic goes.
Important changes:
Try to avoid having Aztec (at the wrapper level and down) request focus automatically. We rely on the JS logic to do that.
setFocusableInTouchMode,setFocusableis set tofalseuntil Aztec needs to receive focus. Also setting it to false when Aztec loses focus.Completely removed the
isSelected()prop since the component should not use it as a flag to request focusSchedule a
requestRectangleOnScreento scroll into viewWhen creating a new RichText based block, Aztec receives focus OK but the container doesn't seem to get scrolled to make sure the edit box is in the viewport. https://github.com/wordpress-mobile/gutenberg-mobile/pull/1076/files#diff-5693404c4c8f8d757cd298cc5aabc561R185 asks the system to bring the caret into the viewport. In a future iteration of this logic, we should try to bring the whole block view into the viewport.
Schedule the
showSoftKeyboardto happen on a next frameRemove the 500ms delay for onContentSizeChange and just schedule it for next frame. This will actually dramatically improve the performance perception of the editor on Android, making the writing flow smoother. There's still the visible glitch where blocks start with minimum height and then expand though and fixing that (separate PR) will also greatly benefit the performance.
No need to try blurring other components in
block-holder's onFocus. Component will self-blur via https://github.com/WordPress/gutenberg/pull/15999/files#diff-4828a21853e899e5a36faecfa96d83e8R753Align block-holder's
withDispatchwith the web's https://github.com/wordpress-mobile/gutenberg-mobile/pull/1076/files#diff-2004b9687d71de0f0a9816269bb4a6a2R276To test:
Also, test focus and selection in general, it should work as expected.
Known issue: at least on Android v7.1.2, sometimes a paragraph block will still have the caret blinking inside it even though a different block might be selected. This seems to be an issue with how the accessibility flag is implemented on ReactNative, in combination with the Android OS underneath it. In particular, setting a block to
accessible=trueseems to cause a request for focus. Other Android OS versions (at least 8.0 and 9.0) don't seem to exhibit that behavior.Update release notes:
RELEASE-NOTES.txt.