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

fix(iOS): modal becomes unresponsive with refresh control inside scrollable #48580

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kkafar
Copy link
Contributor

@kkafar kkafar commented Jan 9, 2025

Summary:

Fixes #48579

Changelog:

[IOS][FIXED] - Modal becomes unresponsive with refresh control in scrollable

Test Plan:

https://snack.expo.dev/jWNIJRvKt6aScyidI-BGW starts to work!

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Software Mansion Partner: Software Mansion Partner labels Jan 9, 2025
@kkafar kkafar changed the title Delay attach code fix(iOS): modal becomes unresponsive with refresh control inside scrollable Jan 9, 2025
@facebook-github-bot facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Jan 9, 2025
Copy link
Contributor

@cipolleschi cipolleschi left a comment

Choose a reason for hiding this comment

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

@kkafar thanks for the PR. I left a couple of comments.

This behavior puzzles me. The didMoveToWindow function is from UIKit, so it should already and always be called from the main queue. Can you expand on when and how you encounter the problem?

@@ -148,7 +148,9 @@ - (void)didMoveToWindow
{
[super didMoveToWindow];
if (self.window) {
[self _attach];
dispatch_async(dispatch_get_main_queue(), ^{
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you use RCTExecuteOnMainQueue instead? It avoids the jump if we are already on the main queue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's all about placing the block at the end of the queue - see my response here: #48580 (comment)

[self _attach];
dispatch_async(dispatch_get_main_queue(), ^{
[self _attach];
});
} else {
[self _detach];
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't we add the same in the detach? also, how come that didMoveToWindow is called in a queue that is not the main queue? These methods are called by UIKit, React Native is not calling them explicitly...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't notice any problems with detach behaviour therefore I've left the code intact.

I believe this is a timing issue rather. The method is executed on UI thread as expected. See below

@kkafar
Copy link
Contributor Author

kkafar commented Jan 10, 2025

@cipolleschi

This behavior puzzles me. The didMoveToWindow function is from UIKit, so it should already and always be called from the main queue. Can you expand on when and how you encounter the problem?

Same here (puzzling part). I haven't had time yet to debug this thoroughly and as I described in the related issue #48579 I do not understand the error mechanism. However, from my testing I can say that the behaviour is 100% reliable (the bug happens always) and deferring execution of the code that sets the refreshControl on the scroll view helps.

[...] it should already and always be called from the main queue [...]

and it is executed on main queue as expected. There is some timing issue however - some unknown yet operations, which are already scheduled on UI queue must be completed before the refreshControl is set, at least it appears so.

Can you expand on when and how you encounter the problem?

I describe this in more detail in the issue report #48579 - the reproduction should be 100% reliable from my experience.

@kkafar
Copy link
Contributor Author

kkafar commented Jan 10, 2025

Having said the above ☝️ I'm not sure yet this is the proper way to fix the problem - I've just confirmed that deferring setting the refreshControl on scrollview improves the situation (haven't been able to reproduce the bug when this patch is applied).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Software Mansion Partner: Software Mansion Partner Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Modal becomes unresponsive when using RefreshControl within ScrollView
3 participants