Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38008
Introduce a legacy module (+ example) in RNTester.
In the future, SampleLegacyModule will be used to:
- Showcase the TurboModule interop layer in RNTester, once Bridgeless mode is ready
- E2E Test the TurboModule interop layer.
The TurboModule interop layer is just an extension to the TurboModule system that allows the system to create legacy modules. Unlike regular TurboModules, these legacy modules don't need codegen for JavaScript -> native method dispatch.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D46874160
fbshipit-source-id: f9810d0bdb3bd0c0a74099fcb6f74ca547977a53
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37599
changelog: [internal]
Moving CoreFeatures class to `utils` module from `core` module. There are other modules besides `core` that need to use CoreFeatures and moving it to `utils` will prevent circular dependency.
Reviewed By: javache, rshest
Differential Revision: D46218604
fbshipit-source-id: 6030f00ad37f55f0c95f4eafa61fb22808b880a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37889
Changelog: [Internal] - Add plumbing/boilerplate for an iOS implementation of the gotpointercapture and lostpointercapture events
Lets try this again: The key difference between this and D44977499 (which I previously reverted) is that in propsConversions & primitives I've ommited the "capture" versions of those methods as it was causing issues. Since we're not doing any runtime checks of those raw props it isn't particularlly necessary (at least not yet) and if we ever want to we can address that when it comes up.
The original diff description follows:
This diff simply adds the boilerplate necessary to hook up the gotpointercapture and lostpointercapture events to the fabric iOS touch handler. This diff does not contain any actual implementation of their behavior as that will occur in future diffs.
Reviewed By: adanoff
Differential Revision: D46709127
fbshipit-source-id: 339dc99e14f2e72d9116bbe84edc67cb5bfaa73b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37932
`static_cast<Derived &>(*sharedBase)` is preferred over `*std::static_pointer_cast<Derived>(sharedBase)`, since we don't need to copy the underlying shared_ptr to do so. The same applies for `std::const_pointer_cast`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D46766558
fbshipit-source-id: 5d0b660107b2a60340952e2b5ec2792e3ed1832a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37659
changelog: [internal]
To better align with how BUCK is setup internally, let's make React utils its own pod.
Reviewed By: dmytrorykun
Differential Revision: D46358021
fbshipit-source-id: c2a48a18e9839a508a87d54685115883975f3979
Summary:
See: https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps
As of iOS 16.4 and above, JSContexts are no longer inspectable by default. Without this, we cannot attach Safari Web Inspector to the JSContext, AKA, we can no longer direct debug. This is a simple change to re-enable that. I decided to extend the `availability` check to macOS and tvOS as I'm certain both out of tree platform forks will want this fix as well.
## Changelog:
[IOS] [FIXED] - Re-enable direct debugging with JSC on iOS 16.4+
Pull Request resolved: https://github.com/facebook/react-native/pull/37874
Test Plan: I launched RNTester in an iOS 15, and iOS 16.4 simulator. I then verified that we can attach Safari Web inspector to both simulators' JSContexts.
Reviewed By: cortinico
Differential Revision: D46719890
Pulled By: huntie
fbshipit-source-id: 7fa5ae244577b7dbf3c9c16e65ad530cfc3e9cbd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37893
Changelog: [Internal]
i just noticed we can push more C++ code down into RCTInstance, so let's do that! will make everything easier to test as well
Reviewed By: cipolleschi, RSNara
Differential Revision: D46672345
fbshipit-source-id: fcb878698ebc9a19714ba6ff94a5760efc830958
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37895
Changelog: [Internal]
i'm adding these helpers so we can test that our objects aren't leaking memory
Reviewed By: cipolleschi
Differential Revision: D46625916
fbshipit-source-id: d811336ae3b0ac420b81832c258d5573c20a5bc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37882
After some progressive changes, we can finally remove the PRODUCTION flag from the codebase.
## Changelog:
[iOS][Removed] - Remove PRODUCTION flag from iOS build logic
Reviewed By: cortinico, dmytrorykun
Differential Revision: D46726208
fbshipit-source-id: 407268779be8de32c5a6c15ba220a60b7cb9ced7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37861
Changelog: [Internal] - Back out of "Add plumbing/boilerplate for an iOS implementation of the `gotpointercapture` and `lostpointercapture` events"
Original commit changeset: c9da5691d399
Original Phabricator Diff: D44977499
This diff appears to be causing issues as reported on T155721480 related to the file `RawPropsKeyMap.cpp` which, while I haven't figured out exactly why this is occurring, confirmed that this diff is causing the issue. In order to buy myself some more time as I diagnose this I'm backing the changes out in this diff.
Reviewed By: adanoff
Differential Revision: D46691035
fbshipit-source-id: 383b46732a3fad24a50e18ab948c96ce9bfe429e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37858
Changelog: [Internal]
in this diff, i add a test that runs `start` validates that the lifecycle `hostDidStart:` is called as a result.
notably, i created a custom shim for `RCTInstance` to completely stub out its behavior.
Reviewed By: cipolleschi
Differential Revision: D46508066
fbshipit-source-id: e815aee64d06b160f2cbdc52720a8e698d11c680
Summary:
React-Native-Windows had to override this file because we treat certain warning as errors. This fix adds in the "f suffix" to remove the unspecified float error.
## Changelog:
[GENERAL] [FIXED] - Specify float value in ParagraphLayoutManager
Pull Request resolved: https://github.com/facebook/react-native/pull/37660
Test Plan: Tested with RNW tests
Reviewed By: NickGerleman
Differential Revision: D46560099
Pulled By: javache
fbshipit-source-id: de593cbe60677533f5194ab8fd7e650607b5829e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37602
Changelog: [Internal] - Add plumbing/boilerplate for an iOS implementation of the `gotpointercapture` and `lostpointercapture` events
This diff simply adds the boilerplate necessary to hook up the `gotpointercapture` and `lostpointercapture` events to the fabric iOS touch handler. This diff does not contain any actual implementation of their behavior as that will occur in future diffs.
Reviewed By: yungsters
Differential Revision: D44977499
fbshipit-source-id: c9da5691d399f612f1980c7692c4ca62877901a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37810
Changelog: [Internal]
in this change, i introduce a helper file for swizzling selectors that can be used for building custom shims and fakes. i tried putting this in the cxx target, but i struggled a lot with managing the dependencies and understanding the extra behavior that was happening from being in a `rn_xplat_cxx_library`. this file is also not obj-c++, so i feel like we should decouple if possible.
it does seem like this is a new practice i'm introducing, so let me know if there's something that i'm missing.
Reviewed By: cipolleschi
Differential Revision: D46507803
fbshipit-source-id: 9be63d992b9838e9a98ee0c1c6d684fc59c3fc80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37811
Changelog: [Internal]
i am looking to add ios unit tests to venice and this is the first unit test suite that will test native ios code in the new architecture afaik, so i wanted to open this up to discussion.
currently, all `XCTest` in `react-native-github` are coupled with the `RNTester` target. my main qualm with this is i am concerned that it won't scale well. currently we have only ~30ish tests but ultimately if we want a proper testing suite, surely this count will be in the hundreds and that won't be able to reasonably live in a single test target.
however, the trade is that this test will not show up in RNTester. i have added a unit test to RNTester before in D31949237, however the experience was extremely painful as i had to manually update the `project.pbxproj` to include my file, and i had to manually determine what hex value was the next one (for whatever reason, this doesn't increment at the endian...).
i am wondering if we can treat the current unit testing experience in RNTester as pretty much maintenance mode and start thinking of a improved version starting with something more modular like this.
Reviewed By: cipolleschi
Differential Revision: D46467229
fbshipit-source-id: 09de9cf8bc5f8b9c86abcaf7750a6f63686d8d1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37812
Changelog: [Internal]
I would like to add iOS unit tests, but this testing directory has a subdirectory based on features and not platform, which makes the organization challenging, so i'm moving it to a more aptly named directory.
Reviewed By: javache
Differential Revision: D46467041
fbshipit-source-id: f2ba714dc79ecb509b86b4708320c68235354240
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37783
We're not checking the number of arguments received before accessing the `arguments` array in JSI methods in `UIManagerBinding`, which could cause access to garbage values. This fixes that by adding a check in all methods to ensure the number of arguments received is at least the arity of the function.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D46564580
fbshipit-source-id: 7012e0d6fb12c5024e4d6a4c0fb7a8c00263ccac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37754
This adds a new method in Fabric to get the scroll position for an element, and uses it to implement the following methods as defined in as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607 :
* `scrollTop`: indicates the number of pixels (in device independent pixels) from the content that have moved in the vertical axis in the scroll container.
* `scrollLeft`: indicates the number of pixels (in device independent pixels) from the content that have moved in the horizontal axis in the scroll container.
These API can provide decimal values.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D44757811
fbshipit-source-id: e1b58db8d9f61e823b62d54620a9a0deaae1566b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37723
React-hermes pod sets the `GCC_PREPROCESSOR_DEFINITIONS` flag for Debug config only, by leveraging the `PRODUCTION=1` flag.
This flag is not standard for iOS, therefore we want to remove it from the condebase to simplify the build APIs.
This change moves the setting of the `GCC_PREPROCESSOR_DEFINITIONS` flag from the podspec xcconfig (which can't distinguish between Debug and Release configurations) to a post install hook (which can).
## Changelog:
[internal] - Remove dependency on PRODUCTION=1 from React-hermes podspec
Reviewed By: dmytrorykun
Differential Revision: D46316662
fbshipit-source-id: b5764e1bf60f2e71ff171556bccbc00c0c0c62aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37553
## Context
I added some getters in EventTarget/EventEmitter to access the React instance handle for a given shadow node/shadow node family in https://github.com/facebook/react-native/commit/43864a1d6025bfc4483dded115d51f7613018199 (D44022477), so I could implement DOM traversal methods easily.
I wanted to reuse that method to implement `MutationObserver` and `IntersectionObserver`, but unfortunately `EventEmitter`/`EventTarget` only allow access to the instance handle as long as the shadow node is mounted. That makes sense for events, but not for this use case, as with `MutationObserver` we intentionally want to have access to unmounted nodes when creating the list of `addedNodes` and `removedNodes` for the `MutationRecord` (depending on when exactly we generate this list, either `addedNodes` or `removedNodes` wouldn't be mounted).
## Changes
This reverts my original change and adds a new field in `ShadowNodeFamily` to provide access to the `InstanceHandle` at any point (even if the node isn't mounted).
This provides the same guarantees as the original method, keeping weak references to the handles to avoid memory leaks.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D46149084
fbshipit-source-id: f76abae50134a5d55a98cab42eebeb62084024f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37772
Changelog: [internal]
`ShadowNodeFragment` is used in multiple places as a general definition for the fragment, but it lacks information that's going to be constructed in the fragment itself in the future (like `eventEmitter` in D46149084).
This migrates some of the usages of this fragment to the `ShadowNodeFamily` directly (as they already have access to it).
Reviewed By: javache, sammy-SC
Differential Revision: D46190382
fbshipit-source-id: 3a879861106594d66a2580410d4d83523c288314
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37716
We call `surfaceHandler.stop` both from `SurfaceHandlerBinding` as well as `Binding`. Since we don't check asserts in production, the second one should generally be a no-op, but may be causing a crash due to incorrectly de-referencing a unique_ptr.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D46441620
fbshipit-source-id: e93b9722fd717947ebf772f545f692c2e31f816e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37687
We end up creating a stub RuntimeExecutor wherever we configure this, and might as well pass in the runtime directly, to match the other binding installer signatures.
Changelog: [iOS][Deprecated] Use -[RCTTurboModuleManager installJSBindings:] instead of -[RCTTurboModuleManager installJSBindingWithRuntimeExecutor:]
Reviewed By: philIip
Differential Revision: D46390501
fbshipit-source-id: df7644ccbd04462dbbe752c60e5d5961ab50dff5
Summary:
Changelog: [Internal]
it appears that having some access to jsi in userland will be necessary for framework developers, so i'm moving this API to the public header.
bypass-github-export-checks
Reviewed By: mdvacca
Differential Revision: D46385184
fbshipit-source-id: 7261c0a8ba8c8c9302f65d440a3a3fb2782c0666
Summary:
Changelog: [Internal]
now that we've wrapped up the first iteration of the venice stable apis, let's clean up old comments and reorganize things to prepare this header for documentation.
bypass-github-export-checks
Reviewed By: mdvacca
Differential Revision: D46334662
fbshipit-source-id: 68d6d2e41d7f7c5b1c69f3bb72482c418e771f72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37703
Changelog: [Internal]
i did too good of a job refactoring that these functions don't abstract any arguments away anymore, so let's just delete it
Reviewed By: javache
Differential Revision: D46303713
fbshipit-source-id: 7e0508a7296ebc3d5c62cf0824071bd2ef041193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37702
Changelog: [Internal]
the context container is a DI object in our internal infra. the delegate method `createContextContainer` is used to pass down internal implementations that may be used in our infra, notably the `ReactNativeConfig`. this API used to be required for the app delegate to implement.
in this change, i introduce a protocol, `RCTContextContainerHandling`, where we shift the burden of creating the DI container to our internal infra where userland can now optionally add dependencies to this.
this also removes more C++ boilerplate for the bridgeless setup.
Reviewed By: sammy-SC
Differential Revision: D46245433
fbshipit-source-id: 552a9ab0b6a178bab592743863694ff886b152f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37604
Changelog: [Internal]
this isn't needed anymore, so we can delete it and remove it from our public api
Reviewed By: javache
Differential Revision: D46215054
fbshipit-source-id: 97bc7821aeea47223a4b10684efe750ff1899fa2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37605
Changelog: [Internal]
in this stack, i remove the `bindingsInstallFunc` argument from `RCTHost`'s public API.
the bindingsInstallFunc is a lambda that provides a runtime parameter, which the consumer can "install bindings" to. we have our specific use case for this internally, but there's no need to expose this.
in this change, i introduce a delegate callback path that notifies an internal delegate that the react runtime has been created.
Reviewed By: javache
Differential Revision: D46215051
fbshipit-source-id: 732d6949064b0948b5cf883dc3c0ab494c2ecd94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37309
### Stack
ARIA roles in React Native are implemented on top of accessibilityRole. This is lossy because there are many more ARIA roles than accessibilityRole. This is especially true for RN on desktop where accessibilityRole was designed around accessibility APIs only available on mobile.
This series of changes aims to change this implementation to instead pass the ARIA role to native, alongside any existing accessibilityRole. This gives the platform more control in exactly how to map an ARIA role to native behavior.
As an example, this would allow mapping any ARIA role to AutomationControlType on Windows without needing to fork to add new options to accessibilityRole.
It also allows greater implementation flexibility for other platforms down the line, but for now, iOS and Android behave the same as before (though with their implementation living in native).
### Diff
This enables the `role` prop in iOS. ARIA role strings become convertible to `UIAccessibilityTrait`, which is the sink of most of the roles. We keep a list of traits derived from `role` vs `accessibilityRole` on the view, then inval and apply the result any time the prop for either is set.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45432530
fbshipit-source-id: ced5be06e319c0b967d7511293e14e05147e5759
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37657
changelog: [internal]
Make React-debug into its own pod to align BUCK and cocoapods.
This is needed to reland RuntimeScheduler in the old architecture on iOS.
Reviewed By: rickhanlonii
Differential Revision: D46357876
fbshipit-source-id: 035aaaee8b4b106f873b4b30c8cb424867be066a
Summary:
When reverting the runtimescheduler fix, we forgot to remove some lines from the React-Fabric dependencies. This broke pod install and we have a red ci since then.
bypass-github-export-checks
## Changelog:
[iOS][Fixed] - fix React-Fabric dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/37652
Test Plan: CircleCI is green
Reviewed By: cipolleschi
Differential Revision: D46349504
Pulled By: sammy-SC
fbshipit-source-id: 8fc1bca7838a913adba702033d06dd02b93c31f9
Summary:
As far as I'm aware, there's no way to know/guarantee whether a JavaScript callback can throw an exception or not.
So, all UIManager methods that synchronously invoke JavaScript callbacks cannot use noexcept.
If they do use noexcept, and the JavaScript callback (i.e: product code) throws an exception, the app will crash.
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: javache
Differential Revision: D46122985
fbshipit-source-id: 2f4356c7dbab1b3a5e0549f58e73f6de1b626ce9
Ramanpreet Nara
Lulu Wu
Samuel Susla
Vincent Riemer
Pieter De Baets
Andrew Wang
Alex Hunt
Riccardo Cipolleschi
Saad Najmi
Phillip Pan
Riccardo Cipolleschi
TatianaKapos
Rubén Norte
Fábio Henriques
Nick Gerleman