-
Notifications
You must be signed in to change notification settings - Fork 24.5k
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
Fix subclipping view removal #48329
Fix subclipping view removal #48329
Conversation
This pull request was exported from Phabricator. Differential Revision: D67398971 |
Heads up to @kkafar |
Summary: With the call to `removeView()` removed from `ReactViewClippingManager` in facebook#47634, we're seeing views erroneously sticking around in the layout. While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501): ``` public void removeView(View view) { if (removeViewInternal(view)) { --> requestLayout(); --> invalidate(true); } } ``` To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout. Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt() Reviewed By: javache Differential Revision: D67398971
529e528
to
958f108
Compare
This pull request was exported from Phabricator. Differential Revision: D67398971 |
This pull request has been merged in 0683206. |
This pull request was successfully merged by Thomas Nardone in 0683206 When will my fix make it into a release? | How to file a pick request? |
Thanks! |
Summary: Pull Request resolved: #48329 With the call to `removeView()` removed from `ReactViewClippingManager` in #47634, we're seeing views erroneously sticking around in the layout. While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501): ``` public void removeView(View view) { if (removeViewInternal(view)) { --> requestLayout(); --> invalidate(true); } } ``` To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout. Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt() Reviewed By: javache Differential Revision: D67398971 fbshipit-source-id: b100db468cc3be6ddc6edd6c6d078a8a0b59a2c1
This pull request was successfully merged by Thomas Nardone in e3970a4 When will my fix make it into a release? | How to file a pick request? |
Summary: Pull Request resolved: #48329 With the call to `removeView()` removed from `ReactViewClippingManager` in #47634, we're seeing views erroneously sticking around in the layout. While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501): ``` public void removeView(View view) { if (removeViewInternal(view)) { --> requestLayout(); --> invalidate(true); } } ``` To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout. Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt() Reviewed By: javache Differential Revision: D67398971 fbshipit-source-id: b100db468cc3be6ddc6edd6c6d078a8a0b59a2c1
## Description This PR removes the workaround introduced in series of PRs (listed chronologically here): 1. #2307 2. #2383 3. #2495 4. #2531 For detailed description of error mechanism and broader discussion please refer to: 1. [my comment on #2495](#2495 (comment)), 2. [my fix to RN core](facebook/react-native#47634) tldr: When popping screen on Fabric we marked the views as "transitioning" and this led to view being effectively miscounted during removal by view groups that supported react-native's subview clipping mechanism. The issue has been present most likely in every version of the library when running on Android & Fabric, but it arose few months ago due to broader adoption of the new architecture. facebook/react-native#47634 is supposed to fix the underlying issue in `react-native's` core. ## Changes Removed the workaround code from `Screen` implementation on Android. The * facebook/react-native#47634 has been released with 0.77.0-rc.3 and followup small fixup: * facebook/react-native#48329 has been released with 0.77.0-rc.4. Therefore, with landing this PR we should limit our support on Fabric to 0.77.0. ## Test code and steps to reproduce `Test2282` - note that there are few testing variants available there, you just need to comment (out) some parts of the code. ## Checklist - [x] Included code example that can be used to test this change - [ ] Ensured that CI passes
Summary:
With the call to
removeView()
removed fromReactViewClippingManager
in #47634, we're seeing views erroneously sticking around in the layout.While
removeViewWithSubviewClippingEnabled()
callsremoveViewsInLayout()
, it does not trigger the corresponding side effects of removeView():To compensate, add an
invalidate()
afterremoveViewsInLayout()
.Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt()
Differential Revision: D67398971