Summary:
Upgrade jsc-android to latest stable version. Hopefully this should finally fix https://github.com/facebook/react-native/issues/25494.
Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable
## Changelog
[Android] [Changed] - Upgrade jsc-android to 250230.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31304
Test Plan: Launch app with new jsc-android and see everything works fine.
Reviewed By: TheSavior
Differential Revision: D28630503
Pulled By: yungsters
fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary:
JS side expects the property name to be "actionName", and this change updates it to that.
Changelog:
[iOS][Fixed] - Use actionName in accessibility event callback
Reviewed By: JoshuaGross
Differential Revision: D28645999
fbshipit-source-id: 0e7a6c3e6c1b6c998f4b53fd89c744c84083dfb1
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:
`isColorMeaningful` is the only place in xplat code that currently uses `colorComponentsFromColor`, which assumes that a color is an RGBA value. When implementing `PlatformColor` for windows, where colors might be complex patterns or effects, I'd like to keep the details of `SharedColor` isolated within `SharedColor`. This change moves `isColorMeaningful` into `color.cpp`, where each platform can provide an implementation that takes into account its platform specific color capabilities.
See https://github.com/microsoft/react-native-windows/pull/7801 for an example of window's SharedColor which can be either an RGBA value, or a name of a native color/brush.
## 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] [Changed] - Move isColorMeaningful to platform specific code
Pull Request resolved: https://github.com/facebook/react-native/pull/31557
Test Plan: This shouldn't change any of the code, its just moving the existing function - normal CI/automation should be plenty of validation.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D28557698
Pulled By: mdvacca
fbshipit-source-id: 2a94850fe9c5037598107e1307f4153cee6491fb
Summary:
Changelog: [internal]
My suggestion is to simplify event dispatching to only two options, synchronous and asynchronous.
Why?
- Fabric has only been using one queue, `AsynchronousBatched`.
- Batching happens even on `AsynchronousUnbatched`. It just batches events until JS thread starts processing them instead of waiting for the main run loop.
- It will make it easier to reason about the code in the future once we start utilising different priorities for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D28603472
fbshipit-source-id: 14e3a9c15a012c550dc16a044c31d722051a2bdc
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:
EventDispatcherImpl uses synchronized blocks all over to make it thread-safe. I'm concerned about the perf implications of this and creating contention between JS and UI threads.
This is locked behind a feature flag.
Enabled only for Fabric in StaticViewConfig mode, and a feature flag, for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28591331
fbshipit-source-id: ea8f93a2e1343ce37fa78690dcb62fe03594120f
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:
Accessibility service does not announce "selected" on accessibilityState = {selected: true} of the Button Component.
Issue link - https://github.com/facebook/react-native/issues/30956
## 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
-->
[General] [Added] - Add accessibilityState prop to Slider component
Pull Request resolved: https://github.com/facebook/react-native/pull/31145
Test Plan:
Verified accessibility states are read by voiceover and talkback. Some state values aren't handled by iOS and have been identified.
Added snapshot tests to test accessibilityState.disabled = disabled values
`js1 test Slider-test`
Reviewed By: yungsters
Differential Revision: D28337723
Pulled By: lunaleaps
fbshipit-source-id: 72a54d8d9dcf1fafb9785c81da99f32a21f3df00
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, TurboModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the TurboModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435429
fbshipit-source-id: fe945d616b97ed89f48b914b064e518b122a7b7b
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:
Changes `ExceptionsManager` in React Native so that errors with a `type` property equal to `'warn'` are not reported.
This change is banking on the fact that `type` is a non-standard and uncommon property on `Error` instances. If this ends up being problematic, we can instead change this to use a `unstable_type` or `unstable_level` property instead.
Changelog:
[General][Changed] - ExceptionsManager will no longer report exceptions with `type === 'warn'`.
Reviewed By: motiz88
Differential Revision: D28421692
fbshipit-source-id: 3ca19e29f32c8c5cad6dac637dcb930944fb24ed
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:
FlatList relies heavily on onScroll events + the measure API. In Fabric, usage of `measure` relies on C++ having an accurate view of the current scroll position of the ScrollView.
We already have a mechanism for updating the scroll position in C++ using UpdateState. But, it is only used currently at the /beginning/ and /end/ of scrolling, and UpdateState is not called /during/ scrolling at all.
This means that we will see a series of events like this while scrolling:
```
Scrolling begins
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 0
JS event: onScroll x=0, y=0
JS event: onScroll x=0, y=100
JS event: onScroll x=0, y=200
...
JS event: onScroll x=0, y=1000
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 1000
```
Notably, not many C++ state updates are queued; and the last one is queued AFTER the JS event is sent. The last JS event and UpdateState will race, which means that sometimes the C++ update will /lose/ and C++ will have an inaccurate view of the world when FlatList receives the onScroll event and calls `measure`.
My proposed solution, gated behind a feature flag, is to delay /some/ onScroll events until the C++ UpdateState has made its way back to Java, and send UpdateStates more frequently. The balance here is that UpdateState is a relatively expensive operation, so we probably still want to call it /less/ than we call onScroll. This means that `measure` will still return some incorrect results but will return correct results more frequently. Win?
Changelog: [Internal[
Reviewed By: mdvacca
Differential Revision: D28558380
fbshipit-source-id: 11c7cd714fae67ee5a94c4413be988481413ec03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
While we are still waiting for Android results, we can safely ship this on iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28542478
fbshipit-source-id: 2673cc4bea0edbc7e4211be7bfec9779205d721b
Summary:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Cleans up `reactConsoleErrorHandler` in `ExceptionsManager` using modern language features, and fixes a minor edge case with how warning-like errors are handled.
Changelog:
[General][Fixed] - Avoid downgrading `console.error` when passed warning-like objects.
Reviewed By: GijsWeterings
Differential Revision: D28418488
fbshipit-source-id: 394e8608c2c81c794c9a0fc155142dcfcfe1c661
Summary:
WITH_FBREMAP was an experiment that is no longer needed. Just disabling the flag for now, the code will be deleted in a separate commit.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28467996
fbshipit-source-id: cb7bc00ea0b9d6e82219dda5148ab29978ddc83d
Summary:
Changelog:
[Internal] - In internal e2e testing, json.stringify is unstable and will occasionally re-order keys. Fix so it's consistent across tests
Reviewed By: kacieb
Differential Revision: D28397174
fbshipit-source-id: 0f2db697d245654c88c3dff3d083bc82890d4bc1
Summary:
It's not supported, and building with libc++ using its unstable ABI
exposes the issue. Include the header to get the complete type.
Changelog: [Internal]
Reviewed By: lanza, sammy-SC
Differential Revision: D28405500
fbshipit-source-id: 65e039a465d8d736eaecb89e82895889fd2379ca
Summary:
Bump the cli version as it caused an issue when running the e2e tests for the 0.65 release
It will fix an incorrect template path being generated and fail the test
## Changelog
Bumped react native cli ? Already in the changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/31548
Test Plan: This is just a yarn.lock update targeting the cli
Reviewed By: fkgozali
Differential Revision: D28513554
Pulled By: Huxpro
fbshipit-source-id: 2957cb9e0d994894c3ef10260ee6167f857bdeef
Summary:
FBJNI version have been updated recently and the new version is available on Maven Central, so we can remove this exception.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28355443
fbshipit-source-id: 1b3d88b668fed12deb786d36672f07dc98709aa0
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:
Minor cleanup of `ReactFiberErrorDialog` with no behavior changes.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28423265
fbshipit-source-id: 796777ca2c26d6d7cfae956299786151c74e937f
Summary:
This diff creates a ReactFeatureFlag to initialize MapBufferSo file during Fabric initialization.
This is necessary to be able to compare properly Mapbuffer vs ReadableNativeMap (because ReadableNativeMap c++ files is already included in the bridge so file)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D28436044
fbshipit-source-id: 338e1bb72b5313dc29a309e1b0e979e7c8bd1c18
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:
Creates a new `Animated.loop` example in RNTester that uses the native driver.
This example shows the precise problem fixed by facebook/react-native#29585 (D28383538 (129180c77b)).
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28406914
fbshipit-source-id: 63ea7799d4b8bef8b0c1caaa3daf514ca04b7ab1
Summary:
Changelog: [internal]
Only moves methods around so public and private methods are grouped together.
Reviewed By: JoshuaGross
Differential Revision: D28381588
fbshipit-source-id: dae7f493b99845f66070689270bc7aef958fbecd