fix(iOS): modal becomes unresponsive with refresh control inside scrollable by kkafar · Pull Request #48580 · react/react-native

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

kkafar · 2025-01-09T22:36:24Z

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!

cipolleschi

@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?

cipolleschi · 2025-01-10T10:04:11Z

 [super didMoveToWindow];
 if (self.window) {
- [self _attach];
+ dispatch_async(dispatch_get_main_queue(), ^{


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

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

cipolleschi · 2025-01-10T10:05:18Z

+ [self _attach];
+ });
 } else {
 [self _detach];


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...

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 · 2025-01-10T10:42:00Z

@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 · 2025-01-10T10:48:27Z

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).

kkafar · 2025-01-13T14:55:39Z

Seems to be superseded by 6cb2684

Thanks!

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Delay attach code
7363620

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 changed the title ~~Delay attach code~~fix(iOS): modal becomes unresponsive with refresh control inside scrollableJan 9, 2025

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

This was referenced Jan 9, 2025
Modal becomes unresponsive when using RefreshControl within ScrollView #48579
Closed
Unresponsive modal when RefreshControl used with iOS modal and header hidden react-navigation/react-navigation#12355
Closed

cipolleschi requested changes Jan 10, 2025
View reviewed changes

kkafar requested a review from cipolleschi January 13, 2025 10:41

kkafar mentioned this pull request Jan 13, 2025
fix(iOS): not reponsive modal with refresh control in scrollable software-mansion/react-native-screens#2610
Closed
8 tasks

kkafar closed this Jan 13, 2025

Uh oh!

Conversation

kkafar commented Jan 9, 2025

Summary:

Changelog:

Test Plan:

Uh oh!

cipolleschi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkafar commented Jan 10, 2025

Uh oh!

kkafar commented Jan 10, 2025

Uh oh!

kkafar commented Jan 13, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

kkafar commented Jan 9, 2025

Summary:

Changelog:

Test Plan:

Uh oh!

cipolleschi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkafar commented Jan 10, 2025

Uh oh!

kkafar commented Jan 10, 2025

Uh oh!

kkafar commented Jan 13, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

kkafar commented Jan 9, 2025

Summary:

Changelog:

Test Plan:

Uh oh!

cipolleschi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

cipolleschi left a comment •
edited
Loading

kkafar commented Jan 13, 2025•
edited
Loading

cipolleschi left a comment •
edited
Loading

kkafar commented Jan 13, 2025•
edited
Loading

cipolleschi left a comment •
edited
Loading

kkafar commented Jan 13, 2025•
edited
Loading

cipolleschi left a comment •
edited
Loading