Skip to content

Fix text becoming invisible in HTML editor#755

Merged
pinarol merged 8 commits intodevelopfrom
issue/744-html-text-invisible
Mar 19, 2019
Merged

Fix text becoming invisible in HTML editor#755
pinarol merged 8 commits intodevelopfrom
issue/744-html-text-invisible

Conversation

@pinarol
Copy link
Copy Markdown
Contributor

@pinarol pinarol commented Mar 18, 2019

To Fix: #744

Root cause analysis and the solution proposal can be found in the issue. ^^^

To fix the anomalies we are removing the outer ScrollView and letting the TextView scroll in its own bounds, thus, letting iOS system make the required optimizations.

After the fix:

iOS:
ios-longtext-html-mode-after

Android:
android-longtext-html-mode-after

Implementation Details

Since we can not use keyboardDismissMode prop anymore I've added a pan gesture to detect when the user drags down and close the keyboard with it. This is active for iOS only, keyboardDismissMode='interactive' was also an iOS only behavior.

To Test

  • Open the iOS example app with yarn ios
  • Switch to html mode
  • Verify that text is visible
  • Scroll down to the bottom
  • Verify that the whole content is visible
  • Drag down to close the keyboard (iOS only)

Repeat tests for following platforms:

WPiOS
WPAndroid(Except for draggin down to close the keyboard)

Try using also a non iPhone X series device like iPhone 8.

cc @daniloercoli

@pinarol pinarol added this to the v1.2 milestone Mar 18, 2019
@pinarol pinarol self-assigned this Mar 18, 2019
@pinarol pinarol requested a review from etoledom March 18, 2019 11:13
@pinarol
Copy link
Copy Markdown
Contributor Author

pinarol commented Mar 18, 2019

hey @daniloercoli 👋When I first switch to html mode on WPAndroid app, the scroll position is at the bottom of the TextInput, I couldn't figure out why this might be happening, any ideas?

@pinarol
Copy link
Copy Markdown
Contributor Author

pinarol commented Mar 18, 2019

@daniloercoli There's another thing I couldn't figure out on Android side. There's an extra top padding on the html content, and I couldn't detect where it comes from. When I inspect it, it shouldn't be there according to values, could I be missing sth?

Screenshot_1552908232

Screenshot_1552908210

Copy link
Copy Markdown
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 for tackling this @pinarol !

It works well on both iOS and Android.
It's a pity that we lost the interactive keyboard dismissal but this fix is 💯 more important.

The pan-to-dismiss I think feels good enough, and the distance to drag for the dismiss also feels correct.

In general this HTML view needs a lot of more ❤️ I guess 😁

I added a couple of code comments, otherwise I'm happy to ✅
Great job! 🎉


this.panResponder = PanResponder.create( {
onStartShouldSetPanResponder: ( ) => true,
onStartShouldSetPanResponderCapture: ( ) => true,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think that just the onStartShouldSetPanResponderCapture is necessary for the pan responder to capture the event (and trigger onPanResponderMove).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

it looks so yes 👍

keyboardDismissMode="interactive" >
<View
{ ...( this.isIOS ? { ...this.panResponder.panHandlers } : {} ) }
style={ { flex: 1 } } >
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do you think it's a good idea to remove this extra wrapper view and add the panHandlers directly to KeyboardAvoidingView?
It seems to work well but I wonder if there's a benefit on keeping this wrapper.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

there's no benefit currently so I removed

ref={ ( textInput ) => this.textInput = textInput }
textAlignVertical="top"
multiline
style={ { ...styles.htmlView, height: this.state.contentHeight + 16 } }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

contentHeight is not being used anymore. It would be good to remove it from the state.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

And being at it, it looks like the textInput ref is also not being used anymore. This might be a good opportunity to clean it up :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

All true!

As far as I see textInput was even not used before this PR :)

@etoledom
Copy link
Copy Markdown
Contributor

etoledom commented Mar 18, 2019

When I first switch to html mode on WPAndroid app, the scroll position is at the bottom of the TextInput

I believe this has been the case from the beginning of times 🤔 I remember giving this a try long time ago without good results.

@pinarol
Copy link
Copy Markdown
Contributor Author

pinarol commented Mar 18, 2019

@etoledom Ready for another look

@daniloercoli
Copy link
Copy Markdown
Contributor

When I first switch to html mode on WPAndroid app, the scroll position is at the bottom of the TextInput

You mean that the caret is at the end of the text @pinarol ? If that's the case, it is the default behavior on Android, the caret is positioned at the end of the text on focus. We've made changes in the wrapper to move the caret at the beginning of a block onfocus/split.

@pinarol
Copy link
Copy Markdown
Contributor Author

pinarol commented Mar 18, 2019

You mean that the caret is at the end of the text @pinarol ? If that's the case, it is the default behavior on Android, the caret is positioned at the end of the text on focus. We've made changes in the wrapper to move the caret at the beginning of a block onfocus/split.

I see the caret only if I tap to somewhere, and yes when I tap, the caret appears at the end. If that's the default behavior on Android I wouldn't be worried though.

Copy link
Copy Markdown
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 for the updates! 🎉

@pinarol
Copy link
Copy Markdown
Contributor Author

pinarol commented Mar 19, 2019

Will merge this since the padding issue in this comment doesn't look related with this PR. I removed the top padding of html content and the padding is still there on Android so I am thinking there can be an inset value on native Android level? @daniloercoli if you think the other way feel free to send your feedbacks and I can open a new PR.

@pinarol pinarol merged commit 1af1a70 into develop Mar 19, 2019
@pinarol pinarol deleted the issue/744-html-text-invisible branch March 19, 2019 09:37
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.

[iOS]Text is invisible on HTML mode when content height is long enough

3 participants