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:
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:
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:
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:
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
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).
I'm also bumping the docker container to v12 as we bumped NDK 26 which is missing in the v11 container.
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/39956
Test Plan: CI should be green
Reviewed By: christophpurrer
Differential Revision: D50019777
Pulled By: cortinico
fbshipit-source-id: a2ab7a7bd7c55624d5c050b45e69086c5f25ba6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
Summary:
Currently, when we build the app in production mode the `DevtoolsOverlay` & `TraceUpdateOverlay` are bundle
## Changelog:
[GENERAL][REMOVED]: removed `DevtoolsOverlay` & `TraceUpdateOverlay` from production bundle
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/40749
Test Plan:
1. Build the app in production mode
2. Check that both `DevtoolsOverlay` & `TraceUpdateOverlay` are included in the bundle
Reviewed By: robhogan, NickGerleman
Differential Revision: D50121208
Pulled By: hoxyq
fbshipit-source-id: 3e1fb506c679ec79b116dea9772d372cd2ea9ca9
Summary:
Commit 8b88883071 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo
## Changelog:
[Internal] - Bump RNTester cache keys
Pull Request resolved: https://github.com/facebook/react-native/pull/40789
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D50169281
Pulled By: cipolleschi
fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39988
Changelog: [Internal]
in this pr, we integrate the sync void configuration with our feature flag infra
Reviewed By: luluwu2032
Differential Revision: D50030743
fbshipit-source-id: 03505e5e1f74aa90dc16f33fa4e93f9de9660dae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39989
Changelog: [Internal]
we need some configuration path to turn on the sync void method execution behavior, doing that here
Reviewed By: luluwu2032
Differential Revision: D50028200
fbshipit-source-id: a2501b622685e4bafa5e2a5031275cc8bc5050b7
Gijs Weterings
Filipp Mikheev
Yicheng (Jerry) Gong
Arushi Kesarwani
Ramanpreet Nara
Nicola Corti
Alex Hunt
Rob Hogan
Pieter De Baets
Eric Rozell
Jakub Romanczyk
Joe Vilches
David Vacca
Sam Zhou
Dmitry Rykun
Blake Friedman
Skander Ellouze
Riccardo Cipolleschi
Fabrizio Cucci
Lulu Wu
Luis Miguel Alvarado
Krystof Woldrich
Ivan Alexandrov
Alex Hunt
Kacper Kafara
generatedunixname89002005325672
Riccardo Cipolleschi
Gabriel Donadel
Phillip Pan