Summary:
This PR aims to resolve iOS can't dismiss Modal on swipe gesture.
https://github.com/facebook/react-native/issues/29319
When modal presentationStyle is pageSheet, iOS allows to dismiss the modal using swipe gesture. This PR adds support for that feature
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - Support for onRequestClose for iOS Modal component.
Pull Request resolved: https://github.com/facebook/react-native/pull/31500
Test Plan:
- If onRequestClose updates the visibility state, modal will be closed.
```
<Modal
visible={visible}
animationType="slide"
presentationStyle="pageSheet"
onRequestClose={dismiss}>
</Modal>
```
https://user-images.githubusercontent.com/23293248/117590263-36cd7f00-b14c-11eb-940c-86e700c0b8e7.mov
## Notes
- In this PR, only support for partial drag is added. i.e. user can't drag the modal up and down completely. I added full user dragging but reverted in this [commit](bb65b9a60d) to support controllable onRequestClose. If someone has any suggestion to have full draggable support + controllable onRequestClose, please let me know.
<!--
the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
Reviewed By: p-sun
Differential Revision: D30041625
Pulled By: sammy-SC
fbshipit-source-id: 9675da760bd5c070c4f0e1d30271c8af5c50b998
Summary:
seperated -> separated
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Fixed typo in comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31067
Test Plan: NONE
Reviewed By: sammy-SC
Differential Revision: D30176244
Pulled By: sota000
fbshipit-source-id: 617607aaa7eb5f613344773c4bbbc09a8c5096c1
Summary:
Note: PR to react-native-macos here https://github.com/microsoft/react-native-macos/pull/733
Internally in Microsoft code, we ran into a deadlock where the main queue and the UIManager queue were both trying to access `[RCTI18nUtil sharedInstance]`, and were blocked on each other. This is similar to an earlier issue with RCTScreenScale decsribed [here](https://github.com/facebook/react-native/issues/18096).
To summarize:
1- RCTShadowView (on the UIManager queue) and RCTView (on the main queue) both try to access `[RCTI18nUtil sharedInstance]`
2- The UIManager thread gets there first, and lazily initializes the sharedInstance. Meanwhile, the main thread is waiting on a lock possessed by the UIManager thread
3- As part of the initialization, we set an NSUserDefault, which seems to require the (blocked) main thread.
4- Deadlock.
For whatever reason, this only happens on debug. I did not figure out why, but I do know based on [this comment](https://github.com/facebook/react-native/issues/18096#issuecomment-368718081), that the UIManagerQueue should never block the main queue.
The fix is to not use NSUserDefaults, and simpy use atomic properties instead. We get the thread safety for free, and it also simplifies the code somewhat without changing the public API. The downside is values aren't persisted anymore, but I do not think that was necessary / intended.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix deadlock on RCTi18nUtil
Pull Request resolved: https://github.com/facebook/react-native/pull/31032
Test Plan:
Ran the RTLExample in RNTester, and ensured switching to RTL still worked, and that setting forceRTL would still work after reloading the bundle.
https://user-images.githubusercontent.com/6722175/108775429-aefdae80-7526-11eb-9a89-3114f7ddc2af.mov
Reviewed By: javache
Differential Revision: D29522152
Pulled By: RSNara
fbshipit-source-id: 160840f63a7b1d6721b0fd8294fb11990a4509fa
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Remove unused import
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [performance] - Remove unused import
Pull Request resolved: https://github.com/facebook/react-native/pull/30544
Test Plan: Should build on CI
Reviewed By: lunaleaps
Differential Revision: D30000901
Pulled By: charlesbdudley
fbshipit-source-id: 3d3310917823b7af57564ca1ea397cd32cd0c4d5
Summary:
Fixes https://github.com/facebook/react-native/issues/31779
For more detailed explanation, see issue https://github.com/facebook/react-native/issues/31779
React Native touch handler events (onTouchStart, onTouchMoved, etc..) are intended to have "force" properties when used on devices which support pressure input (3D Touch & Apple Pencil events). However, due to a check in RCTForceTouchAvailable() function which checks for UITraitCollection's "forceTouchCapability" to be equal to UIForceTouchCapabilityAvailable, the check returns NO on iPad-based devices, due to iPad devices returning UIForceTouchCapabilityUnavailable at all times. This causes "force" values of Apple Pencils to never be passed on to React Native.
Since simply passing 0 as a value for force across the RN bridge for every touch event seemed like a change that might seem jarring to some, I decided that a simple additional boolean check if the touch event's type is UITouchTypePencil (this is the same as UITouchTypeStylus) should also suffice.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fixed "force" property of touch events for Apple Pencil/Stylus devices.
[iOS] [Feature] - Added "altitudeAngle" property to touch events from Apple Pencil/Stylus devices.
Pull Request resolved: https://github.com/facebook/react-native/pull/31780
Test Plan:
The code compiles and runs, and trying a simple handler for a View like
````
touchMove = (e: GestureResponderEvent) => {
console.log(`pressure, altitude (${e.nativeEvent.force}, ${e.nativeEvent.altitudeAngle})`);
````
results in
<img width="424" alt="Screen Shot 2564-06-28 at 17 13 22" src="https://user-images.githubusercontent.com/5000572/123621055-0b563f00-d835-11eb-9eff-526ba27fdf7b.png">
and when pencil is oriented perpendicular to the screen and pressed with full force shows
<img width="412" alt="Screen Shot 2564-06-28 at 17 13 58" src="https://user-images.githubusercontent.com/5000572/123621139-1c06b500-d835-11eb-8207-68a49720d708.png">
Reviewed By: sammy-SC
Differential Revision: D29964102
Pulled By: sota000
fbshipit-source-id: 5a1f41d64c6fe325afbd2b9579eaf20a522e92dc
Summary:
changelog: [internal]
Completion block can retain `_eventEmitter` beyond existence of the component. To fix this, do not retain `_eventEmitter` by block but try to acquire it inside it.
Reviewed By: JoshuaGross
Differential Revision: D29969189
fbshipit-source-id: 456c42f816acc160f9d6bbd3f9c8c55d611940b2
Summary:
Changelog: [internal]
Fabric didn't have prop [removeClippedSubviews](https://reactnative.dev/docs/view#removeclippedsubviews) implemented. This diff adds it. It is
Reviewed By: JoshuaGross
Differential Revision: D29906458
fbshipit-source-id: 5851fa41d7facea9aab73ca131b4a0d23a2411ea
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769275
fbshipit-source-id: 7ac04f8a8f7e41ce8d43a81b25ebd063b3a9f3de
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
![before](https://user-images.githubusercontent.com/428831/91644197-ea03a700-ea07-11ea-9489-be27820930eb.png)
![after](https://user-images.githubusercontent.com/428831/91644200-eff98800-ea07-11ea-8788-daf1e783639d.png)
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
Changelog: [internal]
Make sure correct text attributes are used inside of view command.
Reviewed By: sshic
Differential Revision: D29585943
fbshipit-source-id: 4748c843ff586f1dd42f3a89460afb624f9b371a
Summary:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
The Facebook app can have both bridge and bridgeless surface. Each type of surface has its own DevMenu. It's important to specify which DevMenu is being rendered, because not doing so can make for some confusing/frustrating devx (e.g: the bridgeless dev menu shows up for bridge surfaces: https://pxl.cl/1L1m7).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29439980
fbshipit-source-id: 24de1e6b44e5315c0cee0684d0db5df31514d3e2
Summary:
# See PR
https://github.com/facebook/react-native/pull/29728
# From PR Author
Using `PlatformColor` with border colors doesn't work currently when switching dark mode as the information is lost when converting to `CGColor`. This change keeps the border colors around as `UIColor` so switching to dark mode works.
```ts
<View
style={{
borderColor: DynamicColorIOS({ dark: "yellow", light: "red" }),
borderWidth: 1,
}}
>
...
</View>
```
This view will start with a red border (assuming light mode when started), but will not change to a yellow border when switching to dark mode. With this PR, the border color will be correctly set to yellow.
## Changelog
[iOS] [Fixed] - Allow PlatformColor to work with border colors
Pull Request resolved: https://github.com/facebook/react-native/pull/29728
Test Plan:
1. Assign a `PlatformColor` or `DynamicColorIOS` to a view border color.
2. Toggle between dark / light mode. See the colors change.
Reviewed By: lunaleaps
Differential Revision: D29268376
Pulled By: p-sun
fbshipit-source-id: 586545b05be0beb0e6e5ace6e3f74b304620ad94
Summary:
Changelog: [internal]
Original commit changeset: fa4d8944ad6b
Not sending onScroll events events to Paper has no effect.
Reviewed By: mdvacca
Differential Revision: D29229662
fbshipit-source-id: b84a2614bfd42c64ca67ca6a1cd9d0a815c11ad0
Summary:
Previously, RCTRootView added support for minimumSize as a workaround for some initial layout use cases. Going forward, we don't need this anymore. So let's add a proxy property but log an error if anyone calls it.
Changelog: [iOS][Changed] - Proxy minimumSize to RCTSurface as a noop
Reviewed By: JoshuaGross
Differential Revision: D29284227
fbshipit-source-id: 98b2dfc905c6c7e1adc03216e3a1cc3fda0a4133
Summary:
Changelog: [internal]
ScrollView's `scrollTo` command doesn't work in RTL. It sets the offset from left of the screen instead of right. This diff fixes this for Fabric only.
Reviewed By: JoshuaGross
Differential Revision: D29164056
fbshipit-source-id: f685d3e013f474f9b445112333d8f5ad7ed36ea7
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4
Summary:
Changelog: [internal]
RuntimeScheduler can be accessed before any Fabric surface is rendered. Therefore, it needs to be created and installed in the runtime at the start up of the runtime.
Reviewed By: JoshuaGross
Differential Revision: D29091848
fbshipit-source-id: ff75ef8c4882550795e5d4a258355b651cb0e637
Summary:
Changelog: [internal]
Using keyboard's autocomplete did not insert space at the end of the word.
Reviewed By: fkgozali
Differential Revision: D29085654
fbshipit-source-id: 35fee726ea7d2030fdfa64300e045a303ea98ce9
Summary:
Changelog: [internal]
To prevent wrong TextInput becoming first responder, force a resign when preparing for a reuse.
Reviewed By: JoshuaGross
Differential Revision: D29085923
fbshipit-source-id: 246cdf0628f914c3928cc9c7499d029b77684f2c
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
When maxLength is defined in <TextInput>, if the last character at max length is an emoji, the content of the input is cleared:
{F620865178} {F620865237}
Related Github issues:
https://github.com/facebook/react-native/issues/10929https://github.com/facebook/react-native/issues/10964
## Root cause:
When NSString was created, unicode characters were 16-bit long, so Objective-C considers every unicode character as 16-bit. However, unicode was later extended to more than 16bit, for example, emojis, which causes NSString substring method cuts off at the wrong position.
Example:
```
NSString *s = @"abc{emoji:1f601}";
NSInteger len = s.length; //length is 5 (as {emoji:1f601} occupies two 16-bit characters)
NSString *s3 = [s substringToIndex: 3]; //s3 is "abc"
NSString *s4 = [s substringToIndex: 4]; //s4 is null!
```
If string s, "abc{emoji:1f601}", is entered in <TextInput>, which has max length 4, it will truncate the string to the first 4 characters, "cutting" the emoji in half which causes encoding error and returns null. The text input is cleared.
## Solution:
If the character at max length is longer than 16-bit, truncate the character BEFORE it instead. In the previous example, truncate till index 3 instead of 4. The end result will be "abc" and the emoji is dropped.
## Changelog:
[iOS] [Fixed] - <TextInput> content is reset when emoji is entered at the max length
Reviewed By: p-sun
Differential Revision: D28821909
fbshipit-source-id: 4720d864970b554160ed5388f65b352ce95a6199
Summary:
Changelog: [internal]
Add a feature flag to enable yielding in RuntimeScheduler
Reviewed By: JoshuaGross
Differential Revision: D28903226
fbshipit-source-id: c361ca144a2d531e8aa671bc8875bce075e13a2c
Summary:
Changelog: [internal]
This is a life cycle issue where LayoutManager outlives the runtime. To fix this, we need to destroy `_accessibilityProvider` before the runtime. The way to do it is to destroy it inside `prepareForReuse` which is guaranteed to be called before runtime is destroyed.
Reviewed By: JoshuaGross
Differential Revision: D28898257
fbshipit-source-id: 9d2c0b9cebd9889caa4328f9ee7f005928bbf55a
Summary:
Changelog: [internal]
There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells.
To make sure the race doesn't happen, state must be updated before dispatching onScroll event.
Android has implemented a different mechanism to tackle this issue in D28558380 (b161241db2).
Reviewed By: JoshuaGross
Differential Revision: D28642737
fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
Summary:
Changelog: [internal]
collapsable was not passed to Fabric because view configs are built using Paper' ViewManagers.
Reviewed By: p-sun
Differential Revision: D27944688
fbshipit-source-id: 73a5646e25b3dd7a1a9dfc1079406047ab483d88
Summary:
Changelog: [internal]
Introduces synchronous access to the runtime from RuntimeScheduler.
At the moment, this is not used anywhere.
In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor.
Reviewed By: mdvacca
Differential Revision: D28024380
fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary:
Android was using rawProps received from JS, so no updates needed.
Updated iOS callsite to use the name of the action.
Changelog:
[General][Fixed] - Parse accessibilityAction props into object instead of string
Reviewed By: mdvacca
Differential Revision: D28614407
fbshipit-source-id: 209134f8fac65ca8516039e10ea502e57d52a7a7
Summary:
Changelog: [internal]
Originally added in D17814260 (ffc7ec992c) to make parallax effect work in Dating.
This diff hides it behind a flag so we can properly evaluate what's the cost of sending scroll events to Paper.
Reviewed By: JoshuaGross
Differential Revision: D28608283
fbshipit-source-id: fa4d8944ad6b5e767363e231942f13fec9d18cb5
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Changelog: [internal]
Extend LeakChecker so it is available on Android (or any other platform as it is completely in C++ now).
Reviewed By: JoshuaGross
Differential Revision: D28600243
fbshipit-source-id: c77a003e3ffc6171e61c998508c9f34f10bb65ca
Summary:
After D28435078, NativeModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the NativeModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435430
fbshipit-source-id: 1ce00c3fb3c63b024d7e24895ff96c541a6fa654
Summary:
While testing 0.65, we noticed issues with hermes on iOS in the template projects
These changes create a subspec to the react-core pod so that it can access hermes header correctly.
## Changelog
Not applicable
Pull Request resolved: https://github.com/facebook/react-native/pull/31559
Test Plan: I've ran e2e manual test. Tested RNTester manually also. Then tested a project inited with hermes and the default template
Reviewed By: mhorowitz
Differential Revision: D28564642
Pulled By: Huxpro
fbshipit-source-id: cfcb3363254f62a0e514ec99159b32f841ee4463
Summary:
When we initialize RCTDevLoadingView, we dispatch_sync to the main thread. There isn't anything in the NativeModule that requires us to initialize it on the main thread. So, this diff toggles requiresMainQueueSetup to NO. This should mitigate this prefetch-related deadlock: T90970812. Please read the task comments for the rationale.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28490715
fbshipit-source-id: 7efceb392ec9e0cabe7f7cd8867cf4b07f8fff19
Summary:
This protocol is no longer necessary, because we introduced the bridgeless-compatible abstraction: RCTCallJSModuleMethod.
Changelog: [iOS][Removed] - Delete RCTCallJSModuleMethod protocol
Reviewed By: fkgozali
Differential Revision: D28395446
fbshipit-source-id: 0ad606ce7935b24bfbd6e0c2f35fbde480a8a6ff
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
This diff has the bridge attach RCTCallableJSModules to our TurboModules.
Changelog: [Internal]
Differential Revision: D28395450
fbshipit-source-id: 6861e56f7fa0c009cded41f80b569de57a383e83
Summary:
This diff has the bridge attach RCTCallableJSModules to our NativeModules.
Changelog: [Internal]
Differential Revision: D28395447
fbshipit-source-id: 01ca62442013826d28ba0f710e28a5963f5efb65
Summary:
This is a Bridgeless-compatible API to allow our NativeModules to call JSModule methods.
Changelog: [iOS][Added] - Introduce RCTCallableJSModules API for NativeModules
Differential Revision: D28395448
fbshipit-source-id: b7929ba8b4cc4410361961b45efa23c76baacd24
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27937665
fbshipit-source-id: 434d78c95ccf23d8da41186d0dae91bff4eda384
Summary:
When RCTDevLoadingView is created, it checks to see if the bridge is loading. If so, displays the loading banner with the bundleURL. This logic is better placed in the bridge, because the bridge is also responsible for updating progress on the DevLoadingView.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28301524
fbshipit-source-id: fb6c259b546d8cd9e08568a88c7046d06c70ed6f
Summary:
Changelog: [internal]
Fix accessibility when entire text node is a link
Reviewed By: JoshuaGross
Differential Revision: D28325749
fbshipit-source-id: 9ac68b802f13d028b5cdb6cae7bdae5f4924fc07
Summary:
RCTJSInvokerModule invokeJS can do the work done by setInvokeJSWithModuleDotMethod. Therefore, this diff reduces the surface area of Venice, and gets rid of setInvokeJSWithModuleDotMethod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232947
fbshipit-source-id: aa0d8497a1e0fba29109ca86a39de5d9e5b10c9c
Summary:
This protocol is no longer necessary, because we migrated all our NativeModules to synthesize bundleManager = _bundleManager;
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28232441
fbshipit-source-id: 0bd54fa49299574db8a75247c97b466476037f4f
Summary:
This diff migrated RCTDevSettings to the RCTBundleManager, which works both in bridge/bridgeless mode. RCTDevSettings is the last TurboModule that synthesizes the bundleURL. So, after this diff, we can get rid of the RCTBundleHolderModule protocol.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232320
fbshipit-source-id: ab53278fea0ea7e025cf748be62bc5d610593e7f
Summary:
After this diff, every NativeModule that has `synthesize bundleManager = _bundleManager`, will get access to an RCTBundleManager, that it can use to read from/write to the bridge's bundle URL.
Changelog: [iOS][Added] - Attach RCTBundleManager to NativeModules
Reviewed By: PeteTheHeat
Differential Revision: D28086319
fbshipit-source-id: 6e4cd815d300e9036957ec8c743e947d2cb3f365
Summary:
In the full bridgeless, the following aren't allowed:
* using legacy view manager interop layer (won't support long term, but still needed today, so just warn)
* initializing any subclass of RCTViewManager (won't support long term, but still used by legacy interop layer)
* initializing RCTUIManager (fabric UIManager should be the only one used)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28111530
fbshipit-source-id: 4f5eab600c6c7896d51861545b7f878c25248e44
Summary:
Changelog:
[General][Added] Add support for "togglebutton" accessibilityRole
# Context
The role for ToggleButton, which is needed on Android to implement toggle buttons correctly, is not currently supported.
# What does this diff do?
Adds support for accessibilityRole `"togglebutton"`.
On Android, this maps to class `"Android.widget.ToggleButton"`.
iOS does not have an equivalent trait for togglebutton, so I set it to be the same as setting `accessibilityRole="button"` for iOS.
# Caveats - checked vs selected
It seems to me like this role currently requires that you set `accessibilityState={{checked: true/false}}`. The behavior is strange when setting `selected` state, I think because on Android ToggleButtons are meant to use `checked` to indicate toggled on/off.
This is tricky because typically on iOS if you have a toggle button, you would use `selected` instead of `checked`, so RN users are likely to mess this up.
Possible solutions:
1. document that you should use `checked` state on Android for toggle buttons (and maybe throw a warning if someone passes in `selected`).
2. have RN ignore it if someone passes in accessibilityState `selected`, if this role is used.
3. Have RN convert passed in `selected` state to `checked` on the Android side.
Reviewed By: nadiia
Differential Revision: D27976046
fbshipit-source-id: 4ce202449cf2371f4bf83c4db2d53120369ee7b0
Summary:
Changelog: [iOS] Use visible prop to dismiss Modal on old renderer.
Visible prop is used on Fabric so that onDismiss can be passed with the the bridgeless per-component event emitter, rather than the bridge global event emitter. The old renderer still uses the global event emitter.
I needed to use the visible prop for Paper too because in diff 6/7, Modal.js [no longer uses visible prop to return null](dc80b2dcb5/Libraries/Modal/Modal.js (L221-L222)), and Modal.js can't distinguish on whether it's a Fabric or Paper component.
Reviewed By: JoshuaGross
Differential Revision: D28137929
fbshipit-source-id: f6ede0019fbe498a10b822ff09fc135a9fff8ec0
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Summary:
Changelog: [Internal]
Static ViewConfigs are not yet available in Fabric. ViewConfigs are generated from Paper view managers.
For a prop to pass through from JS to iOS, props in [RCTModalHostViewNativeComponent.js](dc80b2dcb5/Libraries/Modal/RCTModalHostViewNativeComponent.js) need to match RCT_EXPORT_VIEW_PROPERTY in RCTModalHostViewManager.m.
Reviewed By: sammy-SC
Differential Revision: D27977574
fbshipit-source-id: 9790d93500890a04ffc0fb4d2bcd2de5187f1fc0
Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
Changelog: Fix main thread access to UIKit in RCTRedBox
{F611784226}
Xcode's main thread checker complains about this during reload. it is not needed to set `dataSource` and `delegate` to nil because the table view is about to be destroyed.
Reviewed By: mdvacca
Differential Revision: D28089039
fbshipit-source-id: 13b62cafb4790fc15b5a5dde131d4ae64bd97c82
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
From looking at other implementations of setJSResponder, we need the MountingManager to have access to "blocksNativeResponder" param, but do not need to pass that through to individual views (see also Android implementation).
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D28066257
fbshipit-source-id: e1420431478fd27d2e1463e291a0bbc600d3f0a6
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
Changelog: [internal]
`accessibilityFrame` needs to take scrolling position into account. To fix that, we calculate the position dynamically.
Reviewed By: mdvacca
Differential Revision: D28056789
fbshipit-source-id: 3247b3e6fd64934e99563de83d163f657828e933
Summary:
Changelog: Fix possible sizing issue with DatePicker
Changing `preferredDatePickerStyle` changes size of the component without triggering re-layout of the react native screen. The fix is to make sure the size stays the same after changing the style.
Reviewed By: mdvacca
Differential Revision: D28035226
fbshipit-source-id: 2dcb50fd5ebaa0c0d01d3289c4ffa77a053cfc4a
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
Changelog: [internal]
Current implementation of `AsynchronousEventBeat` dispatches lambdas through `RuntimeExecutor` regardless if it has done so previously.
So if `AsynchronousEventBeat::induce` is called 30 times, it will dispatch 30 lambdas.
In `AsynchronousEventBeatV2`, we make sure only single lambda is dispatched to `RuntimeExecutor` at a time.
Reviewed By: mdvacca
Differential Revision: D27940300
fbshipit-source-id: 2bad25c86315c1712b4a1da8c1d4702734cec70f
Summary:
Previously it defaults to using transparent color (iOS default), but when using `RCTSurfaceHostingProxyRootView` we actually manually set to `[UIColor whiteColor]`. However, if the surface is initialized via a different API, the color wasn't set. To avoid confusion and backward incompatibility, let's just set the same background color here.
We can decide in the future if the default color should be transparent instead.
Changelog: [Fixed][iOS] RCTSurfaceHostingView default background color is now consistent with RCTRootView
Reviewed By: RSNara
Differential Revision: D27973748
fbshipit-source-id: c506afbc5629df6647277aa2323f084773c8e760
Summary:
Adding support for DatePickerStyles on iOS13.4+
Changelog:
[iOS][Added] - Expose UIDatePickerStyles as a prop for DatePickerIOS
Reviewed By: PeteTheHeat
Differential Revision: D27953279
fbshipit-source-id: a35adf245147467ecbacac3770b9c50836cea468
Summary:
Adding support for DatePickerStyles on iOS13.4+
Changelog:
[iOS][Added] - Expose UIDatePickerStyles as a prop for DatePickerIOS
Reviewed By: PeteTheHeat
Differential Revision: D27948608
fbshipit-source-id: fcc16c630148818d9db0c9eef8363f8592b13791