ChatScreen: Fix blank strip between compose box and keyboard on iOS#5564
ChatScreen: Fix blank strip between compose box and keyboard on iOS#5564chrisbobbe merged 1 commit intozulip:mainfrom
Conversation
chrisbobbe
added
a-iOS
a-layout
a-compose/send
| keyboardVerticalOffset={ | ||
| // This is a slight misuse of this prop: this value is not (to quote | ||
| // from the jsdoc) "How much the top of `KeyboardAvoider`'s layout | ||
| // *parent* is displaced downward from the top of the screen." That | ||
| // value would be zero. | ||
| // | ||
| // This addresses an issue where the strip that covers the bottom | ||
| // inset would scoot up above the keyboard with the rest of the | ||
| // compose box when the keyboard opens, leaving a blank strip of | ||
| // wasted space ( #3370). We haven't yet found a better way to avoid | ||
| // this, while still letting `ComposeBox` control how it occupies | ||
| // the inset (like how our header components occupy the top inset). | ||
| -useSafeAreaInsets().bottom | ||
| } |
There was a problem hiding this comment.
Hmm fascinating.
What does this look like when the keyboard isn't open? Does it cause the compose box to be lowered into the inset area, where it's obscured at the bottom? On its face it seems like it would.
It looks like this would become our one use of this keyboardVerticalOffset prop. If something like this is right, then perhaps the jsdoc on it isn't right and should be edited? It looks like we added that prop in 70eca07 / #4683 and have never yet used it in main. (It subsequently appeared in #4893, in a previous revision of this same commit.)
chrisbobbe
force-pushed
the
pr-fix-ios-blank-strip
branch
from
583a5ca to
281bcdc
Compare
|
Thanks for the review, and for finding a better solution just now in discussion in the office! 🙂 Revision pushed. |
gnprice
left a comment
gnprice
left a comment
There was a problem hiding this comment.
Thanks! Looks good -- small comment-comments below.
| * Use this when a child component uses SafeAreaView to pad the bottom | ||
| * inset, and you want the open keyboard to cover that padding. | ||
| * | ||
| * (SafeAreaView has a bug where it applies a constant padding no matter | ||
| * where it's positioned onscreen -- so in particular, if you ask for | ||
| * bottom padding, you'll get bottom padding even when KeyboardAvoider | ||
| * pushes the SafeAreaView up and out of the bottom inset.) |
| compensateOverpadding={ | ||
| // We let the compose box pad the bottom inset. | ||
| showComposeBox |
There was a problem hiding this comment.
Let's have a comment at the use of SafeAreaView in ComposeBox, too, saying that when the keyboard is open it's compensated for here.
| keyboardVerticalOffset={ | ||
| keyboardVerticalOffset + (compensateOverpadding ? -bottomInsetHeight : 0) |
There was a problem hiding this comment.
At this spot we're abusing the keyboardVerticalOffset prop of KeyboardAvoider -- what we're doing doesn't match its intended interface. So a comment to acknowledge that would be helpful, letting the reader know the mismatch is intentional and they're not just missing something. Like this, say:
| keyboardVerticalOffset={ | |
| keyboardVerticalOffset + (compensateOverpadding ? -bottomInsetHeight : 0) | |
| keyboardVerticalOffset={ | |
| keyboardVerticalOffset | |
| // A negative term here reduces the bottom inset we use for the child, | |
| // when the keyboard is open, so that the keyboard covers its bottom padding. | |
| + (compensateOverpadding ? -bottomInsetHeight : 0) |
chrisbobbe
force-pushed
the
pr-fix-ios-blank-strip
branch
from
281bcdc to
9ed6fd3
Compare
|
Thanks for the review! Revision pushed. |
|
Cool, the screenshot looks good to me! |
chrisbobbe
force-pushed
the
pr-fix-ios-blank-strip
branch
from
9ed6fd3 to
ee6630e
Compare
|
Merging with that fix, thanks for the review! |
chrisbobbe
force-pushed
the
pr-fix-ios-blank-strip
branch
from
ee6630e to
cbdc035
Compare
3 participants
Before/after:
Fixes: #3370