Summary:
I believe these two were the last items under `com.facebook.debug` that were still Java.
I thought about making DebugOverlayTag a Data class, but i will leave it up to the reviewer to decide if it would be needed or not.
## Changelog:
[INTERNAL] [FIXED] - Migrate DebugOverlayTag and ReactDebugOverlayTag to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/47362
Test Plan:
`./gradlew test`:
<img width="1265" alt="Screenshot 2024-11-02 at 18 45 45" src="https://github.com/user-attachments/assets/405e77bc-1287-4329-b230-9f46eadb3580">
Reviewed By: javache
Differential Revision: D65417984
Pulled By: cortinico
fbshipit-source-id: e39224e40bde281498fdbed1609a03b264967396
Summary:
While we (Margelo) were developing a new C++ 3D library for react-native, we noticed that Java often keeps a lot of dead instances in memory, making it hard to debug memory allocations (or actually _de_-allocations), especially since we use `jsi::HostObject` and `jni::HybridClass` in conjunction. Having two garbage-collected languages retain an object is a bit tricky, and making sure that we aren't doing anything wrong with our allocations and references was not easy - but manually calling `System.gc()` on app reloads helped us see that much better.
Before this, we needed to wait multiple minutes until some Java objects are actually freed from the GC. Our use-case was a `facebook::jni::HybridClass`, which was held strong in a `facebook::jsi::HostObject` (so again, two GC'd languages).
There _should_ be no change in behaviour with this PR, just two things to note:
1. Memory might be free'd more eagerly in full reloads (dev builds) - makes sense for library developers, especially when working with C++ modules.
2. `System.gc()` only _suggests_ garbage collection, it does not _force_ it. But when it runs, it might impact performance, although we haven't noticed any impact of that at all. The garbage collector runs anyways - better during a reload than later when exceuting the app normally.
## 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] [ADDED] - Trigger Java GC on app reload
Pull Request resolved: https://github.com/facebook/react-native/pull/43813
Test Plan:
Open an app, create a Java module that holds a few objects, add `finalize()` methods to those objects and log their deletion.
Reload the app to see the logs, compare before vs after.
Reviewed By: rshest
Differential Revision: D65418163
Pulled By: javache
fbshipit-source-id: 7597548790577dfc542b57f59578ae48df543b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47369
This just bumps the AGP patch version to the latest stable.
Changelog:
[Android] [Changed] - AGP to 8.7.2
Reviewed By: tdn120
Differential Revision: D65336357
fbshipit-source-id: 9a7464304ba29f6b752f41b252bde9cb0eca0e9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47357
`MultiSourceHelper` should not yield an `ImageSource` that has its cache control policy set to `RELOAD`. This change skips such sources when computing the bestCached item (but not best item)
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D65337414
fbshipit-source-id: bdd0d55f4a65128b141a1c7a132dba085232fa11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47356
Add utf16 method to JSI. This change will add the default implementation
for all VMs by calling UTF8 and manually convert it to UTF16. A later
change will be added for Hermes to use internal VM information to get
the UTF16 string.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D64918244
fbshipit-source-id: 6fc0c44fc397c2f8bb40a4262596b178ee4f1f29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47333
Motivated by https://github.com/facebook/hermes/issues/1549. This was originally changed in https://github.com/facebook/react-native/pull/46696, as our internal Flow support had diverged from `babel/eslint-parser` (https://github.com/facebook/react-native/issues/46601).
We effectively have three flavours of JavaScript in support:
- Flow@latest for the `react-native` package, shipped as source — uses `hermes-parser`.
- TypeScript for product code (community template, Expo) — uses `babel/plugin-syntax-typescript`.
- Plain JavaScript or Flow in product code, *which may be extended with additional user Babel plugins and needs lenient parsing* — uses `babel/plugin-syntax-flow` via `babel/eslint-parser` (**this change**).
I'd love to simplify this 😅.
Switching to `hermes-eslint` for the RN monorepo codebase (D63541483) is unchanged.
Changelog: [Internal]
Reviewed By: robhogan, cipolleschi
Differential Revision: D65272156
fbshipit-source-id: 3a2bbe3fcf8ed6057f6d994a0be4985e6bf46fa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47339
Fixing issue raised in https://github.com/facebook/react-native/issues/47307
This is a follow up from D62286026.
It appears there was a line that went missing while trying to refactor the code.
`fitsSystemWindows = true` is needeod for < API 30 to avoid content rendering under the system bars when Modal is shown with Activity that is edge-to-edge.
Changelog:
[Android][Fixed] Fix Regression - Modal content rendering below system bar on < API 30 when activity is edge-to-edge
Reviewed By: cortinico
Differential Revision: D65280014
fbshipit-source-id: 616ff739be55635f1295ef3bf8b997a27ef769ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47342
There are things we can do to modernize `FBHashKit` to make it ready for prime time, aka Layer Zero.
* Consolidate down to a singular `meta_hash(...)` generic macro (supports all primitives for hashing)
* Eliminate the unnecessary C++
* Deprecate legacy FB APIs
* Make logic (and interfaces) explicit for 32 vs 64 bit inputs and 32 vs 64 bit outputs
* Introduce robust unit tests
* Have unit tests actually testable for 32-bit hashes
## Changelog
[Internal][Change] Prep to move `FBXXHashUtils`
Reviewed By: cipolleschi
Differential Revision: D65245787
fbshipit-source-id: 311404068fd9df2a77d1ae4850b8a785466e73f0
Summary:
Depracated usage of scrollInsets + an unused param.
## Changelog:
[INTERNAL] [FIXED] - Switch to verticalScrollIndicatorInsets and mark unused value as __unused in test file
Pull Request resolved: https://github.com/facebook/react-native/pull/47314
Test Plan:
Running the specific test itself, it passes:
<img width="1092" alt="Screenshot 2024-10-30 at 18 02 08" src="https://github.com/user-attachments/assets/e3ed27c6-9f00-4777-a72c-92f0da93a79f">
Reviewed By: NickGerleman
Differential Revision: D65231365
Pulled By: philIip
fbshipit-source-id: eed795ad65bd837fb9f38175081d961245ff3932
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47320
I've solved all the warnings on ReactAndroid/hermes-engine.
This enables warningsAsErrors for that part of the codebase so we can make sure
no further warnings get introduced.
Changelog:
[Internal] [Changed] - Enable warningAsErrors for hermes-engine
Reviewed By: NickGerleman
Differential Revision: D65243753
fbshipit-source-id: 17c22d1a7a32d2c684d7f236f7554f6e26469e99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47340
This diff cleans up some problematic `React.ElementRef<T>` when T is generic type.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D65280467
fbshipit-source-id: 71172b16320a10cbc7a8b46dae5d3dd0eb00ba0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47337
We call `onSurfaceStart` after calling `surfaceHandler.start()`. In theory it's possible for the React surface to start generating commits before we've informed the mounting manager of the surface having started, which could cause us to not accurately track views allocated for that surface so far.
Changelog: [Android][Fixed] Addressed race condition in surface start.
Reviewed By: rshest
Differential Revision: D65269674
fbshipit-source-id: 2927220bc17e61125dabcdd75f5325a0ca77e60b
Summary:
Fixes https://github.com/facebook/react-native/issues/12606
Previously, `Image` cache control options were not functional on Android, even though they were being passed to the native component via the `source` prop. This PR addresses that by implementing logic to manage cache behaviour on Android.
When the `reload` option is explicitly set, the image is now evicted from both memory and disk caches before a new request is made. This ensures the image is always fetched from the source, aligning the caching behaviour between Android and iOS for the `default` and `reload` options.
## Changelog:
[ANDROID][ADDED] - Enabling basic `Image` cache control for Android
Pull Request resolved: https://github.com/facebook/react-native/pull/47182
Test Plan:
Added a new example to the `rn-tester`, where we can notice that the image on the right is reloaded if rendered or re-rendered as the cache policy is set to `reload`. The image on the left has the cache policy set to `default` and won't be re-rendered as the image is already in the cache. See the video below:
https://github.com/user-attachments/assets/88bc1d2d-0239-4deb-bcde-fe0ce521ff4d
Also tested on both old and new architecture.
Reviewed By: NickGerleman
Differential Revision: D64915440
Pulled By: Abbondanzo
fbshipit-source-id: 32e1c55dd20bf96ab0f69ef900d821c3c2552ef7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47231
changelog: [internal]
`EventEmitter::dispatchEvent` and `EventEmitter::dispatchUniqueEvent` that were accepting shared_ptr are not needed. Their functionality is covered by other methods. Let's get rid of them to keep the API of EventEmitter slim.
Reviewed By: rubennorte
Differential Revision: D65040505
fbshipit-source-id: cffdc3ef042418178c5e2e5714779dfd0b61455e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47329
Downgrading from fatal (introduced in D63148523). It's not yet clear why this is firing, and may point at deeper underlying issues, as the re-ordering we do in `disableMountItemReorderingAndroid` only occurs at a later point in `FabricMountingManager`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65267936
fbshipit-source-id: cb32b149a77c9e5a3ac6350baaeae9c7215df01b
Summary:
This pr is part of issue https://github.com/facebook/react-native/issues/46757 solving a task - [ME2E0008] [ME2E0009]
- Set up a test
- Starts the app
- Scrolls until flatlist is visilbe and clicks on flatlist
- Click basic button
- Scroll down until item 600 is visible
## Changelog:
[Internal] [Added] - Add e2e-test logic that click button & scroll down until specific item is visible
Pull Request resolved: https://github.com/facebook/react-native/pull/46804
Test Plan:
### Test Locally
- iOS
```bash
yarn install
cd packages/rn-tester
yarn e2e-build-ios
```
- Android
```bash
yarn install
cd packages/rn-tester
yarn e2e-build-android
```
### Start Maestro
- iOS
```bash
cd packages/rn-tester
yarn e2e-test-ios
```
- Android
```
cd packages/rn-tester
yarn e2e-test-android
```
### Test in CI
To test in CI, just add a comment on your PR with the text:
```
/test-e2e
```
Reviewed By: cortinico
Differential Revision: D63829274
Pulled By: cipolleschi
fbshipit-source-id: f7b4342ed353a48123f87dcfd8d503009f65637c
Summary:
This pull request fixes a style bug in the AnsiHighlight component when the application is in Right-To-Left (RTL) mode. The adjustments ensure that text highlighting is visually consistent and functions properly across all layout modes.
### Before
| Android RTL | iOS RTL | Android LTR | iOS LTR |
|----------|----------|----------|----------|
|  |  |  |  |
### After
| Android RTL | iOS RTL | Android LTR | iOS LTR |
|----------|----------|----------|----------|
|  |  |  |  |
## Changelog:
[GENERAL] [Fixed] - AnsiHighlight style in RTL layout
<!-- 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/47230
Test Plan:
To test the changes, open LogBox while the app is in RTL mode. The modifications ensure that any error messages display correctly. I have verified that the changes function properly in both LTR and RTL modes, and all existing functionality remains unaffected.
This is an example component to throw an error to show LogBox.
```tsx
import React from 'react';
import {Alert, Button, I18nManager, StyleSheet, Text, View} from 'react-native';
function SampleError() {
return (
<View>
<Button
title="Change to RTL"
onPress={() => {
I18nManager.allowRTL(true);
I18nManager.forceRTL(true);
Alert.alert('Restart app to apply changes');
}}
/>
<Button
title="Change to LTR"
onPress={() => {
I18nManager.allowRTL(false);
I18nManager.forceRTL(false);
Alert.alert('Restart app to apply changes');
}}
/>
<Text style={styles.text}>
isRTL: {I18nManager.isRTL ? 'true' : 'false'}
</Text>
<Button
title="Show Error"
onPress={() => {
console.error('sample خطا');
}}
/>
</View>
);
}
const styles = StyleSheet.create({
text: {
fontSize: 24,
textAlign: 'center',
paddingVertical: 20,
},
});
export default SampleError;
```
Reviewed By: sammy-SC
Differential Revision: D65145991
Pulled By: NickGerleman
fbshipit-source-id: cbca106813e587ed223be48b75ee5279072c2da0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47322
Changelog: [Internal]
these callsites were causing crashes in new bridgeless integrations, it appears they are not used, so cleaning up. after this, we can remove all callsites that insert ReactNativeConfig to the contextContainer.
Reviewed By: javache
Differential Revision: D65191733
fbshipit-source-id: 94e694ef27249773c2a39bd77f316f8f5cc2b1fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47321
Changelog: [Internal]
this seems to be the last callsite where we read the ReactNativeConfig from the contextContainer. i don't think this killswitch should block cleanup of the ReactNativeConfig, so maybe we can just remove this?
Reviewed By: cortinico
Differential Revision: D65192744
fbshipit-source-id: d8b595edb6fecce05e67abc257d98805daa16a9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47313
We're going to fix up a bunch of designated initializers. `RCTSurfaceHostingProxyRootView` is particularly problematic because different initializers will do different things even though reading the code it looks like they should be equivalent. Remove the encapsulated "start" to the provided "surface", and require it to be explicit at the callsite.
## Changelog:
[iOS][Changed] - `RCTSurfaceHostingProxyRootView` no longer has different behavior (whether it calls `start` on the provided *surface*) depending on which initializer is used. Call `start` yourself on the *surface* instead.
Reviewed By: cipolleschi
Differential Revision: D65214656
fbshipit-source-id: 179d5220d4f866b4452561e1bb6e2051020c8a11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47297
In this diff I'm proposing to remove configuration for RCTConstants.RCTGetMemoryPressureUnloadLevel API in iOS
changelog: [iOS][Breaking] Delete experimental API RCTConstants.RCTGetMemoryPressureUnloadLevel
Reviewed By: rubennorte, philIip
Differential Revision: D65181556
fbshipit-source-id: c435bec6ed03562b53f1924add7b69ab517b190b
Summary:
This PR introduces `RCTArchConfiguratorProtocol` for better separation of concerns inside of RCTAppDelegate.
It's also a prerequisite for https://github.com/facebook/react-native/issues/46298
Discussed with cipolleschi
## Changelog:
[IOS] [ADDED] - introduce RCTArchConfiguratorProtocol
Pull Request resolved: https://github.com/facebook/react-native/pull/47306
Test Plan:
- CI Green
- Test if methods can be overriden
Reviewed By: realsoelynn
Differential Revision: D65212703
Pulled By: cipolleschi
fbshipit-source-id: 9850fec31c421f0c6230e7e23d7a208d823d828f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47302
changelog: [internal]
The original cancellation logic cancelled image request when RCTImageComponentView was recycled but the image request was never resumed.
So in case the request was cancelled and later the same shadow node representing the image view was showed, the image request was never fulfilled and it stayed blank. It entered invalid state from where it would never recover. The image would go from state: Loading -> Cancelled and Cancelled is terminal state.
This diff adds a "resume" mechanism. If image goes from Loading -> Cancelled and something subscribes to the image state, the image request will be started again.
So we can go from Loading -> Cancelled -> Loading -> Completed.
This diff also moves the resume/cancel mechanism to ImageResponseObserverCoordinator. Where we can observe if anything is observing result of the image response.
Even though this case was highly unlikely, with <Activity /> component in React Native, it may occur.
Reviewed By: lyahdav
Differential Revision: D65149804
fbshipit-source-id: d59c1793785a367bb92602f6438666fa53db4ceb
Summary:
in the `image component`, add the ts definition with the `resizeMethod` attribute value as `none`.
## Changelog:
[Android][Fixed] - the definition of ts of resizeMethod attribute is none.
Pull Request resolved: https://github.com/facebook/react-native/pull/47227
Test Plan: <img width="579" alt="image" src="https://github.com/user-attachments/assets/e91dc47a-22c4-4d47-a4c2-6497d47cb842">
Reviewed By: javache
Differential Revision: D65058737
Pulled By: Abbondanzo
fbshipit-source-id: a077e4e4786a72ebffaf0698217809b1e7fde226
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47241
Changelog: [internal]
The options for the internal constructor of `PerformanceMeasure` shouldn't be optional. This just cleans that up.
Reviewed By: rshest
Differential Revision: D64480048
fbshipit-source-id: d0275276b11bd329aa2e4667646c67608d562299
Summary:
This PR introduces `RCTUIConfiguratorProtocol` for better separation of concerns inside of RCTAppDelegate.
It's also a prerequisite for https://github.com/facebook/react-native/issues/46298
Discussed with cipolleschi
## Changelog:
[IOS] [ADDED] - introduce RCTUIConfiguratorProtocol
Pull Request resolved: https://github.com/facebook/react-native/pull/47139
Test Plan:
- CI Green
- Test if methods can be overriden
Reviewed By: blakef
Differential Revision: D65063839
Pulled By: cipolleschi
fbshipit-source-id: b63766e245d57f369ab94bd8047d5de9a3447b3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47271
Let's keep the recent goals of centering (instead of arbitrary prioritizing ascent), ala spec, and make some changes to allow overlapping interior line-boxes, and make the implementation a lot simpler, instead of the cruft it has been accumulating.
The new simple versions is implemented as the only `CustomLineHeightSpan`. This replaces the code used when `enableAndroidLineHeightCentering` is enabled (which is now the default).
Legacy path is renamed to `LegacyLineHeightSpan`, slated to be deleted if rollout goes well.
We cannot yet cause text to overflow the bounds of the underlying TextView until potentially large later work related to ReactTextView reimplementation.
There's a somewhat arbitrary choice here, when rounding, to whether we ceil ascent vs descent when pixels don't evenly split. This does result in a visual difference, and for sake of avoiding breakage of screenshots, I left the same choice as before.
Changelog:
[Android][Fixed] - Reimplement Android lineHeight positioning/determination
Reviewed By: javache
Differential Revision: D64716557
fbshipit-source-id: 5a947377df7cfee9dff4484c840939f527caf94b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47270
Lets add some screenshot tests, along with one more example, and fixing some silly typos in test IDs.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65094482
fbshipit-source-id: a5f3e06c4737158bf6419364d05668c3feb1bd5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47282
D63318754 fixed a class of issues with RTL horizontal scrollviews by moving logic from native Android view layer to Fabric ShadowNode layer.
I realized quite a bit later this is problematic for legacy arch, since it now never runs RTL translation code, and all our RTL screenshot tests are against new arch.
It's tricky to port Fabric ShadowNode related code to Paper since its shadownodes are more coupled to Yoga nodes, and the existing solution for contextual layout direction didn't quite work, so I went with the original logic we had for this, where we use global layout direction to determine whether to offset, and disable removeClippedSubviews, and this is applied via onLayout. This is wrong in several ways, but not a regression compared to previous legacy arch behavior. The fully correct behavior will require new arch.
Changelog:
[Android][Fixed] - Fix legacy arch RTL horizontal ScrollView regression
Reviewed By: rshest
Differential Revision: D65139747
fbshipit-source-id: 5662c0744c3c402efe583e602b2272662b4d5476
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47280
Noticed in the screenshots of https://github.com/facebook/react-native/pull/47230 that Android's logic of setting scroll content origin to zero, then right aligning scroll offset, won't correctly handle case where content is smaller than scrolling container. We can fix that by only resetting the origin when content overflows container, since we otherwise are not scrollable, and scroll adjustment will not translate.
Changelog:
[Android][Fixed] - Fix RTL ScrollView position when content smaller than container
Reviewed By: rshest
Differential Revision: D65136654
fbshipit-source-id: 2818ff6360cbfac64d7e57bdcbbe8c0a9b4bbb97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47284
If the surface hasn't been set up yet, attempting to fetch the ReactRootView will throw a null reference exception. Since the result is already nullable, it's perhaps better to just return null when the surface has not yet been initialized.
## Changelog
[Android][Fixed] Avoid null reference exception in bridgeless ReactDelegate
Reviewed By: javache
Differential Revision: D65141137
fbshipit-source-id: 9b002b0520a7eeea61767cb8934e9bb8d049fc6a
Summary:
## Changes
If the c++ pipeline is active:
If someone calls console.error:
- The c++ pipeline will report it as a soft error
If someone reports an error:
- The c++ pipeline will log it via console.error
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64506069
fbshipit-source-id: 293cd1774f19ee03d7eb61572b7b1f03a47a4756
Summary:
Now, all ios apps will just be integrated with the c++ error reporting pipeline, with zero configuration.
Changelog: [Internal]
Reviewed By: javache, philIip
Differential Revision: D64615457
fbshipit-source-id: db9d98115238d9a42563e39a4780234a9bc3c034
