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

KeyboardAvoidingView does not work well with ScrollView's keyboardDismissMode set to interactive #31394

Closed
bjornlll opened this issue Apr 20, 2021 · 4 comments
Labels
Needs: Triage 🔍 Resolution: Locked This issue was locked by the bot.

Comments

@bjornlll
Copy link

bjornlll commented Apr 20, 2021

Screencast

Components used:

  • ScrollView with keyboardDismissMode set to interactive
  • InputAccessoryView for the sticky toolbar on top of the keyboard
  • KeyboardAvoidingView wrapped around the ScrollView, behavior set to position

Expected: As I scroll to gradually dismiss the keyboard, the KeyboardAvoidingView gradually adjusts the position of ScrollView. See WhatsApp or Telegram for proper implementation of what I'm trying to achieve.

What really happens: KeyboardAvoidingView does not gradually update the position of ScrollView. Instead, you get one position when we've half-dismissed the keyboard resulting in a rather unsmooth user experience.

This issue has previously been covered #13073 but the issue was closed since, for the author's purpose, his problem had been solved. The root cause - this - however, is not solved.

Telegram's implementation (what I want to achieve)
2021-04-21-14.23.12.gif

@bjornlll bjornlll changed the title KeyboardAvoidingView does not work well with ScrollView keyboardDismissMode's interactive KeyboardAvoidingView does not work well with ScrollView's keyboardDismissMode set to interactive Apr 20, 2021
@bjornlll
Copy link
Author

bjornlll commented Apr 21, 2021

It seems, if I understand this correctly, that the reason it's difficult to build a KeyboardAvoidingView that reacts to changes in height of the keyboard's position is that the events triggered by Keyboard do not provide granular enough feedback (see here).

Specifically, if these two events had provided updates when the keyboard is drag-closed, it wouldn't be too complicated to implement:

  • keyboardWillChangeFrame
  • keyboardDidChangeFrame

Had these two events fired whenever the height of the keyboard changes it'd been easily doable.

@mrousavy
Copy link
Contributor

see #31402

@bjornlll
Copy link
Author

see #31402

That's amazing @mrousavy! Thanks. I'll put that to use straight away.

@johnpawl
Copy link

I want to get back to android activity from react-native activity using backkey .

MainActivity.java

public class MainActivity extends AppCompatActivity {

Button button;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    button = (Button) findViewById(R.id.button);
    button.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            startRNPage();
        }
    });
}

private void startRNPage() {
    Intent intent = new Intent(this, ReactNativeActivity.class);
    startActivity(intent);
    finish();
}
}

ReactNativeActivity.java

public class ReactNativeActivity extends AppCompatActivity {
private ReactRootView mReactRootView;
private ReactInstanceManager mReactInstanceManager;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    SoLoader.init(this, false);

    mReactRootView = new ReactRootView(this);
    List<ReactPackage> packages = new PackageList(getApplication()).getPackages();
    // Packages that cannot be autolinked yet can be added manually here, for example:
    // packages.add(new MyReactNativePackage());
    // Remember to include them in `settings.gradle` and `app/build.gradle` too.

    

    mReactInstanceManager = ReactInstanceManager.builder()
    .setApplication(getApplication())
    .setCurrentActivity(this)
    .setBundleAssetName("index.android.bundle")
    .setJSMainModulePath("index")
    .addPackages(packages)
    .setUseDeveloperSupport(BuildConfig.DEBUG)
    .setInitialLifecycleState(LifecycleState.RESUMED)
    .build();
    // The string here (e.g. "MyReactNativeApp") has to match
    // the string in AppRegistry.registerComponent() in index.js
    mReactRootView.startReactApplication(mReactInstanceManager, "firstpro", null);

    setContentView(mReactRootView);
    }
@Override
public void onBackPressed() {
    if (mReactInstanceManager != null) {
        mReactInstanceManager.onBackPressed();
    } else {
      super.onBackPressed();
    }
}
}

I also tried the following code in ReactNativeActivity.java

public void onBackPressed() {
    if (mReactInstanceManager != null) {
        mReactInstanceManager.onBackPressed();
    } else {
        Intent intent = new Intent(this, MainActivity.class);
        startActivity(intent);
    }
}

If I pressed the back button it didn't get back to android activity.

How can I get back to android activity from react-native activity using backkey?

facebook-github-bot pushed a commit that referenced this issue Sep 25, 2021
Summary:
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.

With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.

* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)

## Changelog

* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)

Pull Request resolved: #31402

Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4

</td>
</table>

### "Why not just use `<KeyboardAvoidingView>`?"

<table>
<tr>
<th>Before (with <code>&lt;KeyboardAvoidingView&gt;</code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4

</td>
</table>

> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard

### Usage

```jsx
export const ChatPage = ({
  flatListProps,
  textInputProps
}: Props): React.ReactElement => (
  <>
    <FlatList
      {...flatListProps}
      keyboardDismissMode="interactive"
      automaticallyAdjustContentInsets={false}
      contentInsetAdjustmentBehavior="never"
      maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
      automaticallyAdjustKeyboardInsets={true}
    />
    <InputAccessoryView backgroundColor={colors.white}>
      <ChatInput {...textInputProps} />
    </InputAccessoryView>
  </>
);
```

## Related Issues

* Fixes #31394
* Fixes #13073

Reviewed By: yungsters

Differential Revision: D30015799

Pulled By: sota000

fbshipit-source-id: 9ccfb4b6d477da192a96db4cfa07c31a2d2cefcb
facebook-github-bot pushed a commit that referenced this issue Dec 6, 2021
Summary:
Retrying D30015799 (6e903b0) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.

With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.

* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)

## Changelog

* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)

Pull Request resolved: #31402

Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4

</td>
</table>

### "Why not just use `<KeyboardAvoidingView>`?"

<table>
<tr>
<th>Before (with <code>&lt;KeyboardAvoidingView&gt;</code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4

</td>
</table>

> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard

### Usage

```jsx
export const ChatPage = ({
  flatListProps,
  textInputProps
}: Props): React.ReactElement => (
  <>
    <FlatList
      {...flatListProps}
      keyboardDismissMode="interactive"
      automaticallyAdjustContentInsets={false}
      contentInsetAdjustmentBehavior="never"
      maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
      automaticallyAdjustKeyboardInsets={true}
    />
    <InputAccessoryView backgroundColor={colors.white}>
      <ChatInput {...textInputProps} />
    </InputAccessoryView>
  </>
);
```

## Related Issues

* Fixes #31394
* Fixes #13073

Reviewed By: yungsters

Differential Revision: D32578661

Pulled By: sota000

fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
arunim2405 pushed a commit to arunim2405/react-native that referenced this issue Dec 9, 2021
Summary:
Retrying D30015799 (facebook@6e903b0) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.

With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.

* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)

## Changelog

* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)

Pull Request resolved: facebook#31402

Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4

</td>
</table>

### "Why not just use `<KeyboardAvoidingView>`?"

<table>
<tr>
<th>Before (with <code>&lt;KeyboardAvoidingView&gt;</code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>

https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4

</td>

<td>

https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4

</td>
</table>

> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard

### Usage

```jsx
export const ChatPage = ({
  flatListProps,
  textInputProps
}: Props): React.ReactElement => (
  <>
    <FlatList
      {...flatListProps}
      keyboardDismissMode="interactive"
      automaticallyAdjustContentInsets={false}
      contentInsetAdjustmentBehavior="never"
      maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
      automaticallyAdjustKeyboardInsets={true}
    />
    <InputAccessoryView backgroundColor={colors.white}>
      <ChatInput {...textInputProps} />
    </InputAccessoryView>
  </>
);
```

## Related Issues

* Fixes facebook#31394
* Fixes facebook#13073

Reviewed By: yungsters

Differential Revision: D32578661

Pulled By: sota000

fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
@facebook facebook locked as resolved and limited conversation to collaborators Apr 24, 2022
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Apr 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs: Triage 🔍 Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants