Summary:
This prop was introduced for horizontal and vertical scrollview in D40642469.
That diff updated the native view configs only.
**Note:** This prop did not work for bridgeless mode.
Partial fix: Add the prop to vertical scrollview: D54223244
Full fix: this diff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854757
fbshipit-source-id: aff2da407f4df4575ceb66d3d381a144fa07a8e9
Summary:
The margin/padding props were introduced in this diff: D41267765
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56846578
fbshipit-source-id: 396cab3fdd63d9c630690157a385f1ae53208bb7
Summary:
The insets props were introduced in this diff: D42193661
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849870
fbshipit-source-id: 7be2a5825086ac954fdb8bc3bb86b57a2fa6d326
Summary:
onClick was made into a capture event in this diff: D45745906
- Partial fix: D51551255
- Full fix: this diff.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849867
fbshipit-source-id: 15acc16b162e0dd17513c6452008331e3fee4526
Summary:
As pointed out by liamjones here:
https://github.com/facebook/react-native/pull/44214#discussion_r1587755403
The original PR did introduce a bug in the `find/first` check, but in my testing, we do need to look at `group.name`, so let's make sure we check both.
This also makes it play nice with an existing file even if it is added to a different directory, by appending to it instead of forcing it to exist in the main group.
## Changelog:
[IOS] [FIXED] - Fix privacy aggregation
Pull Request resolved: https://github.com/facebook/react-native/pull/44390
Test Plan: Tested on rn-tester
Reviewed By: cipolleschi
Differential Revision: D56893594
Pulled By: philIip
fbshipit-source-id: b92589bc2bed9d07e9af20c56a8b9f6c61d864f0
Summary:
This is a major sync, featuring our recent rebase of `chromium/6344`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56884975
fbshipit-source-id: bc91f66bfc92464ab8fa99893ab0181077041b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44339
We require the wrapper code for in repository calls to these packages directly from node (i.e. using CommonJS). This wrapper code typically sits at the entrypoint of the build packages (i.e. `index.js`).
NOTE: This unblocks an issue preventing me from landing further work on the `helloworld` cli replacing the community template.
## Problem:
The [flow-api-translator](https://www.npmjs.com/package/flow-api-translator) library doesn't allow CommonJS `module.exports` when generating TypeScript Type Defintions.
## Change
1. At the built time, this strips out our wrapper code and sets up the dist/ folder appropriately for npm distribution.
2. Updated the `package.json` files to consistently share Flow types
Changelog: [Internal] refactor build packages output to remove wrapper.
NOTE: Added better error messages when users deviated from the current pattern:
{F1501571608}
Reviewed By: huntie
Differential Revision: D56762162
fbshipit-source-id: f110b31e4ad780998dbc81a2482891ac8d8c6458
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` & `handleReloadJS()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `shouldShowDevMenuOrReload()` returns true in RELEASE as well which is a bug.
Since there is no need for `shouldShowDevMenuOrReload()` in RELEASE, changing it's logic to introduce that check, early exit and return false in case of RELEASE.
Changelog:
[Android][Fixed] shouldShowDevMenuOrReload() in RELEASE mode
Reviewed By: RSNara
Differential Revision: D56851473
fbshipit-source-id: e9e12b0bec8aead5e9227fcd676459ca54490b61
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java#L66
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `onKeyLongPresss()` returns true in RELEASE as well which is a bug.
Since there is no need for `onKeyLongPress()` in RELEASE, changing it's logic to introduce that check and return false in case of RELEASE.
Changelog:
[Android][Fixed] onKeyLongPress() in RELEASE mode
Reviewed By: christophpurrer, RSNara
Differential Revision: D56850466
fbshipit-source-id: 92d2c8572b32d065f5f9d54e22588bb085b9dcc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44361
In order to keep all platforms in sync (Android, iOS, Windows, etc.), it makes sense to consolidate all C++ TurboModules that we want available by default on all platforms to a shared C++ header / implementation.
This moves the duplicated code from Android and iOS to such a shared module provider and updates relevant build specs.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56835783
fbshipit-source-id: 7322ed054ded5749973885c63257e5caf23b3fc3
Summary:
Changelog: [Internal]
A very similar diff was attempted with D50647971 and reverted in D51617862. The main difference here is all behavior is gated behind the feature flag. Before, we were enqueuing the extra frame callback on start_animating_node even if ondemand choreographer was disabled.
Reviewed By: javache
Differential Revision: D56085369
fbshipit-source-id: fa6335303fe98199b18fa2b4819110afb8efcc0d
Summary:
ViewManagers are all BaseJavaModule, and thus have access to methods like `getReactApplicationContext`. We don't expose the appropriate constructors though to pass this context down from the base class.
Not a breaking change, as the no-arg constructor is still used implicitly.
Changelog: [Android][Fixed] ViewManagers can pass context to their base class.
Reviewed By: fabriziocucci
Differential Revision: D56804318
fbshipit-source-id: b0e6b15dfd7786073da058beccfaba2ff30daf5a
Summary:
In a future release of React Native, string refs will no longer be supported. This increases the severity of the `no-string-refs` lint rule to convey this.
Changelog:
[General][Changed] - `no-string-refs` is now a lint error
Reviewed By: kassens
Differential Revision: D56826663
fbshipit-source-id: 603f5b205bb9fd8a5dcb8ee917f6a2ba1ac47e6e
Summary:
Changelog: [Internal]
Updates the doc comment on `Function::createFromHostFunction` to
mention that (a copy of) the provided `std::function` may be destroyed
on an arbitrary thread, much like `HostObject` (where this is already
documented).
Reviewed By: neildhar
Differential Revision: D56628194
fbshipit-source-id: 1939602135e83a9c36896c395816054376026edc
Summary:
This change removes a couple of method from RCTHost which were not following the iOS convention for names.
We deprecated them in 0.74 and now that the branch is cut, we can remove them.
## Changelog:
[iOS][Breaking] - Remove `getSurfacePresenter` and `getModuleRegistry` from RCTHost
Reviewed By: sammy-SC
Differential Revision: D56633554
fbshipit-source-id: 88fd1525bfe68ca1f6c2d8403d0dec505a23e9f8
Summary:
We [received an issue](https://github.com/react-native-maps/react-native-maps/issues/5042) in OSS where a ViewManager was configured to be initialized on the main queue, but it wasn't.
This was creating a soft crash and showing a RedBox to the user.
The library was going through the Interop Layer.
This change makes sure that, if the ViewManager is configured to be setup in the main queue, we retrieve the constants from the Main Queue
## Changelog
[iOS][Fixed] - Extract the constants from ViewManagers in the UI Thread if needed.
Reviewed By: sammy-SC
Differential Revision: D56762253
fbshipit-source-id: ca807b34d6e61418da9fd6a639a05f3394879f7c
Summary:
Changelog: [internal]
Migrating this feature flag (which is currently unused) to the new system, so we can test it in production and ship it soon.
Reviewed By: NickGerleman
Differential Revision: D56766553
fbshipit-source-id: 42d44cdd163568564e789cdffe1683e78fe91b53
Summary:
This work is based on Ruslan's https://www.internalfb.com/intern/diff/D56185630/
Changelog: [Internal]
`Expectation`: In React DevTools, user should be able to select an element on screen and it will show you what React component rendered it. This doesn't work in RN app that is using JS navigation
`Root Cause`:
In Fabric, when we try to find `ShadowNode` in the `ShadowTree`, `pointerEvents` props are not considered during the lookup of node using coordinate. Hence, in React DevTools when we inspect element, it was hightlighting the overlay `View` with `pointerEvents` props `box-none` was getting highlighted instead of its children view in the hierarchy.
Reviewed By: javache
Differential Revision: D56334314
fbshipit-source-id: ebfe58c5a1516add347c2c21ab5d075f804df8a9
Summary:
This removes the bulk of code added in https://github.com/facebook/react-native/pull/39630.
We're not shipping it, as it caused performance regressions.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56796936
fbshipit-source-id: 82f3a51cf145bc1695d70393e1f050685a1e6174
Summary:
Changelog: [General][BREAKING] Don't support 'float' enums in Turbo Modules
- The current implementation of 'float enums' in C++ does not work as invalid results are returned.
- At potential fix could still cause rounding errors when crossing language bounaries, e.g. `4.6` can become `4.5599999942..`
- C++ enum classes don't support float: https://eel.is/c++draft/dcl.enum#2.sentence-4
> The type-specifier-seq of an enum-base shall name an integral type; any cv-qualification is ignored.
Hence removing the feature of `float enums` for now
Reviewed By: NickGerleman
Differential Revision: D52120405
fbshipit-source-id: 3685ad0629e16ff9db424ba67e07d09df6027553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
## Changelog:
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:
When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:
When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:
Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
This enables to code-gen base C++ types for custom exported JS types from a RN TM spec - which have been previously excluded from code-gen as these aren't used in any function.
The only work around so far was to ‘register’ a random function using the custom type which should be used for RCTDeviceEventEmitter events
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56685903
fbshipit-source-id: add9ca40018b91c9fca98609ba3d1f85d3affec1
Summary:
Changelog: [internal]
`LazyShadowTreeRevisionConsistencyManager` wasn't correctly updating the locked revision, because `emplace` is a no-op if there's already a value for the key in the `unordered_map`.
This fixes the issue and adds tests that actually showed it.
Reviewed By: sammy-SC
Differential Revision: D56761941
fbshipit-source-id: 340e9195b14460a591c48186bd365688c74ade04
Summary:
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44333
Reviewed By: cortinico
Differential Revision: D56756077
Pulled By: cipolleschi
fbshipit-source-id: 4e8d2f6b83499bd89d6a60de4eede385b7a8ac3c
Summary:
`RCTComposedViewRegistry` extends `NSMutableDictionary` which is a clustered class in iOS.
NSMutableDictionary is techncially an abstract class, but when instantiated by `[NSMutableDictionary new];` the system will return one of concrete classes that inherit from `NSMutableDictionary`, opaquely from the perspective of the caller.
By calling `super`, we are actually calling the not implemented method for the abstract class. If this happen, this can crash the app.
Given that the `RCTComposedViewRegistry` is extending the dictionary only for its interface but is using other mechanisms as storage, is it fair to return `NULL`if the storages don't have the requested view.
## Changelog
[iOS][Fixed] - Avoid calling abstract methods in RCTComposedViewRegistry
Reviewed By: cortinico
Differential Revision: D56755427
fbshipit-source-id: f5c56dc59ccc6b30c00199b4196c42eb9b021e2b
Summary:
I accidentally broke build_android.
Here the two fixes:
1. Make sure the constructor of PackageList2 are actually called `PackageList2`
2. Make sure the package of `OSSLibraryExamplePackage` is `com.facebook.react.osslibraryexample`
Changelog:
[Internal] [Changed] - Fix accidentally broken build_android job
Reviewed By: dmytrorykun
Differential Revision: D56756601
fbshipit-source-id: 862597ca829d702d880624d29276193f8548715d
Summary:
Changelog: [Internal]
The bodies of all `console` methods are currently written as lambdas within `installConsoleHandler` but actually capture nothing meaningful from that scope. This diff rewrites them as free functions instead.
To enable the "forwarding console methods" to be written as free functions, we also replace the runtime loop over `kForwardingConsoleMethods` with a compile-time equivalent using macros. (This technique is inspired by the Hermes source code, which uses it heavily for compile-time code generation.)
Reviewed By: huntie
Differential Revision: D56679956
fbshipit-source-id: babf368ecacb9dc426b2356a4a2091881ca1023e
Summary:
Changelog: [Internal]
Switches to constrained `auto` instead of `std::function` to represent intermediate function types in `RuntimeTargetConsole::installConsoleHandler`. This removes some indirection and potential runtime overhead.
Reviewed By: huntie
Differential Revision: D56675188
fbshipit-source-id: 76cbf8b8be9ca1a9466efbcd187bddd60c921019
Summary:
Changelog: [internal]
This migrates all the classes related to performance in `react-native/src/private` to use private fields instead of regular fields prefixed with `_`.
Reviewed By: yungsters
Differential Revision: D55931659
fbshipit-source-id: e8b2018048dbb6c8d6e8a4d143357bf2ac39dd1e
Summary:
Changelog: [internal]
Quick refactor to use private fields instead of fields with a naming convention, in classes in `react-native/src/private`.
Reviewed By: yungsters
Differential Revision: D56700382
fbshipit-source-id: ee0a7b30a9da20c31b92878be3316227b2d0a0c4
Summary:
Adds changelog for the 0.73.8 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.73.8 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44331
Reviewed By: cortinico
Differential Revision: D56753881
Pulled By: cipolleschi
fbshipit-source-id: eed053cd39a768d6acb40a037a4218ee5e1fbbf8
Summary:
Changelog: [internal]
We have a comment explaining how to update all generated files everywhere but here.
Reviewed By: NickGerleman
Differential Revision: D56717344
fbshipit-source-id: cc538e37dd6ab09f67d67bb13ce4e560870d44d0
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating data classes that will allow us to parse the `config` JSON output.
Code is pretty straightforward and follows the structure as the `config` command output.
Changelog:
[Internal] [Changed] - RNGP - Autolinking - Add model classes for parsing the `config` output
Reviewed By: cipolleschi, blakef
Differential Revision: D55475595
fbshipit-source-id: 3457c008ff0c5bce2b47fd637c7b10a5e7427c01
