-
-
Notifications
You must be signed in to change notification settings - Fork 521
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(iOS): header left and right layout on fabric #2248
Conversation
…-left-and-right-layout-fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks promising, I just left a question on "whys".
If you're to spend too much time investigating then I think it is not worth it & feel free to say so.
One general note: add link to this PR in comment above the line you added, because it is definitely not obvious why the line should be there.
@@ -72,6 +72,7 @@ - (void)updateLayoutMetrics:(const react::LayoutMetrics &)layoutMetrics | |||
self); | |||
} else { | |||
self.bounds = CGRect{CGPointZero, frame.size}; | |||
[self.superview layoutIfNeeded]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so we now trigger layout in the native superview (this is one of system views, beyond control of react) every time we receive a new frame from react.
The solution itself is ok & if it helps I'm for it, but do we have understanding why does it not work without this change? Especially that we do not have such code on Paper & I believe it works fine there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it does work fine on paper. It looks like the bounds of the subview are set properly but then the frame is given the old values unless we trigger a re-layout of the superview.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check what happens if you disable view recycling on header subviews in this PR? Im speaking with context of this issue on which we debated earlier today: #2232
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be the same issue of the views being swapped due to recycling pool working in stack manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turning off recycling does not fix this issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, after playing around with this & seeing no other solution I think we should proceed.
## Description This PR fixes the incorrect position of the custom header items when updating more than one option at the same time. The proposed solution let us remove the previous fix for a similar problem: #2248 which only fixed the issue on fabric. Fixes #432, #2231. ## Changes - forced re-layout of the navigation controller when subviews are updated - removed previous fix - updated `Test432` repro <!-- ## Screenshots / GIFs Here you can add screenshots / GIFs documenting your change. You can add before / after section if you're changing some behavior. ### Before ### After --> ## Test code and steps to reproduce - use `Test432` and `Test2231` to test this fix on both architectures. ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes
## Description This PR intents to fix header subviews incorrect layout when changing tabs. The previous solution did layout the subviews correctly in the test cases, but triggered an undesirable `layoutIfNeeded` when going back from tab to tab. In such case the navigation layout happened without updating subview's layout metrics. Moving the logic to subview resolves the issue as the re-layout is now triggered only when subview's layout metrics are updated. Related fixes from the past: #2316, #2248 ## Changes - combined `Test2231.tsx` with `Test432.tsx` to create comprehensive test case - moved re-layout logic to subview ## Screenshots / GIFs ### Before ![Screenshot 2024-10-04 at 10 10 15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77) ### After ![Screenshot 2024-10-04 at 10 09 37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83) ## Test code and steps to reproduce - Use `Test432.tsx` repro ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes
## Description This PR fixes the header layout mismatch when updating both `headerLeft` and `headerRight` options simultaneously using `navigation.setOptions`. Fixes software-mansion#2231 . ## Changes - Forced subview to re-layout when updating layoutMetrics - added `Test2231.tsx` repro ## Screenshots / GIFs ### Before ![Screenshot 2024-07-16 at 12 05 14](https://github.com/user-attachments/assets/37a5a77d-1cd5-457f-901e-9dd5b4065a8f) ### After ![Screenshot 2024-07-16 at 12 04 49](https://github.com/user-attachments/assets/025db807-ef6d-46f2-b4c0-cd9f06e03d93) ## Test code and steps to reproduce - Use `Test2231.tsx` repro ## Checklist - [x] Ensured that CI passes
## Description This PR fixes the incorrect position of the custom header items when updating more than one option at the same time. The proposed solution let us remove the previous fix for a similar problem: software-mansion#2248 which only fixed the issue on fabric. Fixes software-mansion#432, software-mansion#2231. ## Changes - forced re-layout of the navigation controller when subviews are updated - removed previous fix - updated `Test432` repro <!-- ## Screenshots / GIFs Here you can add screenshots / GIFs documenting your change. You can add before / after section if you're changing some behavior. ### Before ### After --> ## Test code and steps to reproduce - use `Test432` and `Test2231` to test this fix on both architectures. ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes
## Description This PR intents to fix header subviews incorrect layout when changing tabs. The previous solution did layout the subviews correctly in the test cases, but triggered an undesirable `layoutIfNeeded` when going back from tab to tab. In such case the navigation layout happened without updating subview's layout metrics. Moving the logic to subview resolves the issue as the re-layout is now triggered only when subview's layout metrics are updated. Related fixes from the past: software-mansion#2316, software-mansion#2248 ## Changes - combined `Test2231.tsx` with `Test432.tsx` to create comprehensive test case - moved re-layout logic to subview ## Screenshots / GIFs ### Before ![Screenshot 2024-10-04 at 10 10 15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77) ### After ![Screenshot 2024-10-04 at 10 09 37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83) ## Test code and steps to reproduce - Use `Test432.tsx` repro ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes
## Description This PR fixes the incorrect position of the custom header items when updating more than one option at the same time. The proposed solution let us remove the previous fix for a similar problem: #2248 which only fixed the issue on fabric. Fixes #432, #2231. ## Changes - forced re-layout of the navigation controller when subviews are updated - removed previous fix - updated `Test432` repro <!-- ## Screenshots / GIFs Here you can add screenshots / GIFs documenting your change. You can add before / after section if you're changing some behavior. ### Before ### After --> ## Test code and steps to reproduce - use `Test432` and `Test2231` to test this fix on both architectures. ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes (cherry picked from commit bc95fa4)
## Description This PR intents to fix header subviews incorrect layout when changing tabs. The previous solution did layout the subviews correctly in the test cases, but triggered an undesirable `layoutIfNeeded` when going back from tab to tab. In such case the navigation layout happened without updating subview's layout metrics. Moving the logic to subview resolves the issue as the re-layout is now triggered only when subview's layout metrics are updated. Related fixes from the past: #2316, #2248 ## Changes - combined `Test2231.tsx` with `Test432.tsx` to create comprehensive test case - moved re-layout logic to subview ## Screenshots / GIFs ### Before ![Screenshot 2024-10-04 at 10 10 15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77) ### After ![Screenshot 2024-10-04 at 10 09 37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83) ## Test code and steps to reproduce - Use `Test432.tsx` repro ## Checklist - [x] Included code example that can be used to test this change - [x] Ensured that CI passes (cherry picked from commit 91d89c4)
Description
This PR fixes the header layout mismatch when updating both
headerLeft
andheaderRight
options simultaneously usingnavigation.setOptions
.Fixes #2231 .
Changes
Test2231.tsx
reproScreenshots / GIFs
Before
After
Test code and steps to reproduce
Test2231.tsx
reproChecklist