Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50570
This diff makes the following file internal - ReactRawTextShadowNode and ReactRawTextManager
as part of our ongoing effort of reducing the API surface.
The only meaningful user of this API is this library:
https://github.com/iyegoroff/react-native-text-gradient
Which is umaintained (last supported version is RN 0.59) so I'm not considering this breaking.
Changelog:
[Android] [Changed] - Make ReactRawTextManager internal. We verified no popular libraries are impacted by this change
Reviewed By: mdvacca
Differential Revision: D72647702
fbshipit-source-id: 59a3646fdbc8f11907b4cf5056ff88c6dcec1cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50365
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made FabricUIManager.java nullsafe
Reviewed By: GijsWeterings
Differential Revision: D71979601
fbshipit-source-id: 599d87f0783a566c837aa70975a62f5f908a2294
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50371
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979591
fbshipit-source-id: 77369affbe4fd7411f149a4a2de869b48a1faa1a
Summary:
This PR aims to migrate UiThreadUtil from Java to kotlin as part of https://github.com/facebook/react-native/issues/50513
## 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][CHANGED]Migrate UiThreadUtil to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50536
Test Plan: Tested on RN tester with both new and old arch
Reviewed By: cortinico
Differential Revision: D72602041
Pulled By: arushikesarwani94
fbshipit-source-id: 9f45a139805819a21039eb640a0bd1583a3acde9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50565
This annotation is unused. It was referenced in the past with Buck1 OSS but now we can safely remove it.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D72645219
fbshipit-source-id: 0327fa562276193ad9f48dc81ea7a9fa0da19eee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50374
This diff breaks down ScrollView props into ScrollViewBaseProps to generate more readable TS types, re-exports AnimatedComponent and sets the default SectionList Item type to `any`.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D72061941
fbshipit-source-id: 439fcdb1540288d6e610cd535b1fed82243c3b7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50531
# Changelog: [Internal]
This should not have any functional changes, mostly refactoring the previous code, splitting it into smaller methods, better documentation and added tests.
Main changes are:
1. We are going to use smart pointers for `ProfileTreeNode`
2. Split single static method into multiple smaller methods of one class, less cognitive load and smaller context window
Reviewed By: robhogan
Differential Revision: D72401690
fbshipit-source-id: a1eed5501349dcd811661d91f3bf126a0daaacf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50538
Promises created from `Linking.sendIntent` calls never resolve, leaving them dangling. This change fixes the issue in two spots:
1. By calling promise.resolve directly after the startActivity call
1. By wrapping startActivity in a try/catch so any exceptions thrown are forwarded to the promise as a rejection
Changelog: [Android][Fixed] - Ensure Linking.sendIntent promises resolve or reject
Reviewed By: NickGerleman
Differential Revision: D72606918
fbshipit-source-id: cd437bf65bb631bc04f99b4d2e3d637f7e98b25e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50556
This class is effectively unused, I'm removing it.
It was package private also so no one in OSS could easily use it.
Changelog:
[Internal] [Changed] - Remove unused JSDebuggerWebSocketClient
Reviewed By: GijsWeterings
Differential Revision: D72567055
fbshipit-source-id: aa2fa62c05488d1560c0acfa0b21e2d934c34be2
Summary:
Looks like Jest E2E had significant issues with this test on both android and ios RNTester. I think it's because the view with the testID did not have any contents, which means the accessibility tools have trouble getting the proper context from it. By changing it to a nested view (with some padding to better inspect the borders, since that's what's important in this test) I think we have a better, more stable test case this way
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D72571911
fbshipit-source-id: a85266cf4a1696fdaedcc97ed2a7a05f086d35bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50549
As part of D72558674, I made SurfaceHandlerBinding.setProps nullable, to align with D71979601 - but I didn't realize this wasn't properly handled on the JNI side.
Changelog: [Android][FIxed] Fix crash when passing null initialProps
Reviewed By: lenaic
Differential Revision: D72632625
fbshipit-source-id: 82db1791ceb7c96248b6eea2eb1e6395edc308a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50528
Changelog: [internal]
This adds basic documentation for the IntersectionObserver Web API implementation in React Native.
Reviewed By: lenaic
Differential Revision: D72573107
fbshipit-source-id: 14ed318ae3691550bbe14a6da1184013ce0c60a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50527
Changelog: [internal]
This just defines an outline for the expected docs to be added to RN.
Reviewed By: GijsWeterings
Differential Revision: D72573497
fbshipit-source-id: a8e1c2cc0c6b966656d1089cd33b547174ace873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50525
Changelog: [internal]
Just a rename of the file and moving relevant documentation to the README.
Reviewed By: GijsWeterings
Differential Revision: D72562795
fbshipit-source-id: d675037376a0345dd7d178cf5863f4093eb74542
Summary:
This diff migrates the following file to Kotlin - CxxInspectorPackagerConnection
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - CxxInspectorPackagerConnection to Kotlin
Reviewed By: rshest
Differential Revision: D72566596
fbshipit-source-id: 046e7549841f64d73fed56d8bc8d70f2d3ea63e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50519
This diff migrates the following file to Kotlin - MultipartStreamReader
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - MultipartStreamReader to Kotlin
Reviewed By: rshest
Differential Revision: D72561124
fbshipit-source-id: d616bfc547ea6a773ebc1c45f97111ae7c7ec85a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50526
This change wants to automate the rotation of the issue triaging squad on Discord.
This is taking us a few minutes every week to rotate the oncall.
This change can save us some time.
The configuration file format is supposed to be like this:
```
{
"userMap": {
"discord-username1": "discord-id1",
"discord-username2": "discord-id2",
"discord-username3": "discord-id3",
"discord-username4": "discord-id4"
},
"schedule": {
"date1": ["discord-username1", "discord-username2"],
"date2": ["discord-username3", "discord-username4"],
}
}
```
## Changelog
[Internal] - Automate the issue triage oncall rotation
Reviewed By: cortinico
Differential Revision: D72569435
fbshipit-source-id: 435c13350cf503e99302775674e78a20e328e68d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50518
This diff migrates the following file to Kotlin - BridgeDevSupportManager
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - BridgeDevSupportManager to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72558373
fbshipit-source-id: 07a16dc479e967677b1aab8a6d4a4366994fd490
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50522
This diff migrates the following file to Kotlin - BridgelessDevSupportManager
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - BridgelessDevSupportManager to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72558016
fbshipit-source-id: 9c84f89dfca03991b1feb6f8c9ffe846350aafed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50520
This diff migrates the following file to Kotlin - DebugOverlayController
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - DebugOverlayController.java to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72557349
fbshipit-source-id: dd4a1c7204206189c176b36f81c6d54f5f780b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50521
This diff migrates the following file to Kotlin - DebugCorePackage
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - Migrate to Kotlin - DebugCorePackage
Reviewed By: javache
Differential Revision: D72556867
fbshipit-source-id: dc37538da7089f532dc3a617a8e7dbccc6e187e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50402
While investigating pointer events, I noticed that all Android views fire `onPointerLeave`/`onPointerEnter` in rapid succession on every button press. This is because Android fires `ACTION_HOVER_EXIT` on every frame before firing `ACTION_DOWN` (in the same frame). The logic in JSPointerDispatcher needed to be updated to account for this.
Unfortunately, `ACTION_HOVER_EXIT` events have no means of distinguishing between whether they were driven by the mouse actually leaving the view's bounds or by a button press. Some OS implementations fire this event on the frame just before leaving the view's boundaries while others fire after, so pure X/Y position isn't helpful enough. The button state property on `ACTION_HOVER_EXIT` also never gets set in some OS.
To work around this issue, this change posts a callback to the very next frame after receiving `ACTION_HOVER_EXIT`. If no `ACTION_DOWN` event was received in the same frame, it calls all the way through the existing logic. But, if an `ACTION_DOWN` event *is* received, we compare the event timestamps and if they match we don't post `onPointerLeave`.
Changelog: [Android][Fixed] - Prevent onPointerLeave from dispatching during button presses
Reviewed By: vincentriemer
Differential Revision: D72078450
fbshipit-source-id: dcc7cfa4086963ed8599147d60d8406c54cd5d69
Summary:
Since we've made SurfaceHandler internal, there's no need to maintain a separate interface between it and the actual Binding implementation class.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D72558674
fbshipit-source-id: d7ac15b0e608c3aa7d05e46f1078cef1e154f846
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50481
It's here! kinda...this only works internally right now, so no OSS usage which is explicitly gated to be off. We can't really avoid exposing the types so here we are.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D72428425
fbshipit-source-id: 9642e5db46f9bd34ff505b0e37987da52857b6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50303
This feature is being tested internally right now. We cannot really avoid exposing the type but we are going to make this no-op for now in OSS until we are confident we can roll it out fully
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D71919847
fbshipit-source-id: b1730b8af5180c4513ce1f0d58b3a6526fffed84
Summary:
I was helping a team with some keyboard link accessibility and they had this strange bug where a link was not keyboard accessible despite having `accessible={true}`. Something that fixed it for them was adding an `accessibilityLabel`, which makes no sense.
Turns out there is a bug when the link encompasses the entirety of the `Text` component. We have a special case for handling links of this manner, and right now we are not setting the `frame` property which is responsible for outlining the element when it takes focus.
This property is not one defined by UIKit, rather it is defined in RCTAccessibilityElement. We use it to derive the accessibilityFrame which has to be in screen coordinates. If you do not set the frame property then it is supposed to use the bounds of the container. This does not work properly, seemingly bc the name "frame" gets mangled internally in UIKit leading to UB. I changed the name the "something" and it works.
To remedy this lets just change the name
Changelog: [iOS] [Fixed]
Reviewed By: javache
Differential Revision: D72338838
fbshipit-source-id: da91d0c28baeb6765d4d604f3e47c91952167f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50516
This diff migrates the following file to Kotlin - DevSupportManagerFactory
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Android] [Changed] - Migrate to Kotlin - DevSupportManagerFactory - We couldn't find any implementation of this class in OSS. Some Kotlin implementers might have to change the method signatures. However this interface is not supposed to be extended in OSS.
Reviewed By: javache
Differential Revision: D72556310
fbshipit-source-id: 35d1ed3c332296d3be5244fdab92a890d7ea3c40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50517
This diff migrates the following file to Kotlin - ReactInstanceDevHelper
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Android] [Changed] - Migrate to Kotlin - ReactInstanceDevHelper. Some users implementing this class in Kotlin could have breakages. As this is a devtools/frameworks API we're not marking this as breaking.
Reviewed By: javache
Differential Revision: D72555226
fbshipit-source-id: e7e5523c56de8697def0a509c03e9fe89c6d5839
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50514
When building React Native for mac catalyst on intel architecture, we are observing a build failure in RCTInstance.
See issue: https://github.com/facebook/react-native/issues/50388
Apparently, the compiler don't understand that `errorData[@"isFatal"]` is a BOOL, so we are helping it by extracting the `boolValue`.
## Changelog:
[iOS][Fixed] - Avoid build failure on Catalyst (x86_64)
Reviewed By: cortinico
Differential Revision: D72558024
fbshipit-source-id: 152d89b02ae250a8ae54fe2df658c018d5f63f45
Summary:
Changelog: [internal]
This is stable after the last couple of fixes, so we can enable it by default. Enabling this just improves the accuracy of `IntersectionObserver` and the Event Timing API, and we still haven't shipped those to stable.
Reviewed By: GijsWeterings
Differential Revision: D72561256
fbshipit-source-id: 4b505f1df9c7c495d316e6fbf1498af94aaca959
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made NetworkingModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979590
fbshipit-source-id: 0ddf764f4707d2ee76ab99bc1a09a4e2a7e6b794
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50347
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979581
fbshipit-source-id: 4ed264ff43794b6aafc2a0ee419a660a6b5b0440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50366
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made BlobModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979598
fbshipit-source-id: bbef5548d05e0b77ea03cf72f41a384fe7294d59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50364
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979588
fbshipit-source-id: f5ec8bced87ea0c6c1c193be51ebc78396388d0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50370
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TurboModuleManager.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979605
fbshipit-source-id: b8da8f1ad12f5f6d63e7bd876d7c4912d69a4c4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50358
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979595
fbshipit-source-id: 19bfcea537b7b62536eafa8e1d0b3f8b50666e22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50357
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TurboModuleInteropUtils.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979599
fbshipit-source-id: ffd7006f28db4daf8cd47ce1cd8ff6e3192c0ad1
Summary:
Per discussion in D71979599
Changelog: [General][Fixed] Throw ParsingException when ReactModule doesn't conform to TurboModule invariants
Reviewed By: cortinico
Differential Revision: D72383857
fbshipit-source-id: 2d0282b136312d414234246584d2ae60858955b6
Nicola Corti
Chang Hua
Pieter De Baets
riteshshukla04
Zeya Peng
Dawid Małecki
Andrew Datsenko
Ruslan Lesiutin
Peter Abbondanzo
Jakub Piasecki
Gijs Weterings
Fabrizio Cucci
Rubén Norte
Riccardo Cipolleschi
Mateo Guzmán
Joe Vilches