-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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 warning when loading RCTUIManager in the old architecture #42733
Conversation
This pull request was exported from Phabricator. Differential Revision: D53225120 |
Summary: When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue. In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue. {F1405693310} With this change we anticipate the initialization of the module in a place where: 1. We know we are in the main queue 2. We know we are going to need it (so it is not violating the lazy load principle) 3. We know it is safe. This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module. ## Changelog: [iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it. Differential Revision: D53225120
7eb100d
to
137628f
Compare
This pull request was exported from Phabricator. Differential Revision: D53225120 |
137628f
to
ab64345
Compare
Summary: When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue. In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue. {F1405693310} With this change we anticipate the initialization of the module in a place where: 1. We know we are in the main queue 2. We know we are going to need it (so it is not violating the lazy load principle) 3. We know it is safe. This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module. ## Changelog: [iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it. Differential Revision: D53225120
This pull request was exported from Phabricator. Differential Revision: D53225120 |
ab64345
to
f0a928d
Compare
Summary: When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue. In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue. {F1405693310} With this change we anticipate the initialization of the module in a place where: 1. We know we are in the main queue 2. We know we are going to need it (so it is not violating the lazy load principle) 3. We know it is safe. This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module. ## Changelog: [iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it. Differential Revision: D53225120
This pull request was exported from Phabricator. Differential Revision: D53225120 |
Summary: When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue. In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue. {F1405693310} With this change we anticipate the initialization of the module in a place where: 1. We know we are in the main queue 2. We know we are going to need it (so it is not violating the lazy load principle) 3. We know it is safe. This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module. ## Changelog: [iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it. Reviewed By: philIip Differential Revision: D53225120
f0a928d
to
4665710
Compare
This pull request was exported from Phabricator. Differential Revision: D53225120 |
This pull request has been merged in dc38988. |
Summary:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
This should allow us to also remove the feature flag of
RCTUIManagerDispatchAccessibilityManagerInitOntoMain
because now it is safe to use the main_queue as requested by the module.Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Differential Revision: D53225120