Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40936
Found a couple of places where we were accidentally copying Props structs. These can be big, so we should avoid doing so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50263678
fbshipit-source-id: f60a0370df9b7f3f146988148d5192d3cc32fb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40935
This is scheduled to land in 0.74, so I'm removed the native integration as this is not needed anymore.
The only thing I left is a stub class to ease the migration out of `ReactNativeFlipper`.
Changelog:
[Android] [Removed] - Remove ReactNative/Flipper Integration
Reviewed By: mdvacca, huntie, cipolleschi
Differential Revision: D50259817
fbshipit-source-id: 28427425340896635607202cd78936f6030e78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40862
The last usages of Folly Futures were deleted in D49073914, so we can remove this dependency from React Native.
## Changelog:
[Internal] - remove folly usage in React-hermes
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D50223640
fbshipit-source-id: 792fd7696c1463a81e25dbef7713620486cc94c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39364
Once ConnectionDemux.* and Registration.* finish migrating to the new Hermes CDPHandler, there aren't any usage of the other stuff left over in inspector-modern. They can be safely removed.
Changelog: [Internal]
Reviewed By: mattbfb
Differential Revision: D49073914
fbshipit-source-id: bc60a3da85a00ac86beeebd098d7c3566a7c56dd
Summary:
Every file in the react-native-github repo should have the right copyright header. This was missed for this file.
Changelog: Internal
Reviewed By: rubennorte
Differential Revision: D50319271
fbshipit-source-id: 77c20fa4d3679eb5573ce61fd1c9cba60386ee21
Summary:
CircleCI is red because verdaccio fails to publish `normalize-colors`.
For some old dependencies, normalize-colors has been published on the official npmjs with the version we needs.
In order to mitigate the RN red ci, we can consume them directly from NPMJS.
As a followup, we created a task to investigate it next week.
## Changelog:
[Internal] - Skip publishing or normalize colors
Pull Request resolved: https://github.com/facebook/react-native/pull/40977
Test Plan:
Tested locally, running verdaccio and simulating CI. It worked.
CircleCI is green
Reviewed By: robhogan
Differential Revision: D50300449
Pulled By: cipolleschi
fbshipit-source-id: 2259b450deff15a117d1de4690bcfe8a9ba7d115
Summary:
To address the root cause of a recurring issue (https://github.com/facebook/react-native/issues/40797, https://github.com/facebook/react-native/issues/39692) where breaking changes to `react-native/normalize-colors` would be pulled into old versions of `deprecated-react-native-prop-types`, we recently change the dependency in the latter to use a semver range (https://github.com/facebook/react-native-deprecated-modules/pull/27, https://github.com/facebook/react-native/pull/40869).
For CI, we generally force `react-native/*` to be resolved only from Verdaccio locally published packages - ie, the current versions at source. The source version (currently `0.74.1`) isn't semver-compatible with `deprecated-react-native-prop-types`'s dependency (`^0.73.0`), so `npm install` was failing in CI with "no package found". We should be getting `0.73.2` from the public registry in this case.
This restores a previous workaround added in https://github.com/facebook/react-native/pull/34571 but not updated since https://github.com/facebook/react-native-deprecated-modules/pull/11 meant the dependency was now on the pluralised package. We have no dependency on the old non-plural package any more.
## Changelog:
[INTERNAL] [FIXED] - CI/Verdaccio: Proxy `react-native/normalize-colors` from NPM for the `deprecated-react-native-prop-types` dependency.
Pull Request resolved: https://github.com/facebook/react-native/pull/40971
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D50298291
Pulled By: robhogan
fbshipit-source-id: 4bf6503108335ffa52654346d1874c217071ff91
Summary:
Fixes https://github.com/facebook/react-native/issues/40754
Hi all!
We noticed that our app started to crash after bumping to RN v0.71.13, anyways after a deeper investigation we also found that the crash occurs in the latest version as well.
Crash log:
```
E FATAL EXCEPTION: main
Process: com.nfl.fantasy.core.android.debug, PID: 6034
java.lang.ClassCastException: android.app.ContextImpl cannot be cast to android.app.Activity
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.getActivity(ReactRootView.java:926)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:946)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:912)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
```
The code which causes ClassCastException is following [here](https://github.com/facebook/react-native/blob/ea88fbe229e1d276753ee8e118184274fc872138/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java#L864).
In this code explicit type conversion to Activity is not safe because it's not guaranteed by the compiler that context will be compatible with Activity type.
The appropriate issue [has been filed](https://github.com/facebook/react-native/issues/40754).
## 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
-->
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when keyboard events are fired.
Pull Request resolved: https://github.com/facebook/react-native/pull/40755
Test Plan:
Tested it manually with the [reference application](https://github.com/kot331107/rnCrashReproducer). Repro steps are as follows:
- Build and run the app on Android
- Tap the button "Open Modal"
- You should see the red popup fragment to the bottom of the screen
- Tap on the text input to open software keyboard
- Expected: it should show the keyboard and no crash happens.
Reviewed By: arushikesarwani94
Differential Revision: D50198424
Pulled By: NickGerleman
fbshipit-source-id: a5a6d86334856f4ffbe818150da5793380da4702
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40947
This shows up as this.context shows up as 1 sometimes. Let's just hard-code this to 11, to make the test more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D50253990
fbshipit-source-id: 1da75e5e5f3226676f9af67fc329a70079eed59e
Summary:
Currently, the template has a `buildToolsVersion = '34.0.0'` specified in the top level .gradle file but it's not currently using it.
This is causing the build to fallback to the default version provided by AGP which is 33.x
This is also causing the CI to download buildtools 34.0.0 as they're not in the container (causing network flakyness).
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/40938
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D50270482
Pulled By: cortinico
fbshipit-source-id: 09fdc66fe24f1cae760d07e4a2f044793a66cafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40934
The previous `packages/normalize-color` directory name could be confusing, given we have previously published a `react-native/normalize-color` package in addition to the current `react-native/normalize-colors`. After this change, the directory name and `package.json` `"name"` field are aligned.
Changelog: [Internal]
Reviewed By: cortinico, NickGerleman
Differential Revision: D50229030
fbshipit-source-id: 63854140bf61d7d1d3f1270ed05a2ba76f8c5b0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40939
Currently some libs on RN 0.73 are broken as the default for Build Config generation changed
from true to false since AGP 8.x. This reverts the behavior to the old flag.
Closes#40791Closes#40559
Changelog:
[Internal] [Changed] - Make sure buildConfig is turned on for all the 3rd party libraries
Reviewed By: mdvacca
Differential Revision: D50270382
fbshipit-source-id: 02dcb031c577f65be2f41d9da0334c1b3d89e4c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869
Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.
NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine. We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).
Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.
Reviewed By: huntie
Differential Revision: D50228564
fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40933
This enables us to have lint coverage (and others) for these files. Visibility is none, so it won't be pulled in to anything.
Also removed no-op JSITracing implementation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50262377
fbshipit-source-id: 6218c7a79b5c0328bed8472590cff9e92006b86e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40882
This header has not been used since facebook/react-native#110b191b landed, generalizing the way props map buffers are initialized.
# Changelog
[General][Internal]
Reviewed By: christophpurrer
Differential Revision: D50237390
fbshipit-source-id: f0f532c59c53b1df5d363cfd49f950697df37128
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40881
Some host platforms (e.g., Windows) may have different semantics for accessibility props. For example, not setting `accessibilityState` at all is different from setting all accessibilityState values to false.
Similarly, setting AccessibilityState::expanded to false is different than not setting AccessibilityState::expanded at all because Windows inverts the AccessibilityState::expanded value for it's semantics: an explicitly false value for AccessibilityState::expanded sets the component to a collapsed accessibility state.
## Changelog
[General][Internal]
Reviewed By: NickGerleman
Differential Revision: D50236747
fbshipit-source-id: 2131824d14e38e1ed08a80e8b0e311fc6b02d1f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40880
The isPressable prop was previously added to TextAttributes. It also needs to be parsed from RawProps in BaseTextProps for platforms to use it.
## Changelog
[General][Internal]
Reviewed By: javache
Differential Revision: D50235306
fbshipit-source-id: 101aded2af5889c739ed06af7511bd34a2683dfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40861
Reference `jobj_` from the async callback is unsafe, as the Java counterpart may have been deallocated by the time it's executed. Instead move the async call to Java.
Note that this method doesn't actually do anything in Fabric, it's used by the old renderer only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D50224974
fbshipit-source-id: c848b177753643febac1d6646d62a27ebace9238
Summary:
## Summary
When transpiling `react-native` with `swc` this file caused some trouble
as it mixes ESM and CJS import/export syntax. This PR addresses this by
converting CJS exports to ESM exports. As
`ReactNativeViewConfigRegistry` is synced from `react` to `react-native`
repository, it's required to make the change here. I've also aligned the
mock of `ReactNativeViewConfigRegistry` to reflect current
implementation.
Pull Request resolved: https://github.com/facebook/react-native/pull/40787
Test Plan: Sandcastle tests
Reviewed By: noahlemen
Differential Revision: D50229257
Pulled By: javache
fbshipit-source-id: 2e848a1ac434c45e219876c1042aacb42c77cb6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40885
We no longer need this hotfix since the native fix has been stable for some time now. Cleans up the feature flags and forced `collapsable={false}` prop in View.
## Changelog
[General][Internal]
Reviewed By: yungsters, NickGerleman
Differential Revision: D50241092
fbshipit-source-id: 57a3121356736bd6633e3672e6a8369067e45811
Summary:
X-link: https://github.com/facebook/litho/pull/962
Pull Request resolved: https://github.com/facebook/react-native/pull/40804
X-link: https://github.com/facebook/yoga/pull/1420
This stack is ultimately aiming to solve https://github.com/facebook/yoga/issues/1208
**The problem**
Turns out that we do not even check direction when determining which edge is the leading (start) and trailing (end) edges. This is not how web does it as the start/end is based on the writing direction NOT the flex direction: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_flexible_box_layout/Basic_concepts_of_flexbox#start_and_end_lines. While web does not have marginStart and marginEnd, they do have margin-inline-start/end which relies on the writing mode to determine the "start"/"end": https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start.
This means that if you do something like
```
export default function Playground(props: Props): React.Node {
return (
<View style={styles.container}>
<View style={styles.item} />
</View>
);
}
const styles = StyleSheet.create({
container: {
marginEnd: 100,
flexDirection: 'row-reverse',
backgroundColor: 'red',
display: 'flex',
width: 100,
height: 100,
},
item: {
backgroundColor: 'blue',
width: 10,
},
});
```
You get {F1116264350}
As you can see the margin gets applied to the left edge even thought the direction is ltr and it should be applied to the right edge.
**The solution**
I ended up fixing this by creating a new `leadingLayoutEdge` and `trailingLayoutEdge` function that take the flex direction as well as the direction. Based on the errata, the a few functions will use these new functions to determine which `YGEdge` is the starting/ending.
You might be wondering why I did not put this logic inside of `leadingEdge(flexDirection)` / `trailingEdge(flexDirection)` since other areas could potentially have the same bug like `getLeadingPadding`. These functions are a bit overloaded and there are cases where we actually want to use the flexDirection to get the edge in question. For example, many of the calls to `setLayoutPosition` in `CalculateLayout.cpp` call `leadingEdge()` / `trailingEdge()` to set the proper position for cases like row-reverse where items need to line up in a different direction.
Reviewed By: NickGerleman
Differential Revision: D50140503
fbshipit-source-id: 5b580c7570f6ae1e2d031971926ac4e8f52dd362
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40879
Introduce StableReactNativeAPI annotation, the goal of this annotation is to describe classes, interfaces and members that are considered Stable and will remain part of the new architecture of React Native
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D50195996
fbshipit-source-id: a64a27217a6fd885d2c188a6847565b3413bb232
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40860
This diff adds support for the `AS` expression in TS sources. The following codegen declaration should work now:
```
export default codegenNativeComponent<NativeProps>(
'MyComponentView',
) as HostComponent<NativeProps>;
```
Changelog: [General][Added] - Handle TSAsExpression when looking for the codegen declaration
Reviewed By: shwanton
Differential Revision: D50225241
fbshipit-source-id: 247a3d341d742b548e82318d0fa21dff9884d2bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40871
If we pass isPressable to the native props object (via TextAttributes), we can use this information to bypass hit testing on some spans. This is rather important on some platforms where pointerenter/pointerleave/ mousemove events force frequent hit testing.
## Changelog:
[General] [Internal]
Reviewed By: javache
Differential Revision: D50228473
fbshipit-source-id: 4fce85f4b18617fbe10d3c804e943484bf990664
Summary:
Adds changelog for the 0.71.14 version.
## 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.71.14 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/40863
Reviewed By: robhogan
Differential Revision: D50228147
Pulled By: huntie
fbshipit-source-id: cb6ad2abac53825a935205fb7646d8fa32ba8302
Summary:
The reference to runtime assumes the queue will ensure references to runtime are valid when invoked. This
isn't the case if you create a breakpoint, Hermes hit that breakpoint and your refresh the app. This consistently
will crash the app.
The fix is to not assument this, similar to ReactCommon/react/runtime/hermes/HermesInstance.cpp
Reviewed By: javache
Differential Revision: D50225678
fbshipit-source-id: b45cae1f5f687bc8c699fd74b187376a547012c5
Summary:
## Changelog:
[Internal] - Fix Nighlties that were broken due to changes for double publishing
Reviewed By: cortinico
Differential Revision: D50225219
fbshipit-source-id: dd1b96a956bb282caa40bd6f99b9a82554958746
Summary:
I'm removing the node >= 18 restriction on react-native/normalize-colors as that's unnecessary
as is currently breaking the ecosystem for users on Node 16 on previous versions of React Native.
Changelog:
[General] [Fixed] - normalize-colors should not impose node >= 18
Reviewed By: robhogan
Differential Revision: D50215144
fbshipit-source-id: cdfb90f4274754ad5b04fa2cad339419d45bbcba
Summary:
## Changelog:
[Internal] - Run all the tests in CI when not on a PR
Reviewed By: cortinico
Differential Revision: D50220596
fbshipit-source-id: be1a30d713e9d427858cf22bd3ca9549ad513057
Summary:
This is just a type refactoring to make the typing of the `defaultSource` prop of the Image component more explicit and descriptive (using the `ImageRequireSource` type makes it more clear that we can use the require statement to set an image asset as default source) and this is also more consistent with the `source` prop typing.
Currently :
- The typing of default source is `ImageURISource | number | undefined`
- The typing of source is `ImageSourcePropType` which is equal to `ImageURISource | ImageURISource[] | ImageRequireSource` and `ImageRequireSource` is equal to `number`.
In this PR we change the typing of default source to `ImageURISource | ImageRequireSource | undefined` to make more clear that the number of the default source prop refers to the use of the require statement with an asset file.
## Changelog:
[GENERAL] [CHANGED] - use ImageRequireSource instead of number for the defaultSource prop typing of the Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/40801
Test Plan: No one required since it's a small typing refactoring.
Reviewed By: christophpurrer
Differential Revision: D50209922
Pulled By: NickGerleman
fbshipit-source-id: c25f3c6f145f357ff1cb0b1c7b54a19bf1dec824
Summary:
It looks like objects properties aren't guaranteed to have a stable order. Sort them, before we serializae and print them to the screen in the interop test. This should reduce interop test flakyness.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D50148860
fbshipit-source-id: a6ed1433d4dd35cafa5c9f7d09c4cca194c31d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40792
Similarly to D49792717, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49862756
fbshipit-source-id: 289f2d5ef622f47eb3fccf0cc7a52cc13a83b028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39952
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
Changelog: [General] Deprecated RAIICallbackWrapperDestroyer. Use AsyncCallback instead for safe jsi::Function memory ownership.
Reviewed By: RSNara
Differential Revision: D49792717
fbshipit-source-id: 9f2f3b00c71ad1b86427dee3749c6d98ef0f5678
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40794
I accidentally stumbled upon the `UIManager` object on JS side and realised it was being exported as `any`. So I've extracted the interface `UIManagerJSInterface` and applied where it seems to make sense, although, after chatting with javache it could be useful to further narrow down the interface given what's currently implemented by the `BridgelessUIManager`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50137691
fbshipit-source-id: ccc746fa1dfbb3290e0b73dfa14c65833b238e07
Pieter De Baets
Nicola Corti
Moti Zilberman
Gijs Weterings
Riccardo Cipolleschi
Rob Hogan
Filipp Mikheev
Yicheng (Jerry) Gong
Arushi Kesarwani
Ramanpreet Nara
Alex Hunt
Rob Hogan
Eric Rozell
Jakub Romanczyk
Christoph Purrer
Joe Vilches
David Vacca
Sam Zhou
Dmitry Rykun
fortmarek
Alex Hunt
Blake Friedman
Riccardo Cipolleschi
Skander Ellouze
Fabrizio Cucci