Do not virtualize items adjacent to the last focused item #2

…tarball. Summary: I'm backporting PR facebook#33945 to main as it was merged on the release branch to unblock 0.69. Those changes are necessary as Hermes was not being donwloaded at all during `pod install` on .69 and the app was failing to build with a missing `hermes/hermes.h` import. Changelog: [iOS] [Fixed] - Fix Hermes not being properly downloaded during pod install Reviewed By: hramos Differential Revision: D36810787 fbshipit-source-id: f898e61b6536dfcfc81feeff740703fbd697b000

Summary: Creates a base TurboModule for Catalyst. Reviewed By: ann-ss Differential Revision: D36707915 fbshipit-source-id: 9a246f238efdcdde45e0332f7b868478deadf50e

Differential Revision: D36707915 (facebook@528414c) Original commit changeset: 9a246f238efd Original Phabricator Diff: D36707915 (facebook@528414c) fbshipit-source-id: a581b745abd781a97d5ffde303db69ba3e23c51c

Summary: Without getting into the weeds too much, RawPropParser "requires" that props be accessed in the same order every time a Props struct is parsed in order to most optimally fetch the values in a linear-ish fashion, basically ensuring that each rawProps.at() call is an O(1) operation, and overall getting all props for a particular component is O(n) in the number of props for a given struct. If props are called out of order, this breaks and worst-case we can end up with an O(n^2) operation. Unfortunately, calling .at(x) twice with the same prop name triggers the deoptimized behavior. So as much as possible, always fetch exactly once and in the same order every time. In this case, we move initialization of two fields into the constructor body so that we can call .at() a single time instead of twice. In the debug props of ViewProps I'm also reordering the fields to fetch them in the same order the constructor fetches them in, which will make this (debug-only) method slightly faster. What's the impact of this? If you dig into the Tracery samples, the average/median RawPropsParser::at takes 1us or less. However, in /every single/ call to createNode for View components, there is at least one RawPropsParser::at call that takes 250+us. This was a huge red flag when analyzing traces, after which it was trivial (for View) to find the offending out-of-order calls. Since this is happening for every View and every type of component that derives from View, that's 1ms lost per every 4 View-type ShadowNodes created by ReactJS. After just 100 views created, that's 25ms. Etc. There are other out-of-order calls lurking in the codebase that can be addressed separately. Impact scales with the size of the screen, the number of Views they render, etc. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D36889794 fbshipit-source-id: 91e0a7ca39ed10778e60a0f0339a4b4dc8b14436

Summary: See also D36889794. This is a very similar idea, except the core problem is that BaseTextProps is accessing the same props as ViewProps; and for ParagraphProps parsing, it first defers to ViewProps' parser and then BaseTextProps. RawPropsParser is optimized to access the same props in the same order, *exactly once*, so if we access a prop out-of-order, or for a second time, that access and the next access are deoptimized. Paragraph/Text, in particular, were quite bad because we did this several times, and each out-of-order access requires scanning /all/ props. This fixes the issue, at least partially, by (1) pulling all the duplicate accesses to the beginning of BaseTextProps, and (2) accessing them all in the same order as ViewProps, relatively (some props are skipped, but that matters less). Practically what this means is that now, all of Props' accesses have a cost of O(1) for lookup, or a total of O(n) for all of them; each access is at the n+1 position in the internal RawPropsParser array, so each access is cheap. BaseTextProps' duplicate accesses, even though there are only 4 of them: (1) the first one scans the entire array until we reach the prop in question; (2) the next accesses require scans, but not whole-array scans, since they're in order. (3) The BaseTextProps accesses /after/ the duplicate accesses are all O(1). tl;dr is that before we had something like O(n*6) cost for BaseTextProps parsing and now it is O(n*2). Similar to my summary in the last diff: we may want to revisit the RawPropsParser API... but I want to tread gently there, and this gets us a large improvement without major, risky changes. Empirically, based on a couple of systraces, average time for a single UIManager::createNode called from JS thread, before this stack: 17us. After: 667ns (3% as long). On average, for every 60 createNode calls, we will save 1ms on the UI thread. The savings will be greater for certain screens that use many Views or Text nodes, and lesser for screens that use fewer of these components. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D36890072 fbshipit-source-id: 5d24b986c391d7bb158ed2f43d130a71960837d1

Summary: In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults. Changelog: [Internal] Reviewed By: genkikondo Differential Revision: D36885646 fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3

Summary: D36612758 (facebook@40f4c66) attempted to remove the check that the animated node was native when fetching animated prop values for render, in order to fix an issue that arises when a node is converted to native before the initial call to render to mount the component, where the initial value is not applied. However, this causes issues for cases where we call setValue on an animated node soon after render, such as on componentDidUpdate. setValue first updates the animated node value on JS side, then calls the native API setAnimatedNodeValue. The problem is that the next render will then use these updated values in the style props (because we removed the check for native in D36612758 (facebook@40f4c66)), resulting in a diff in props. Since Animated and Fabric aren't synchronized, there's a race condition between SurfaceMountingManager.updateProps and NativeAnimatedNodesManager.runUpdates To allow proper rendering of initial values of native animated nodes, and mitigate the issue when calling setValue on an animated node soon after render, during initial render we use the initial values of both native and non-native driven nodes, and on subsequent renders we only use the initial values of non-native driven nodes. An alternative considered was to add internal state to the nodes themselves (AnimatedProps, AnimatedStyle), but keeping it in sync with the component state is not easy/clean as AnimatedProps can be recreated and reattached at any time for a mounted component. Changelog: [Internal][Fixed] - Only use value of natively driven nodes on initial render Reviewed By: JoshuaGross Differential Revision: D36902220 fbshipit-source-id: c20f711aa97d18a2ed549b5f90c6296bf19bb327

Summary: The current implementation of `throwJSError` places it in jsi.cpp, but does not actually export it. This means that when JSI is being provided by a dynamic library, `detail::throwJSError` will not be available. To fix this, move the definition of `throwJSError` into jsi-inl.h, similar to all of the other functions in the `detail` namespace. This uses a roundabout implementation of `throwJSError` in order to avoid directly using `throw`, which would fail to compile when exceptions are turned off. Changelog: [Internal] Reviewed By: jpporto Differential Revision: D36873154 fbshipit-source-id: bbea48e0d4d5fd65d67a029ba12e183128b96322

…as been deallocated Summary: Changelog: [iOS][Fixed][Internal] - Protect handlers in RCTNetworking with mutex even if RCTNetworking has been deallocated # The Logview We get this error in LogView: `Unhandled JS Exception: Error: Exception in HostFunction: mutex lock failed: Invalid argument`, which is an C++ std::error. "This typically happens when .lock() is called on a mutex that is not yet constructed, or has already been destructed." # Hypothesis of issue The LogView says the line that throws this softerror is [RCTNetworking.ios.js](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.ios.js#L87). Inside RCTNetworking, there's only [one mutex and only one line where is is being used](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.mm#L207-L215 ), to protect the _handlers array. My guess is that RCTNetworking was deallocated, which made `_handlersLock` nil, so it resulted in this error when we tried to lock it. # This diff * Add `std::lock_guard<std::mutex> lock(_handlersLock);` to `invalidate()` * Move `_handlersLock` logic to its own method instead of using a lambda. If `self` is being deallocated, I would guess that this method (`[self prioritizedHandlers]`) would return nil. Referencing this for correct ways to use lock_guard with mutex: https://devblogs.microsoft.com/oldnewthing/20210709-00/?p=105425 Reviewed By: fkgozali Differential Revision: D36886233 fbshipit-source-id: 60246f4d9bbc1d834497e4fb8a61d9c0e9623510

Summary: This diff fixes the rendering of transparent borders in RN Android views The fix clips the view ONLY when there is a border color that's non transparent This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android Reviewed By: JoshuaGross Differential Revision: D36890856 fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced

Summary: Pull Request resolved: facebook#33937 This moves the build of RNTester from Unix Make to CMake This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls. In order to make this possible I had to: * Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build. * Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make * Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make Changelog: [Internal] [Changed] - Build RN Tester with CMake Reviewed By: cipolleschi Differential Revision: D36760309 fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70

Summary: Problem - Error when trying to publish to Apple Store in debug scheme Error thread - facebook#31507 ## Changelog  [General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's Pull Request resolved: facebook#33153 Reviewed By: lunaleaps Differential Revision: D34392529 Pulled By: sshic fbshipit-source-id: 78387999f94e0db71f5d3dafff51e58d7d0c1847

Summary: When tapping on ReactRootView and having Fabric enabled, the touch logic mistakenly dispatch the event to JS via the legacy renderer. This is because the destination was computed based on reactTag (odd = legacy, even = Fabric), but root view tag happens to be always odd (always ends with 1). This change uses the right destination based on what the Event itself tells us, instead of deriving from the reactTag. Changelog: [Android][Fixed] Fix Fabric touch event dispatching for root views Reviewed By: JoshuaGross, sshic Differential Revision: D36917300 fbshipit-source-id: 838b4e135d7df07c37040bd47d71370ff10df067

Summary: This sync includes the following changes: - **[dd4950c90](facebook/react@dd4950c90 )**: [Flight] Implement useId hook ([facebook#24172](facebook/react#24172)) //<Josh Story>// - **[26a5b3c7f](facebook/react@26a5b3c7f )**: Explicitly set `highWaterMark` to 0 for `ReadableStream` ([facebook#24641](facebook/react#24641)) //<Josh Larson>// - **[aec575914](facebook/react@aec575914 )**: [Fizz] Send errors down to client ([facebook#24551](facebook/react#24551)) //<Josh Story>// - **[a2766387e](facebook/react@a2766387e )**: [Fizz] Improve text separator byte efficiency ([facebook#24630](facebook/react#24630)) //<Josh Story>// - **[f7860538a](facebook/react@f7860538a )**: Fix typo in useSyncExternalStore main entry point error ([facebook#24631](facebook/react#24631)) //<François Chalifour>// - **[1bed20731](facebook/react@1bed20731 )**: Add a module map option to the Webpack Flight Client ([facebook#24629](facebook/react#24629)) //<Sebastian Markbåge>// - **[b2763d3ea](facebook/react@b2763d3ea )**: Move hydration code out of normal Suspense path ([facebook#24532](facebook/react#24532)) //<Andrew Clark>// - **[357a61324](facebook/react@357a61324 )**: [DevTools][Transition Tracing] Added support for Suspense Boundaries ([facebook#23365](facebook/react#23365)) //<Luna Ruan>// - **[2c8a1452b](facebook/react@2c8a1452b )**: Fix ignored setState in Safari when iframe is touched ([facebook#24459](facebook/react#24459)) //<dan>// - **[62662633d](facebook/react@62662633d )**: Remove enableFlipOffscreenUnhideOrder ([facebook#24545](facebook/react#24545)) //<Ricky>// - **[34da5aa69](facebook/react@34da5aa69 )**: Only treat updates to lazy as a new mount in legacy mode ([facebook#24530](facebook/react#24530)) //<Ricky>// - **[46a6d77e3](facebook/react@46a6d77e3 )**: Unify JSResourceReference Interfaces ([facebook#24507](facebook/react#24507)) //<Timothy Yung>// - **[6cbf0f7fa](facebook/react@6cbf0f7fa )**: Fork ReactSymbols ([facebook#24484](facebook/react#24484)) //<Ricky>// - **[a10a9a6b5](facebook/react@a10a9a6b5 )**: Add test for hiding children after layout destroy ([facebook#24483](facebook/react#24483)) //<Ricky>// - **[b4eb0ad71](facebook/react@b4eb0ad71 )**: Do not replay erroring beginWork with invokeGuardedCallback when suspended or previously errored ([facebook#24480](facebook/react#24480)) //<Josh Story>// - **[99eef9e2d](facebook/react@99eef9e2d )**: Hide children of Offscreen after destroy effects ([facebook#24446](facebook/react#24446)) //<Ricky>// - **[ce1386028](facebook/react@ce1386028 )**: Remove enablePersistentOffscreenHostContainer flag ([facebook#24460](facebook/react#24460)) //<Andrew Clark>// - **[72b7462fe](facebook/react@72b7462fe )**: Bump local package.json versions for 18.1 release ([facebook#24447](facebook/react#24447)) //<Andrew Clark>// - **[22edb9f77](facebook/react@22edb9f77 )**: React `version` field should match package.json ([facebook#24445](facebook/react#24445)) //<Andrew Clark>// - **[6bf3deef5](facebook/react@6bf3deef5 )**: Upgrade react-shallow-renderer to support react 18 ([facebook#24442](facebook/react#24442)) //<Michael サイトー中村 Bashurov>// Changelog: [General][Changed] - React Native sync for revisions bd4784c...d300ceb jest_e2e[run_all_tests] Reviewed By: cortinico, kacieb Differential Revision: D36874368 fbshipit-source-id: c0ee015f4ef2fa56e57f7a1f6bc37dd05c949877

Summary: This PR adds `READ_VOICEMAIL` and `WRITE_VOICEMAIL` permissions to the PermissionsAndroid library. Resolves facebook#33922. https://developer.android.com/reference/android/Manifest.permission#READ_VOICEMAIL https://developer.android.com/reference/android/Manifest.permission#WRITE_VOICEMAIL ## Changelog  [Android] [Added] - Add READ_VOICEMAIL and WRITE_VOICEMAIL permissions to PermisionsAndroid library. Pull Request resolved: facebook#33965 Test Plan: ``` PermissionsAndroid.READ_VOICEMAIL === 'com.android.voicemail.permission.READ_VOICEMAIL' PermissionsAndroid.WRITE_VOICEMAIL === 'com.android.voicemail.permission.WRITE_VOICEMAIL' ``` Reviewed By: kacieb Differential Revision: D36933524 Pulled By: cortinico fbshipit-source-id: f5283d526aeb68c2724654e22ae16c8c3f69f740

…face Summary: This diff address an edge case when the pending events are enqueued when the surface is stopped. In this case we will reset map that holds view state to null, which will cause NPE. Changelog: [Android][Fixed] - Fix edge case when we enqueue a pending event to views on stopped surface Reviewed By: javache, gorodscy Differential Revision: D36912786 fbshipit-source-id: 3ae5a4b08a0a6bf55538d69ac80a101c2c3d899a

Summary: Seems like an obvious typo! Whoops! Not causing any known issues, but... this should be fixed. Changelog: [Internal] Reviewed By: genkikondo Differential Revision: D36940476 fbshipit-source-id: d534ca3763b1f91e41c56953bf3d665e86db9e2b

Differential Revision: D36926167 fbshipit-source-id: e5c262e269b3ccb2afe04b45398ec66fc5c48df2

Summary: facebook@3337add made some changes to method signature but the template wasn't updated. This adds the missing changes. ## Changelog [Internal] [Fixed] - Pass string by ref in TurboModule template Pull Request resolved: facebook#33970 Test Plan: Didn't test the template directly, but the change is trivial. Reviewed By: cortinico Differential Revision: D36964481 Pulled By: dmitryrykun fbshipit-source-id: 561e32f218baf398b8d4d8c77381a2642e22ef42

Summary: This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See facebook#33381. The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers. Tested in the YogaKitSample, and also in a react-native app. Changelog: [iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus X-link: facebook/yoga#1150 Reviewed By: dmitryrykun Differential Revision: D36966687 Pulled By: cortinico fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39

Summary: Changelog: [iOS][Internal] - Add dispatching of pointerover/pointerout events Reviewed By: lunaleaps Differential Revision: D36718156 fbshipit-source-id: c2fee2332ac52e617db938e321e3b38fd5c35ad3

…n Android. Summary: Changelog: [Android][Fix] - When `onEndReachedThreshold` is set to 0 `onEndReached` function on `VirtualizedList` properly fires once the user scrolls to the bottom of the list. Reviewed By: genkikondo Differential Revision: D36488189 fbshipit-source-id: b95f3291f2957273280696d8840c1e000d669380

Summary: D36902220 (facebook@a041951) changed Animated to only use value of natively driven nodes on initial render. However, there remained a case where we could end up with a race condition between Fabric prop update (via SurfaceMountingManager.updateProps) and Animated (via NativeAnimatedNodesManager.runUpdates), when an animation on a node that was created natively is triggered close to render (such as in componentDidUpdate). This happens as Animated and Fabric aren't synchronized, and at the platform level, they do not know each other's state. Say we have two items, where opacity is used to indicate whether the item is selected. On initial render, A's opacity is set to 1, and animated sets opacity to 1; B's opacity is set to 0, and animated sets opacity to 0. When B is selected (and causes A and B to rerender), A's opacity is now set to null, and animated sets opacity to 0; B's opacity is also now set to null, and animated sets opacity to 1. A's props have changed, and thus the default opacity value of 1 is applied via Fabric, but Animated also sets the opacity to 0 - either may end up being the value visible to the user due to the nondeterministic order of Fabric update props and Animated. This is what is causing T122469354. This diff addresses this edge case by using the initial prop values for native animated nodes, for subsequent renders, to ensure that values of native animated nodes do not impact rerenders. This diff also fixes a bug in OCAnimation where translateX/Y values of 0 in transition will result in render props containing translateX/Y instead of transform, resulting in potentially incorrect pressability bounds. Changelog: [Internal][Fixed] - Only use initial value of natively driven nodes on render Reviewed By: JoshuaGross, javache Differential Revision: D36958882 fbshipit-source-id: 10be2ad91b645fa4b8a4a12808e9299da33aaf7d

Summary: D36784563 (facebook@ec307e0) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop Changelog [Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop Reviewed By: makovkastar Differential Revision: D36994688 fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6

…book#33972) Summary: `OTHER_CFLAGS` doesn't seem to work when the file is imported from Objc++. This causes flipper to not be included. ## Changelog [iOS] [Fixed] - Use `GCC_PREPROCESSOR_DEFINITIONS` to set `FB_SONARKIT_ENABLED` Pull Request resolved: facebook#33972 Test Plan: Tested the change in an app. Used a breakpoint to see that flipper code is not executed before this change, and is after. Also made sure other `GCC_PREPROCESSOR_DEFINITIONS` set by cocoapods are still properly inherited. Reviewed By: cipolleschi Differential Revision: D37001624 Pulled By: dmitryrykun fbshipit-source-id: 920f3fe368a9fbe2cde9aa1e6d5b3b883c42119d

Summary: This diff adds an assertion to make sure the pending events are enqueued only when the event emitter is null. This is to avoid unexpected workflow when we queue events but we should just dispatch them. Changelog: [Android][Internal] - Make sure we only queue events when event emitter is null Reviewed By: javache Differential Revision: D36916482 fbshipit-source-id: fff305615b302ece26bc2482c826b74de4f70266

…r iOS 13+ (facebook#33553) Summary: Support to override Alert interface style to match your app. For example, You want to change the style on the alert. ## Changelog  [iOS] [Added] - Add userInterfaceStyle to Alert to override user interface style for iOS 13+ Pull Request resolved: facebook#33553 Test Plan: **`userInterfaceStyle: 'light'`:** <img width="320" src="https://user-images.githubusercontent.com/37284154/161358408-50dbf0a5-ae46-458e-a075-8595cce1b046.png" /> **`userInterfaceStyle: 'dark'`:** <img width="320" src="https://user-images.githubusercontent.com/37284154/161358326-bc54effb-1635-43df-97e0-522328713259.PNG" /> Reviewed By: philIip Differential Revision: D35371697 Pulled By: ryancat fbshipit-source-id: 597c1a97ca94571abada2b5fb97cb2adcb5337f5

Summary: This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`. Changelog: Internal Reviewed By: javache Differential Revision: D36989312 fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b

…ComponentView Summary: Changelog: [iOS][Fixed] - `_scrollViewComponentView` is set to `RCTPullToRefreshViewComponentView's` superview: ``` _scrollViewComponentView = [RCTScrollViewComponentView findScrollViewComponentViewForView:self]; ``` It should be safe to make it weak. Reviewed By: javache Differential Revision: D36998626 fbshipit-source-id: 2130b743d181e15986cb68636d60507a986968e1

Summary: I'm extending ktfmt setup to run on kotlin script files as well. Changelog: [Internal] [Changed] - Reformat .kts files with ktfmt skip-linter-coverage-verification Reviewed By: zertosh Differential Revision: D36967010 fbshipit-source-id: a83f3facbb5f30b935b69fc70a5588e4da5996b2

Summary: Allow an arbitrary path to hermes-runtime-darwin-vX.Y.Z.tgz to be specified. This can be used in CI or in local e2e tests to test with Hermes enabled without having a matching GitHub release. Usage: ``` HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes- runtime-darwin-v0.69.0.tar.gz \ USE_HERMES=1 \ pod install ``` Changelog: [Internal] Reviewed By: cortinico Differential Revision: D36985477 fbshipit-source-id: 853829c89e6f0ac3f63781c7f290cf3994b8e0cd

…33974) Summary: Pull Request resolved: facebook#33974 Enable Hermes in iOS Template tests and use pre-built Hermes binaries from Circle CI. Changelog: [Internal] Reviewed By: cortinico, cipolleschi Differential Revision: D36989241 fbshipit-source-id: a240713d0bd0383fa218f8fc031e81467ebeb376

… three months Summary: Remove overflow inset optimization flags as they've been rolled out 100% to public. Changelog: [Android][Internal] - Clean up feature flags for overflowInset Reviewed By: nlutsenko Differential Revision: D36990986 fbshipit-source-id: 77da78a2927034893f25937c2ccbd0b53e08031d

Summary: Pull Request resolved: facebook#33885 When building Hermes for React Native, point to the React Native JSI location to ensure both React Native and Hermes use the exact same version of JSI. Changelog: [iOS] [Changed] - When Hermes is enabled, it will use the same copy of JSI as React Native Reviewed By: cortinico, cipolleschi Differential Revision: D36567471 fbshipit-source-id: 97d954ef34007bd31f008fab451512194060d670

…cus to true Summary: [A recent fix](facebook#33076) to Android to set focusable to true when accessible is true, and this caused several components not to work correctly. This JS change essentially reverts the default back to Text not being focusable unless it is explicitly set. Android's "auto" behavior is better than setting `accessible=true`, and it's also the behavior React Native has had since accessibility on Android was implemented. # Wall of Text Explanation Explanation From Brett's comment [here](https://www.internalfb.com/diff/D35908559?dst_version_fbid=700876567897063&transaction_fbid=477905564133412) blavalla Generally speaking, "accessible" in react native maps to "focusable" in Android views, and the default value for "focusabe" for a TextView (and actually all views) is "auto" not "false". The difference here is that "false" is telling the system to explicitly disallow focus on this element, where as "auto" is telling the system that it's up to whatever service is trying to focus to determine if it should or not. In the case of text, Talkback generally does default to focusing on Text when it's set to "auto", though it also does try to combine this text together with other not-explicitly focusable siblings and roll the focus up to some common ancestor element. In the case of TetraButton here, I would expect the default behavior would be that the text is "auto" focusable, so Talkback would combine the text here with the parent <TetraPressable> (which is explicitly focusable via accessible="true"). ... [This diff](facebook#33076) was to fix the issue with "disabled" not properly announcing on text views, which was commonly occuring due to the description-combining feature described above. Basically, when Talkback decides to combine not-explicitly-focusable elements together, it ignores properties like "disabled", "selected", etc. so when combined only the text is transferred. The "fix" here was to make sure that if disabled was set, that an element was always explicitly focusable so that it wouldn't be eligible to be combined with others. I think that as a general concept makes sense, but the fix actually surfaced an issue that is likely a much older bug. This line in <Text> ``` accessible={accessible !== false} ``` Is basically always setting accessible="true" unless it's explicitly set to false, and has been in there for years. It was likely added to force text to be accessible by default for iOS. But until [this diff](facebook#33076) this line was basically a no-op for Android, since setting accessible="true" on text would do nothing at all. [This diff](facebook#33076) changed this so that setting accessible="true" worked how you'd expect, by making the view explicitly focusable, which was necessary for the disabled behavior to work properly. But that means that now by default all text views are explicitly focusable on both iOS and Android, and this there is likely many components that were built that don't expect this to be the case. It doesn't seem like the right fix here is to revert this behavior to its previous state, as it wasn't working how anyone would expect it to if they looked at the code, and it seems like we were relying on some fairly undocumented behavior of Talkback to get it to work how we wanted. If we truly only wanted accessible="true" to be set on all TextViews for iOS, we should be explicit about it and do a platform check before setting that property. If we didn't want this to be iOS-specific, then everything is now actually working as originally intended. For reference, this is the diff that introduced the default-accessible text - https://www.internalfb.com/diff/D1561326, and the description makes it clear that this was only tested on iOS, and the behavior was explicitly trying to map to iOS norms such as not allowing nested accessible elements. Changelog: [Android][Fixed] Make Text not focusable by default Reviewed By: ryancat Differential Revision: D36991394 fbshipit-source-id: c45d2ada72bb2d6ffeee6947d676a07fb8899449

Summary: Changelog: [Internal] Add optimizations to RNTesterPlatformTest result rendering Reviewed By: kacieb Differential Revision: D37046543 fbshipit-source-id: 53ff6560e65ddfa26c470e5ae04b642154c43d1c

Summary: TurboCxxModule doesn't use the the default JSI getter that TurboModule offers, and has custom behaviour for `getConstants` which broke the I18nAssets module in the binding experiment. Changelog: [Internal] Reviewed By: ryancat Differential Revision: D37030917 fbshipit-source-id: 187f159abc76f792ad2c7045dc2852d216ea978d

Summary: It turned out the previous attempt to rely on the Event's UIManagerType wasn't sufficient, as not all Fabric touch event had a surfaceId set on them, e.g. Modal etc. This brings back the UIManagerType detection based on reactTag, but do it only for non-rootView to keep handling touch via the right dispatcher for rootView as well. Changelog: [Fixed][Android] Bring back non-rootview touch handling based on reactTag Reviewed By: JoshuaGross, sshic Differential Revision: D37063335 fbshipit-source-id: 76e2d7ae5f00006c5ecaf50c86920ea6e85155b7

Summary: Changelog: [Internal][Fixed] - facebook#33973 breaks the internal CI, as it depends on the outdated offline mirror for `Pods/Target Support Files`. Reviewed By: cortinico Differential Revision: D37038213 fbshipit-source-id: 1d27c9c32f2c3ddecd15a83935c520d1e1524b21

Summary: facebook/yoga#1150 is better than the tricky facebook#33381 and fix the build error on react-native 0.69 with swift clang module. as facebook/yoga#1150 is landed as facebook@43f831b, i'm reverting the previous change, only leaving the necessary react_native_pods.rb change. ## Changelog [iOS] [Changed] - Better fix for yoga + swift clang module build error Pull Request resolved: facebook#33973 Test Plan: ci passed Reviewed By: cortinico, cipolleschi Differential Revision: D36998007 Pulled By: dmitryrykun fbshipit-source-id: fa11bd950e2a1be6396f286086f4e7941ad2ff5b

…on.cmake` file for RN Tester (facebook#33985) Summary: The idea behind this is to encapsulate as much build logic as possible inside a `.cmake` file which is contained inside React Native. This reduces the API surface for the users, once we apply this change to the `template` project, and makes easier for us to evolve native library dependencies on Android, without having to worry about asking users to replicate those changes. Currently the change is only on RN Tester, will replicate to the template afterwards ## Changelog [Internal] [Changed] - Encapsulate all the CMake build logic inside a `ReactNative-application.cmake` file for RN Tester Pull Request resolved: facebook#33985 Test Plan: Circle CI Reviewed By: cipolleschi Differential Revision: D37039658 Pulled By: cortinico fbshipit-source-id: 536593e3b7227158acba3f0fb6561efaaa9720a5

Summary: Please see this issue facebook#33034 for details on the problem solved by this PR. ## Changelog  [CATEGORY] [TYPE] - Message [ios] [changed] - HTTP Response headers added to the error object passed to JS code. Pull Request resolved: facebook#33880 Test Plan: Tested: (All tests done on images in rn-tester app, which is a part of this repo) 1. onError method in case image has an HTTP Error 2. onError method in case of non http error (DNS error) 3. Successful image load Reviewed By: cortinico Differential Revision: D37066159 Pulled By: cipolleschi fbshipit-source-id: 546f7678fa0321fe6c6fbef55288715cb6ddc2fd

Summary: Reverts facebook#29012 It is not really possible to properly validate if ENTRY_FILE exists since it is resolved by metro, and the server is not always running from the app root, like in a monorepo with multiple RN apps running on the same metro server. In my case I run metro on the repo root and entry file will be something like `apps/app/index.js`. `-f "$ENTRY_FILE"` will fail since the script is run from the project folder (`PROJECT_ROOT`, in my case the `apps/app` folder, so it tries to resolve `apps/app/apps/app/index.js`). I don't think this check is actually useful since metro will report the error if the entry file is invalid (fixed in facebook#30150). The error is not as user friendly, but I think it is still fine. Maybe it could be improved in metro. ## Changelog [iOS] [Fixed] - Don't validate ENTRY_FILE in react-native-xcode.sh Pull Request resolved: facebook#32762 Test Plan: Before <img width="854" alt="image" src="https://user-images.githubusercontent.com/2677334/146100834-39310c9f-1767-496a-8698-1026726a1120.png"> After if file is actually missing <img width="987" alt="image" src="https://user-images.githubusercontent.com/2677334/146100893-d01e2247-c787-4174-ac60-2f308c338c8f.png"> After if file exists, builds successfully. Reviewed By: cortinico Differential Revision: D37066073 Pulled By: cipolleschi fbshipit-source-id: 8f6b149099a39d9179996bb965daa6cd9e06feac

Summary: Pull Request resolved: facebook#33978 This Diff moves part of the utilities from the `react_native_pods` file to a specific `utils.rb` file. It adds tests for these utils and improve our test mocks. The goal is to simplify the `react_native_pods.rb` so it's easier to work with it. I decided to split this diff in 2 because it was becoming quite big. ## Changelog [iOS][Changed] - Refactoring part of the react_native_pods.rb script Reviewed By: cortinico Differential Revision: D37004347 fbshipit-source-id: a5156f7c199d082d5d895a58af80948556c51c2a

Summary: Pull Request resolved: facebook#33982 This Diff moves another part of the utilities from the `react_native_pods` file to a specific `utils.rb` file. It adds tests for these utils and improve our test mocks. The goal is to simplify the `react_native_pods.rb` so it's easier to work with it. I decided to split this diff in 2 because it was becoming quite big. ## Changelog [iOS][Changed] - Refactoring part of the react_native_pods.rb script Reviewed By: cortinico Differential Revision: D37006265 fbshipit-source-id: ffaac3270cb098fa30b73c97ce7cd350dfb8d7d6

Summary: In facebook#32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock. This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements. With this change, the clock is now monotonic (and the implementation stays consistent between platforms). More details and repro steps can be found in [this issue](facebook#33977) Closes facebook#33977 ## Changelog [General] [Fixed] - Use monotonic clock for performance.now() Pull Request resolved: facebook#33983 Test Plan: Run on iOS and Android: ``` const now = global.performance.now() console.log(`${Platform.OS}: ${now}`) ``` Reviewed By: JoshuaGross, cipolleschi Differential Revision: D37066999 Pulled By: dmitryrykun fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b

…c for over three months" Summary: Original commit changeset: 77da78a29270 Original Phabricator Diff: D36990986 (facebook@df80ed4) Reviewed By: mdvacca Differential Revision: D37074879 fbshipit-source-id: 82668c90d50b4cc6c53986aa9450eea7934402b3

Summary: Changelog: [Internal] Reviewed By: gkz Differential Revision: D37075801 fbshipit-source-id: 2e5eef84b4dde7fe789d7506a32dbbaeb7ae3b8f

Summary: We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement. Changelog: [internal] Reviewed By: JoshuaGross Differential Revision: D31057046 fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5

Summary: Adds support for handling animations in response to events on the platform side, without needing a JS round trip. With this TM, NativeViewEvents will no longer affected by JS thread - hover events will not be delayed when JS thread is busy. This makes a significant difference for VR panel apps - see test plan for an example for the before and after in Store. Changelog: [Internal] - Make NativeAnimatedNodesManager public Reviewed By: JoshuaGross Differential Revision: D37082069 fbshipit-source-id: 330acd78c547587de5545b61895e0d821fb99552

Reviewed By: ivanmurashko Differential Revision: D37102721 fbshipit-source-id: a19267b5c06d8da4ca51fc33d9f62ca768fc6f3a

Summary: Changelog: [Internal] Reviewed By: robhogan Differential Revision: D37085382 fbshipit-source-id: 21c0a6fd095d858e3cdf694d677a5c57fd7d63a1

Summary: This PR updates the Ecosystem Partners entries and performs the following changes: * **Facebook**: renamed to Meta, URL updated * **Expo**: URL updated, [EAS](https://expo.dev/eas) mention * **Software Mansion**: [App.js Conf](https://appjs.co/) mention ## Changelog N/A Pull Request resolved: facebook#34006 Test Plan: N/A Reviewed By: robhogan Differential Revision: D37121100 Pulled By: cortinico fbshipit-source-id: dc1c8b93d2fd8cb7cdd2377542f825dbd1ae1999

…vents" because hover events stopped working in felios apps in headsets Summary: Changelog: [Internal][Changed] The diff I'm backing out accidentally made Hover events in Felios apps that use RN under the hood stopped working in headsets (Oculus, Arcata). So we can't test our apps properly without these events. We, with the diff author Luna tried to fix that but it turned out to be not easy so we decided to revert the commit in order to unblock experiences teams. Original commit changeset: d6b5c32ae50b Original Phabricator Diff: D36601638 (facebook@40769f2) (Note: this ignores all push blocking failures!) Reviewed By: arhelmus Differential Revision: D37135208 fbshipit-source-id: 4f7d5f168b795690e951ce7063ae3feec3338772

Summary: Some files relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff is fixing missing imports Reviewed By: rmaz Differential Revision: D37140239 fbshipit-source-id: bc57921e0c8365e0e9a5a571d607ba40ff1b31f3

…/'em' units. Summary: A huge set of props use YGValue directly, say something really basic like `margin`/`position`/`padding`/`border`. All of these according to CSS spec actually support `number | "em" | "px" | %` units, but we are going to throw and hard crash on `em` and `px`, which are unsupported in React Native. Using `tryTo` instead of `to` (noexcept vs throwing method) for conversion, and treating things like `margin: 50px` same way as we would treat `margin: false` which is not really supported. Changelog: [General][Fixed] - Fixed a crash on deserialization of props when using 'px'/'em' units. Reviewed By: bvanderhoof Differential Revision: D37163250 fbshipit-source-id: 59cbe65a821052f6c7e9588b6d4a0ac14e344684

Summary: This sync includes the following changes: - **[5cc2487e0](facebook/react@5cc2487e0 )**: bump versions for next release ([facebook#24725](facebook/react#24725)) //<Josh Story>// - **[54f17e490](facebook/react@54f17e490 )**: [Transition Tracing] Fix Cache and Transitions Pop Order ([facebook#24719](facebook/react#24719)) //<Luna Ruan>// - **[7cf8dfd94](facebook/react@7cf8dfd94 )**: [Transition Tracing] Create/Process Marker Complete Callback ([facebook#24700](facebook/react#24700)) //<Luna Ruan>// - **[327e4a1f9](facebook/react@327e4a1f9 )**: [Follow-up] Land enableClientRenderFallbackOnTextMismatch //<Andrew Clark>// - **[a8c9cb18b](facebook/react@a8c9cb18b )**: Land enableSuspenseLayoutEffectSemantics flag ([facebook#24713](facebook/react#24713)) //<Andrew Clark>// - **[a8555c308](facebook/react@a8555c308 )**: [Transition Tracing] Add Tracing Marker Stack ([facebook#24661](facebook/react#24661)) //<Luna Ruan>// - **[8186b1937](facebook/react@8186b1937 )**: Check for infinite update loops even if unmounted ([facebook#24697](facebook/react#24697)) //<Andrew Clark>// - **[060505e9d](facebook/react@060505e9d )**: Fix misapplying prod error opt-out ([facebook#24688](facebook/react#24688)) //<Josh Story>// - **[47944142f](facebook/react@47944142f )**: `now` isn't part of the react-reconciler config anymore ([facebook#24689](facebook/react#24689)) //<Mathieu Dutour>// - **[b34552352](facebook/react@b34552352 )**: [Fizz] Support abort reasons ([facebook#24680](facebook/react#24680)) //<Josh Story>// - **[79f54c16d](facebook/react@79f54c16d )**: Bugfix: Revealing a hidden update ([facebook#24685](facebook/react#24685)) //<Andrew Clark>// - **[7e8a020a4](facebook/react@7e8a020a4 )**: Remove extra Server Context argument ([facebook#24683](facebook/react#24683)) //<Sebastian Markbåge>// - **[4f29ba1cc](facebook/react@4f29ba1cc )**: support errorInfo in onRecoverableError ([facebook#24591](facebook/react#24591)) //<Josh Story>// - **[1cd90d2cc](facebook/react@1cd90d2cc )**: Refactor of interleaved ("concurrent") update queue ([facebook#24663](facebook/react#24663)) //<Andrew Clark>// Changelog: [General][Changed] - React Native sync for revisions d300ceb...256aefb jest_e2e[run_all_tests] Reviewed By: cortinico Differential Revision: D37155957 fbshipit-source-id: 4c0afc95abe8fa13c3803584922c8dc0059ff562

Summary: Pull Request resolved: facebook#34015 I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup. Changelog: [Internal] Reviewed By: IanChilds Differential Revision: D37178005 fbshipit-source-id: cba51e168c5a2f2ee6468acb8c144db4ad352d95

…rn vs random-map-access pattern (ViewProps, minus YogaLayoutableShadowNode) Summary: Perf numbers for this stack are given in terms of before-stack and after-stack, but the changes are split up for ease of review, and also to show that this migration CAN happen per-component and is 100% opt-in. Most existing C++ components do not /need/ to change at all. # Problem Statement During certain renders (select critical scenarios in specific products), UIManagerBinding::createNode time takes over 50% of JS thread CPU time. This could be higher or lower depending on the specific product and interaction, but overall createNode takes a lot of CPU time. The question is: can we improve this? What is the minimal overhead needed? The vast, vast majority of time is taken up by prop parsing (specifically, converting JS values across the JSI into concrete values on the C++ props structs). Other methods like appendChild, etc, do not take up a significant amount of time; so we conclude that createNode is special, and the JSI itself, or calling into C++, is not the problem. Props parsing is the perf problem. Can we improve it? (Spoiler: yes) # How does props parsing work today? Today, props parsing works as follows: 1. The ConcreteComponentDescriptor will construct a RawPropsParser (one per component /type/, per application: so one for View, one for Image, one for Text... etc) 2. Once per component type per application, ConcreteComponentDescriptor will call "prepare" on the RawPropsParser with an empty, default-constructed ConcreteProps struct. This ConcreteProps struct will cause RawProps.at(field) for every single field. 3. Based on the RawProps::at calls in part 2, RawPropsParser constructs a Map from props string names (width, height, position, etc) to a position within a "value index" array. 4. The above is what happens before any actual props are parsed; and the RawPropsParser is now ready to parse actual Props. 5. When props are actually being parsed from a JSI dictionary, we now have two phases: 1. The RawPropsParser `preparse`s the RawProps, by iterating over the JSI map and filling in two additional data structures: a linear list of RawValues, and a mapping from the ValueIndex array (`keyIndexToValueIndex_`; see step 3) to a value's position in the values list (`value_` in RawPropsParser/RawProps); 2. The ConcretePropT constructor is called, which is the same as in step 2/3, which calls `fieldValue = rawProps.at("fieldName")` repeatedly. 3. For each `at` call, the RawProps will look up a prop name in the Map constructed in step 3, and either return an empty value, or map the key name to the `keyIndexToValueIndex_` array, which maps to a value in `values_`, which is then returned and further parsed. So, a few things that become clear with the current architecture: 1. Complexity is a property of the number of /possible/ props that /can/ be parsed, not what is actually used in product code. This violates the "only pay for what you use" principal. If you have `<View opacity={0.5} />`, the ViewProps constructor will request ~170 properties, not 1! 2. There's a lot of pre-parsing which isn't free 3. The levels of indirection aren't free, and make cache misses more likely and pipelining is more challenging 4. The levels of indirection also require more memory - minor, but not free # How can we improve it? The goal is to improve props parsing with minimal or zero impact on backwards-compability. We should be able to migrate over components when it's clear there's a performance issue, without requiring everything gets migrated over at once. This both (1) helps us prove out the new architecture, (2) derisks the project, (3) gives us time, internally and externally, to perfect the APIs and gradually migrate everything over before deleting the old infrastructure code entirely. Thus, the goal is to do something that introduces a zero-cost abstraction. This isn't entirely possible in practice, and in fact this method slightly regresses components that do not use the new architecture /at all/, while dramatically improving migrated components and causing the impact of the /old/ architecture to be minimal. # Solution 1. We still keep the existing system in place entirely. 2. After Props are constructed (see ConcreteComponentDescriptor changes) we iterate over all the /values/ set from JS, and call PropsT::setProp. Incidentally, this allows us to easily reuse the same prop for multiple values for "free", which was expensive in the old system. 3. It's worth noting that this makes a Props struct "less immutable" than it was before, and essentially now we have a "builder pattern" for Props. (If we really wanted to, we could still require a single constructor for Props, and then actually use an intermediate PropsBuilder to accumulate values - but I don't think this overhead would be worth for the conceptual "immutability" win, and instead a "Construct/Set/Seal" model works fine, and we still have all the same guarantees of immutability after the parsing phase) # Implementation Details # How to properly construct a single Prop value Minor detail: parsing a single prop is a 3-step process. We imagine two scenarios: (1) Creating a new ShadowNode/Props A from nothing/void, so the previous Props value is just the default constructor. (2) Cloning a ShadowNode A->B and therefore Props A must be copied to Props B before parsing. We will denote this as a clone from A->B, where A may or may not be a previous node or a default-constructed Props node; and imagine in particular that we're setting the "opacity" value for PropsB. We must first (1) copy a value over from the previous version of the Props struct, so B.opacity = A.opacity; (2) Determine if opacity has been set from JS. If so, and there is a value, B.opacity = parse(JSValue). (3) If JS has passed in a value for the prop, BUT the value is `null`, it means that JS is resetting or deleting the prop, so we must set it BACK to the default. In this case we set PropsB.opacity = DefaultConstructedProps.opacity. We must take care in general to ensure that the correct behavior is achieved here, which should help to explain some of the code below. ## String comparisons vs hash comparisons In the previous system, a RawPropsKey is three `const char*` strings, concatenated together repeatedly /at runtime/. In practice, the ONLY reason we have the prefix, name, suffix Key structure is for the templated prop parsing in ViewProps and YogaStyableProps - that's it. It's not used anywhere else. Further, the key {"margin", "Left", "Width"} is identical to the key {"marginLeftWidth", null, null} and we don't do anything fancy with matching prefixes before comparing the whole string, or similar. Before comparison, keys are concatenated into a single string and then we use `strcmp`. The performance of this isn't terrible, but it's nonzero overhead. I think we can do better and it's sufficient to compare hashed string values; even better, we can construct most of these /at compile time/ using constexpr, and using `switch` statements guarantee no hash collisions within a single Props struct (it's possible there's a collision between Props.cpp and ViewProps.cpp, for example, since they're different switch statements). We may eventually want to be more robust against has collisions; I personally don't find the risk to be too great, hash collisions with these keys are exceedingly unlikely (or maybe I just like to live dangerously). Thus, at runtime, each setProp requires computing a single hash for the value coming from JS, and then int comparisons with a bunch of pre-compiled values. If we want to be really paranoid, we could be robust to hash collisions by doing `switch COMPILED_HASH("opacity"): if (strcmp(strFromJs, "opacity") == 0)`. I'm happy to do this if there's enough concern. ## Macros Yuck! I'm using lots of C preprocessor macros. In general I found this way, way easier in reducing code and (essentially) doing codegen for me vs templated code for the switch cases and hashing prop names at compile-time. Maybe there's a better way. Changelog: [Added][Fabric] New API for efficient props construction Reviewed By: javache Differential Revision: D37050215 fbshipit-source-id: d2dcd351a93b9715cfeb5197eb0d6f9194ec6eb9

…rn vs random-map-access pattern (YogaLayoutableShadowNode / YGStyle) Summary: See commentary at top of stack. Changelog: [Added][Fabric] New API for efficient props construction Reviewed By: javache Differential Revision: D37050376 fbshipit-source-id: 2bea35a6d604704cf430bd3b2914988227d1abf8

…rn vs random-map-access pattern (ScrollViewProps) Summary: See commentary at top of stack. Changelog: [Added][Fabric] New API for efficient props construction Reviewed By: javache Differential Revision: D37050961 fbshipit-source-id: 170a09c08d7406b6aac51d7e78cf295a72fdcf91

…rn vs random-map-access pattern (BaseTextProps and derived props) Summary: See commentary at top of stack. Changelog: [Added][Fabric] New API for efficient props construction Reviewed By: javache Differential Revision: D37051020 fbshipit-source-id: 643e433c0d0590cfcd17bc7a43d105bed6ff12ef

Summary: Just bumping the offline mirrors for iOS Changelog: [Internal] [Changed] - Update iOS offine mirrors for RN-Tester Reviewed By: cortinico Differential Revision: D37187562 fbshipit-source-id: 4ede8413f98afa4694984baf06349f4330304798

…Android Summary: Hook up feature flags. Changelog: [Internal] Reviewed By: cortinico, ryancat Differential Revision: D37166366 fbshipit-source-id: 440acba9ee85a9ced64cd880d915044de7619584

Summary: `hermes-eslint` is built by Meta to work with the latest Flow code. It follows the latest ESLint standards and AST, and has a true scope analyser to ensure best compatibility with core ESLint rules. Reviewed By: motiz88 Differential Revision: D37181192 fbshipit-source-id: 1f59e01f306792e67a4977435c5c77e0000d960a

Summary: Changelog: [iOS][Internal] Remove unecessary PointerEvent attributes Reviewed By: kacieb Differential Revision: D37115465 fbshipit-source-id: 079a297d1ce5b3d2c6766036a111c73bd75535f1

Summary: Changelog: [iOS][Internal] Add width/height properties to the PointerEvent object Reviewed By: kacieb Differential Revision: D37116854 fbshipit-source-id: 686266d480bb2ee1d2b6696d80ad42865fa2111c

… grid) - JAVA ONLY CHANGES (facebook#33180) Summary: This is the Java-only changes from D34518929 (facebook@dd6325b), split out for push safety. Original summary and test plan below: This issue fixes [30977][17] . The Pull Request was previously published by [intergalacticspacehighway][13] with [31666][19]. The solution consists of: 1. Adding Javascript logic in the [FlatList][14], SectionList, VirtualizedList components to provide accessibility information (row and column position) for each cell in the method [renderItem][20] as a fourth parameter [accessibilityCollectionItem][21]. The information is saved on the native side in the AccessibilityNodeInfo and announced by TalkBack when changing row, column, or page ([video example][12]). The prop accessibilityCollectionItem is available in the View component which wraps each FlatList cell. 2. Adding Java logic in [ReactScrollView.java][16] and HorizontalScrollView to announce pages with TalkBack when scrolling up/down. The missing AOSP logic in [ScrollView.java][10] (see also the [GridView][11] example) is responsible for announcing Page Scrolling with TalkBack. Relevant Links: x [Additional notes on this PR][18] x [discussion on the additional container View around each FlatList cell][22] x [commit adding prop getCellsInItemCount to VirtualizedList][23] ## Changelog [Android] [Added] - Accessibility announcement for list and grid in FlatList Pull Request resolved: facebook#33180 Test Plan: [1]. TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer ([link][1]) [2]. TalkBack announces pages and cells with Vertical Flatlist in the Paper Renderer ([link][2]) [3]. `FlatList numColumns={undefined}` Should not trigger Runtime Error NoSuchKey exception columnCount when enabling TalkBack. ([link][3]) [4]. TalkBack announces pages and cells with Nested Horizontal Flatlist in the rn-tester app ([link][4]) [1]: fabOnReact/react-native-notes#6 (comment) [2]: fabOnReact/react-native-notes#6 (comment) [3]: fabOnReact/react-native-notes#6 (comment) [4]: fabOnReact/react-native-notes#6 (comment) [10]:https://github.com/aosp-mirror/platform_frameworks_base/blob/1ac46f932ef88a8f96d652580d8105e361ffc842/core/java/android/widget/AdapterView.java#L1027-L1029 "GridView.java method responsible for calling setFromIndex and setToIndex" [11]:fabOnReact/react-native-notes#6 (comment) "test case on Android GridView" [12]:fabOnReact/react-native-notes#6 (comment) "TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer" [13]:https://github.com/intergalacticspacehighway "github intergalacticspacehighway" [14]:https://github.com/fabriziobertoglio1987/react-native/blob/80acf523a4410adac8005d5c9472fb87f78e12ee/Libraries/Lists/FlatList.js#L617-L636 "FlatList accessibilityCollectionItem" [16]:https://github.com/fabriziobertoglio1987/react-native/blob/5706bd7d3ee35dca48f85322a2bdcaec0bce2c85/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java#L183-L184 "logic added to ReactScrollView.java" [17]: facebook#30977 [18]: fabOnReact/react-native-notes#6 [19]: facebook#31666 [20]: https://reactnative.dev/docs/next/flatlist#required-renderitem "FlatList renderItem documentation" [21]: fabOnReact@7514735 "commit that introduces fourth param accessibilityCollectionItem in callback renderItem" [22]: facebook#33180 (comment) "discussion on the additional container View around each FlatList cell" [23]: fabOnReact@d50fd1a "commit adding prop getCellsInItemCount to VirtualizedList" Reviewed By: kacieb Differential Revision: D37186697 Pulled By: blavalla fbshipit-source-id: 7bb95274326ded417c6f1365cc8633391f589d1a

Summary: We do not need to register JSTimers as a callable JavaScript module in bridgeless mode. How we know bridgeless mode doesn't use JSTimers: [xbgs JSTimers](https://fburl.com/code/clbz47j5) ## Details: iOS JSTimers is only called into [by RCTCxxBridge](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/xplat/js/react-native-github/React/CxxBridge/RCTCxxBridge.mm?lines=1471), and [RCTTiming.mm, which uses the RCTBridge](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/xplat/js/react-native-github/React/CoreModules/RCTTiming.mm?lines=23%2C241%2C264). RCTBridge is unavailable in bridgeless mode. ## Details: Android JSTimers is only called into [by TimingModule, inside its BridgeTimerExecutor](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/modules/core/TimingModule.java?lines=31%2C40%2C49). This BridgeTimerExecutor is [passed to TimingModule's JavaTimerManager](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/modules/core/TimingModule.java?lines=61-66). The Bridgeless React instance on Android **does not** use this TimingModule, or this BridgeTimerExecutor. Instead, the Bridgeless React instance [creates its own JavaTimerManager](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/fbandroid/java/com/facebook/venice/ReactInstance.java?lines=118-123), [in C++](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/fbandroid/java/com/facebook/venice/ReactInstance.java?lines=117%2C121%2C382), that [implements the callTimers APIs in C++](https://www.internalfb.com/code/fbsource/[88911d726fb4413765903c32a9077cd662ee7b6e]/fbandroid/java/com/facebook/venice/jni/JJSTimerExecutor.cpp?lines=18-22). Therefore, in Bridgeless mode, the React instance calls into TimerManager to execute timers, whereas in Bridge mode, TimingModule calls into JSTimers to call timers. Hence, JSTimers should also not be used in bridgeless mode. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D37208873 fbshipit-source-id: ef6ebe0e8a9fcbcc1f8403ed40ff94ec00b2beac

Summary: The eslint community config does not have the File and Blob polyfills in `globals` which have been part of the Javascript implementation for ~3 years. They were added to the Javascript API in facebook#11573 by satya164. ## Changelog  [General] [Fixed] - Added File and Blob globals to eslint community config Pull Request resolved: facebook#31293 Test Plan: Evidence these globals exist: 1. facebook#11573 2. Executed the following: <img width="421" alt="Screen Shot 2021-04-02 at 12 08 50 PM" src="https://user-images.githubusercontent.com/3495974/113432946-466ae280-93ac-11eb-899c-3ca124e0af84.png"> <img width="317" alt="Screen Shot 2021-04-02 at 12 11 56 PM" src="https://user-images.githubusercontent.com/3495974/113433156-a82b4c80-93ac-11eb-99dc-0840d5ad9078.png"> 3. Receive in console: <img width="603" alt="Screen Shot 2021-04-02 at 12 09 59 PM" src="https://user-images.githubusercontent.com/3495974/113432996-5da9d000-93ac-11eb-81c6-88e6b059c733.png"> <img width="599" alt="Screen Shot 2021-04-02 at 12 12 27 PM" src="https://user-images.githubusercontent.com/3495974/113433174-b711ff00-93ac-11eb-8820-67039696f6ce.png"> Evidence the PR works: the globals in the PR identical to the others in the eslint community config that they are in Reviewed By: cipolleschi Differential Revision: D37214364 Pulled By: cortinico fbshipit-source-id: 71b9dec8d222a057c54f6cde6c6d8e85dd25f6f9

Summary: Original commit changeset: 4c0afc95abe8 Original Phabricator Diff: D37155957 (facebook@d1321d8) See attached UBN task for more details, I am reverting the whole diff now while investigating the root cause. Changelog: [General][Changed] - Revert "React Native sync for revisions d300ceb...256aefb" jest_e2e[run_all_tests] === update klein did a bisect for S276290, it seems Original Phabricator Diff: D37155957 (facebook@d1321d8) is the blame diff. jackworden also has verified backout can fix it for both ios and android. Reviewed By: ahujap-fb, kacieb Differential Revision: D37205394 fbshipit-source-id: 600e6593532da064631c016aace317932f290c67

Summary: LogBox was using AppRegistry to render on to the screen. Switch LogBox over to using SurfaceRegistry instead. Changelog: [Internal] Reviewed By: sshic Differential Revision: D37223641 fbshipit-source-id: 59001ad290c1e2c2f14828d38a96f48bd1ab39ca

…available Summary: SurfaceRegistryBinding::startSurface [checks whether global.RN$SurfaceRegistry binding is installed](https://www.internalfb.com/code/fbsource/[7040bef7d4fe43298c5f9dc1fef10f47ec396e79]/xplat/js/react-native-github/ReactCommon/react/renderer/uimanager/SurfaceRegistryBinding.cpp?lines=28-29). If not, control flow goes directly into the bridge path: [callFunctionOnModule](https://www.internalfb.com/code/fbsource/[7040bef7d4fe43298c5f9dc1fef10f47ec396e79]/xplat/js/react-native-github/ReactCommon/react/renderer/uimanager/SurfaceRegistryBinding.cpp?lines=40-46). callMethodOfModule [react_native_asserts, if the requested callable JS module isn't available](https://www.internalfb.com/code/fbsource/[7040bef7d4fe43298c5f9dc1fef10f47ec396e79]/xplat/js/react-native-github/ReactCommon/react/renderer/uimanager/bindingUtils.cpp?lines=29) on the batched bridge. This crashes the app. We could make this error experience better: 1. We shouldn't crash the app. 2. We should fail fast, and produce an error message that is more descriptive of the actual cause of the error. 3. We can leverage the RedBox infra to display this error on the screen. ## Fixes This diff modifies the gating inside SurfaceRegistryBinding. Now, in bridgeless mode, if global.RN$SurfaceRegistry isn't instaled, we'll display a RedBox instead, that shows what the error is. Changelog: [Internal] Reviewed By: sshic Differential Revision: D37223640 fbshipit-source-id: 8fbf57f5d9cf359046dc94f0a5f7d66624caee4e

Summary: Fixes facebook#33751 Relates to facebook#33576 Jest 28 removed support for returning a string in the process method of a transformer (https://jestjs.io/docs/upgrading-to-jest28#transformer). This PR changes assetFileTransformer to return an object instead of a string. ## Changelog [Internal] [Fixed] - Return object from assetFileTransformer Pull Request resolved: facebook#33756 Test Plan: Tests pass with Jest 28 when this change is made. Reviewed By: cipolleschi Differential Revision: D37242038 Pulled By: cortinico fbshipit-source-id: d8a5054f5378183f644cd1458785084b26782193

Summary: Fixes a trivial crash that occurs when running View Recycling on pre-Android P devices. Changelog: [Internal] Reviewed By: bvanderhoof Differential Revision: D37242858 fbshipit-source-id: 74f3912d60799172c47c67a87f662b4ff8fb1e35

Summary: This is what I had to do locally to fix facebook#33966 ## Changelog  [iOS] [Fixed] - Fix sed error when installing `glog` Pull Request resolved: facebook#33967 Test Plan: After this, `pod install` installed `glog` successfully <img width="255" alt="image" src="https://user-images.githubusercontent.com/8580352/172226617-6fe8c3df-1629-42e9-95a4-a9c0ebe675a8.png"> Reviewed By: cortinico Differential Revision: D36943821 Pulled By: charlesbdudley fbshipit-source-id: 8f6aa64089b22d23f8c4a015ff30a3789e612b4e

Summary: Changelog: [Internal] Reviewed By: nlutsenko Differential Revision: D37250414 fbshipit-source-id: be3b98ba661c6f267d0d0dcac8d816584ef58c51

…#32748) Summary: Currently `ListHeaderComponent` & `ListFooterComponent` allow to use React Componetn & Elemelen ```tsx <FlatList ListHeaderComponent={<View />} // valid ListHeaderComponent={View} // valid /> ``` But when you try to pass `ItemSeparatorComponent` as React Element it will throw an error ```tsx <FlatList ItemSeparatorComponent={View} // ok ItemSeparatorComponent={<View />} /* not valid: Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. Check the render method of `CellRenderer`. */ /> ``` So, this PR adds this ability ## Changelog  [General] [Changed] - Add ability to pass `ItemSeparatorComponent` as React Element Pull Request resolved: facebook#32748 Test Plan: ... Reviewed By: lyahdav Differential Revision: D37227719 Pulled By: cortinico fbshipit-source-id: 1c4943fa9d42bf5e61fbd999d1f5be46b51ecb14

…3990) Summary: Pull Request resolved: facebook#33990 This diff moves the setting of some CPP flags from the main React native pods file to a dedicated file. It also introduces some tests and it improves the Test Mocks we have ## Changelog [iOS][Changed] - Move the `modify_flags_for_new_architecture` method to separate ruby file Reviewed By: cortinico Differential Revision: D37040927 fbshipit-source-id: 037ddaf123d01f3a2fd622b8a0cd10535da70b92

… grid) - Javascript Only Changes (facebook#33180) Summary: This is the Javascript-only changes from D34518929 (facebook@dd6325b), split out for push safety. Original summary and test plan below: This issue fixes [30977][17] . The Pull Request was previously published by [intergalacticspacehighway][13] with [31666][19]. The solution consists of: 1. Adding Javascript logic in the [FlatList][14], SectionList, VirtualizedList components to provide accessibility information (row and column position) for each cell in the method [renderItem][20] as a fourth parameter [accessibilityCollectionItem][21]. The information is saved on the native side in the AccessibilityNodeInfo and announced by TalkBack when changing row, column, or page ([video example][12]). The prop accessibilityCollectionItem is available in the View component which wraps each FlatList cell. 2. Adding Java logic in [ReactScrollView.java][16] and HorizontalScrollView to announce pages with TalkBack when scrolling up/down. The missing AOSP logic in [ScrollView.java][10] (see also the [GridView][11] example) is responsible for announcing Page Scrolling with TalkBack. Relevant Links: x [Additional notes on this PR][18] x [discussion on the additional container View around each FlatList cell][22] x [commit adding prop getCellsInItemCount to VirtualizedList][23] ## Changelog [Android] [Added] - Accessibility announcement for list and grid in FlatList Pull Request resolved: facebook#33180 Test Plan: [1]. TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer ([link][1]) [2]. TalkBack announces pages and cells with Vertical Flatlist in the Paper Renderer ([link][2]) [3]. `FlatList numColumns={undefined}` Should not trigger Runtime Error NoSuchKey exception columnCount when enabling TalkBack. ([link][3]) [4]. TalkBack announces pages and cells with Nested Horizontal Flatlist in the rn-tester app ([link][4]) [1]: fabOnReact/react-native-notes#6 (comment) [2]: fabOnReact/react-native-notes#6 (comment) [3]: fabOnReact/react-native-notes#6 (comment) [4]: fabOnReact/react-native-notes#6 (comment) [10]:https://github.com/aosp-mirror/platform_frameworks_base/blob/1ac46f932ef88a8f96d652580d8105e361ffc842/core/java/android/widget/AdapterView.java#L1027-L1029 "GridView.java method responsible for calling setFromIndex and setToIndex" [11]:fabOnReact/react-native-notes#6 (comment) "test case on Android GridView" [12]:fabOnReact/react-native-notes#6 (comment) "TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer" [13]:https://github.com/intergalacticspacehighway "github intergalacticspacehighway" [14]:https://github.com/fabriziobertoglio1987/react-native/blob/80acf523a4410adac8005d5c9472fb87f78e12ee/Libraries/Lists/FlatList.js#L617-L636 "FlatList accessibilityCollectionItem" [16]:https://github.com/fabriziobertoglio1987/react-native/blob/5706bd7d3ee35dca48f85322a2bdcaec0bce2c85/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java#L183-L184 "logic added to ReactScrollView.java" [17]: facebook#30977 [18]: fabOnReact/react-native-notes#6 [19]: facebook#31666 [20]: https://reactnative.dev/docs/next/flatlist#required-renderitem "FlatList renderItem documentation" [21]: fabOnReact@7514735 "commit that introduces fourth param accessibilityCollectionItem in callback renderItem" [22]: facebook#33180 (comment) "discussion on the additional container View around each FlatList cell" [23]: fabOnReact@d50fd1a "commit adding prop getCellsInItemCount to VirtualizedList" Reviewed By: kacieb Differential Revision: D37189197 Pulled By: blavalla fbshipit-source-id: 3765213c5d8bfde56e0e5f155cdd899c368512e7

… (list and grid) - Javascript Only Changes" Summary: Original commit changeset: 3765213c5d8b Original Phabricator Diff: D37189197 (facebook@2d58821) Changelog: [Internal] Reviewed By: bvanderhoof Differential Revision: D37260990 fbshipit-source-id: bfcb10f2d5a2a1427b72a10ef380df194b041ba0

Summary: Rewrites `EventEmitter` as a simple, type-safe abstraction with a minimal interface. The public interface of `EventEmitter` is unchanged. This rewrite was made possible only after deprecating and removing public methods that imposed restrictions on implementation details (e.g. deleting `removeListener`). However, this includes a subtle breaking change that makes it behave the same as `EventEmitter` in Node.js and `EventTarget` in the DOM. The set of listeners being notified by `emit` will no longer be influenced by changes made during the course of notifying the existing listeners. Changelog: [General][Changed] - `EventEmitter#emit` now freezes the set of listeners before iterating over them, meaning listeners that are added or removed will not affect that iteration. Reviewed By: javache Differential Revision: D22153962 fbshipit-source-id: 81b87113590dee0296eff61374bf732171855453

…abled (facebook#34030) Summary: This PR is fixing the build errors on iOS when `use_frameworks!` and `:hermes_enabled` are both enabled. There are two errors: - fmt/compile.h include not found: This PR adds fmt in header search paths. - undefined symbols `_jump_fcontext` and `_make_fcontext` from boost. the two symbols are actually not be unused. because to generate the shared library in dynamic framework mode, LTO (Link-Time-Optimization) is not as powerful as generating a single executable. ## Changelog [iOS] [Fixed] - Fix RCT-Folly build error when use_frameworks! and hermes are both enabled Pull Request resolved: facebook#34030 Test Plan: - CI passed - ``` $ npx react-native init RN069 --version next # edit RN069/ios/Podfile to enable use_frameworks! and hermes_enabled # patch node_modules/react-native from both facebook#34011 and this prs' patch $ pod install $ yarn ios ``` Reviewed By: cortinico Differential Revision: D37284084 Pulled By: dmitryrykun fbshipit-source-id: 923fa03d7844d1d227880919c8b2c8614c848d59

Summary: `use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things: - use `header_mappings_dir` to keep `react/bridging` header structure - because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary. - forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec. ## Changelog [iOS] [Fixed] - Fix use_frameworks! for 0.69 Pull Request resolved: facebook#34011 Test Plan: ```sh $ npx react-native init RN069 --version next # add `use_frameworks!` to ios/Podsfile # comment out use_flipper!() in ios/Podfile # patch node_modules/react-native with these changes $ yarn ios ``` Reviewed By: cortinico, cipolleschi Differential Revision: D37169699 Pulled By: dmitryrykun fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0

…eceiveEvent Summary: # Context ScrollView sticky headers rely on this bit of code to work: ``` AnimatedImplementation.attachNativeEvent( this._scrollViewRef, 'onScroll', [{nativeEvent: {contentOffset: {y: this._scrollAnimatedValue}}}], ); ``` What this code means: When the ScrollView host component receives the "onScroll" event, assign event.nativeEvent.contentOffSet.y to the this._scrollAnimatedValue AnimatedValue. How this subscription mechanism is set up: NativeAnimatedTurboModule subscribes to events dispatched by RCTEventDispatcher sendEvent. Then, whenever RCTEventEmitter sendEvent executes, NativeAnimatedTurboModule also updates the AnimatedValue for that event. # Problem Previously, in bridgeless, we started dispatching RCTScrollView via the RCTEventDispatcher sendEvent to update the AnimatedValue for ScrollView. This meant that we started dispatching the onScroll event to JavaScript via RCTEventEmitter.receiveEvent JSModule, which isn't supported in the Fabric renderer. With this diff, we dialed back that solution. Instead of (1) notifying NativeAnimatedTurboModule and (2) sending the onScroll event to JavaScript, we're only doing (1) (i.e: notifying NativeAnimatedTurboModule). Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D37257719 fbshipit-source-id: 7dea3cf8b9ae78f6b0fd40414b8f224d43367a5a

Summary: Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D37313175 fbshipit-source-id: 3a8507a4914bcafb1ec84ed260d67cd28bba9169

Summary: Original commit changeset: 78387999f94e Original Phabricator Diff: D34392529 (facebook@086c13d) Backing this out because it breaks univeral hot reload support. We should probably find a way to support this *without* relying on swizzling. This was originally backed out it because it was blocking app store submission, but this is gated by `RN_DEV` so should never be included in a release build. Changelog: [General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's Reviewed By: cipolleschi Differential Revision: D37311377 fbshipit-source-id: 18abb1b53a5be054098cd3717705ea5086c4f595

Summary: Bumping RTC-Folly version used to address CVE-2022-24440. ## Changelog  [General][Security] - Bump RTC-Folly to 2021-07-22 Pull Request resolved: facebook#33841 Reviewed By: Andjeliko, philIip Differential Revision: D36425598 Pulled By: cortinico fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af

Summary: Fix crashes that can occur on older versions of Android due to not-yet-implemented APIs. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D37321713 fbshipit-source-id: a27aaf4b28e19a86f4cb10808162102177b9f306

Summary: ## Changelog  [Internal] - Changelog for 0.69.0 Pull Request resolved: facebook#33730 Reviewed By: lunaleaps Differential Revision: D36007445 Pulled By: cortinico fbshipit-source-id: adb9070a83b992f7138e93710a0508be59f07832

Summary: Changelog: [iOS][Internal] - Add tiltX/tiltY properties to the PointerEvent interface Reviewed By: necolas Differential Revision: D37117909 fbshipit-source-id: 277d1296b16bbf729dbc32f385634752fd145c8f

Summary: Changelog: [iOS][Internal] Add detail property to the PointerEvent interface Reviewed By: necolas Differential Revision: D37117932 fbshipit-source-id: a5f1c6386d2521e22651453efeffe2005e4a8b6e

…lag on Wilde Summary: Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D37269572 fbshipit-source-id: ba9ecea2d81075a7ce79e26040924d04b170bf46

Summary: This PR is a follow up for the contributing content move on the website: * facebook/react-native-website#3120 It replaces most of the CONTRIBUTING file content with a reference to the contributing overview page on the website, which has been based off the content of this file. Additionally I have searched thought the code for the wiki links and replaces theme with the correct website links. There was an instance where comment was referring to an old and removed a while ago wiki page, so I just get rid of this link. ## Changelog [Internal] [Chore] - Update CONTRIBUTING.md, replace wiki links Pull Request resolved: facebook#34035 Test Plan: N/A Reviewed By: lunaleaps Differential Revision: D37318814 Pulled By: cortinico fbshipit-source-id: d3f5e5c5bd477c0de5c4f0f1d5de81f464b9f5b4

Summary: [`babel-eslint`](https://github.com/babel/babel-eslint) is deprecated now. We should use the new Babel parser. ## Changelog  [General] [Fixed] - Use new Babel parser instead of deprecated one Pull Request resolved: facebook#34020 Test Plan: Ensure lint is working as expected. Reviewed By: cortinico Differential Revision: D37239826 Pulled By: jacdebug fbshipit-source-id: f5fa5d7f829d6d3ae5cffd855ed6c8542c7d46de

Summary: ThemedReactContext should be what is stored as the context on all RN views, but some legacy components use other things like an Activity. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D37356865 fbshipit-source-id: bc914cd06a8846037506a50f254995a6e10c8a9c

Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable. Reviewed By: evanyeung Differential Revision: D37360113 fbshipit-source-id: 870bcfe680542b3861fefbaf372db0ae8b32cbf3

Summary: This removes the `hermes-engine` NPM package from the RN package.json. Users are not supposed to use this package anymore as we now ship Hermes bundled with React Native. More on this here: https://reactnative.dev/architecture/bundled-hermes Changelog: [General] [Changed] - Do not depend on hermes-engine NPM package anymore Reviewed By: neildhar Differential Revision: D37353977 fbshipit-source-id: b049d18e945a72c1f37c3e4b040af83b5e395774

Summary: Pull Request resolved: facebook#34049 This just flips the switch for having Hermes on by default on new projects for React Native. Changelog: [Android] [Changed] - Make Hermes the default engine on Android Reviewed By: neildhar, jpporto Differential Revision: D37354079 fbshipit-source-id: cb0391eb3927d13432e7d4b9efef7b8812938a98

Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable. Reviewed By: evanyeung Differential Revision: D37353648 fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28

Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable. Reviewed By: bradzacher Differential Revision: D37363351 fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a

Summary: As we changed the deps for react-native/eslint-plugin-specs, let's release a new version of it. Changelog: [General] [Changed] - Bump react-native/eslint-plugin-specs to 0.0.4 Reviewed By: jacdebug Differential Revision: D37353474 fbshipit-source-id: dc77c987ee06d72903d246544c63816a64ecd7f6

Summary: This improves errors significantly, which is especially helpful as the runtime scheduler only implements a subset of the JS API. Example error: `Error: Exception in HostObject::get for prop 'unstable_next': undefined property` Changelog: [Internal] Reviewed By: rickhanlonii Differential Revision: D37313924 fbshipit-source-id: b53bc67b9cc36dee34dba86c07fdcf2353338c72

Summary: We need to check that the animated node exists prior to executing the animation. The native animated node lifecycle is not synced with Fabric and nodes are frequently destroyed and re-created on rerenders. Therefore, there is a possibility that the the animated node does not exist when the native event is dispatched, in particular with native call batching. Changelog: [Internal] - Make NativeAnimatedNodesManager.getNodeById public Reviewed By: JoshuaGross Differential Revision: D37323138 fbshipit-source-id: ed0567871b4189c454b6b3145b853ecdfe844840

…or hover events" because hover events stopped working in felios apps in headsets" Summary: Changelog: [Internal] - Reland pointer event dispatch optimization. Have a fix in followup commit. Reviewed By: vincentriemer Differential Revision: D37348771 fbshipit-source-id: 495dda301849255ddc2b35cc5ef9054f10f77ce8

Summary: Changelog: [Internal] Fixing a recent optimization to prevent event dispatches for events that are not listened for. An incorrect hitpath was passed in for `leave` events. Refactored the PointerEvent optimization such that `filterByShouldDispatch` determines what views should dispatch a PointerEvent, and `dispatchEventForViewTargets` to actually dispatch them. We are separating this because the order of dispatch differs between `enter` and `leave` events. Reviewed By: vincentriemer Differential Revision: D37348726 fbshipit-source-id: a09a04df3ae027cce95e0d93a4163c2015fe3fe3

…hermes to correctly decide which DSO to load at app startup. (facebook#33952) Summary: The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration. Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native. So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files. The code snippet in **ReactInstanceManager** for adding a new setter method: ``` /** * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call * Uses the enum {link JSInterpreter} * param jsEngine */ private void setJSEngine(JSInterpreter jsEngine){ this.jsEngine = jsEngine; } /** * Utility setter to set the required JSEngine as HERMES or JSC * Defaults to OLD_LOGIC if not called by the host app * param hermesEnabled * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise */ public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){ if(hermesEnabled){ setJSEngine(JSInterpreter.HERMES); } else{ setJSEngine(JSInterpreter.JSC); } return this; } ``` The code snippet for the new logic in **ReactInstanceManagerBuilder**: 1) Setting up the new logic: Adding a new enum class : ``` public enum JSInterpreter { OLD_LOGIC, JSC, HERMES } ``` A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable. ``` /** * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call * Uses the enum {link JSInterpreter} * param jsEngine */ private void setJSEngine(JSInterpreter jsEngine){ this.jsEngine = jsEngine; } /** * Utility setter to set the required JSEngine as HERMES or JSC * Defaults to OLD_LOGIC if not called by the host app * param hermesEnabled * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise */ public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){ if(hermesEnabled){ setJSEngine(JSInterpreter.HERMES); } else{ setJSEngine(JSInterpreter.JSC); } return this; } ``` 2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one: ``` private JavaScriptExecutorFactory getDefaultJSExecutorFactory( String appName, String deviceName, Context applicationContext) { // Relying solely on try catch block and loading jsc even when // project is using hermes can lead to launch-time crashes especially in // monorepo architectures and hybrid apps using both native android // and react native. // So we can use the value of enableHermes received by the constructor // to decide which library to load at launch // if nothing is specified, use old loading method // else load the required engine if (jsEngine == JSInterpreter.OLD_LOGIC) { try { // If JSC is included, use it as normal initializeSoLoaderIfNecessary(applicationContext); JSCExecutor.loadLibrary(); return new JSCExecutorFactory(appName, deviceName); } catch (UnsatisfiedLinkError jscE) { if (jscE.getMessage().contains("__cxa_bad_typeid")) { throw jscE; } HermesExecutor.loadLibrary(); return new HermesExecutorFactory(); } } else if (jsEngine == JSInterpreter.HERMES) { HermesExecutor.loadLibrary(); return new HermesExecutorFactory(); } else { JSCExecutor.loadLibrary(); return new JSCExecutorFactory(appName, deviceName); } } ``` ### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix** ``` builder = ReactInstanceManager.builder() .setApplication(this) .setJsEngineAsHermes(BuildConfig.HERMES_ENABLED) .setBundleAssetName("index.android.bundle") .setJSMainModulePath("index") ``` where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle: `def enableHermes = project.ext.react.get("enableHermes", true) ` and then ``` defaultConfig{ if(enableHermes) { buildConfigField("boolean", "HERMES_ENABLED", "true") } else{ buildConfigField("boolean", "HERMES_ENABLED", "false") } } ``` Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button. This change can possibly solve many of the issues listed in the list as it solved ours. ## Changelog [GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package: ``` /** * An enum that specifies the JS Engine to be used in the app * Old Logic uses the legacy code * JSC/HERMES loads the respective engine using the revamped logic */ public enum JSInterpreter { OLD_LOGIC, JSC, HERMES } ``` [GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder: ``` private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC; ``` [GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder: ``` /** * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call * Uses the enum {link JSInterpreter} * param jsEngine */ private void setJSEngine(JSInterpreter jsEngine){ this.jsEngine = jsEngine; } /** * Utility setter to set the required JSEngine as HERMES or JSC * Defaults to OLD_LOGIC if not called by the host app * param hermesEnabled * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise */ public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){ if(hermesEnabled){ setJSEngine(JSInterpreter.HERMES); } else{ setJSEngine(JSInterpreter.JSC); } return this; } ``` [GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method ``` private JavaScriptExecutorFactory getDefaultJSExecutorFactory( String appName, String deviceName, Context applicationContext) { // Relying solely on try catch block and loading jsc even when // project is using hermes can lead to launch-time crashes especially in // monorepo architectures and hybrid apps using both native android // and react native. // So we can use the value of enableHermes received by the constructor // to decide which library to load at launch // if nothing is specified, use old loading method // else load the required engine if (jsEngine == JSInterpreter.OLD_LOGIC) { try { // If JSC is included, use it as normal initializeSoLoaderIfNecessary(applicationContext); JSCExecutor.loadLibrary(); return new JSCExecutorFactory(appName, deviceName); } catch (UnsatisfiedLinkError jscE) { if (jscE.getMessage().contains("__cxa_bad_typeid")) { throw jscE; } HermesExecutor.loadLibrary(); return new HermesExecutorFactory(); } } else if (jsEngine == JSInterpreter.HERMES) { HermesExecutor.loadLibrary(); return new HermesExecutorFactory(); } else { JSCExecutor.loadLibrary(); return new JSCExecutorFactory(appName, deviceName); } } ``` Pull Request resolved: facebook#33952 Test Plan: The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project. It can be like: ``` packagingOptions { if (enableHermes) { exclude "**/libjsc*.so" } } ``` Reviewed By: lunaleaps Differential Revision: D37191981 Pulled By: cortinico fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e

Summary: Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D37392308 fbshipit-source-id: 6fb76725065a604a81686c546a779decca3cd0a5

Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable. Reviewed By: bradzacher Differential Revision: D37388949 fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8

Summary: `asHostObject` should throw a `JSINativeException` like the other `as*` functions. This should be a safe change to make in most cases, since this function already did not work when JSI was being provided by a dynamic library. However, I defer to mhorowitz. Changelog: [Fixed] Throw JSINativeException from asHostObject Reviewed By: jpporto Differential Revision: D36873355 fbshipit-source-id: 589ac50ebb4ecec4bacfd923d8b0795c0a6c0e34

Summary: `getCurrentPriorityLevel` is a function which should return the priority level on invocation. Changelog: [Internal] Reviewed By: ryancat Differential Revision: D37314727 fbshipit-source-id: fe385af02af49d1ca444beb881a4893f7f0712f0

Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable. Details: - Codemod script: `scripts/flow/tool add-comments --all --code missing-local-annot --comment "The type annotation(s) required by Flow's LTI update could not be added via codemod" .` - Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035) - Codemod announcement: [post](https://fb.workplace.com/groups/flowlang/posts/917522612186736) - Support group: [Flow Support](https://fb.workplace.com/groups/flow) bypass-lint drop-conflicts Reviewed By: evanyeung Differential Revision: D37403582 fbshipit-source-id: 2024542952042dd93e2c123ba047410e1feca749

…3777) Summary: Provides necessary changes for the autolinking to work in new architecture on Android. Depends on react-native-community/cli#1603 and is subject to change. Upgraded the RN CLI to v9.0.0-alpha.0 so that it's testable locally. ## Changelog  [Android] [Change] - Adapt template to new architecture autolinking on Android Pull Request resolved: facebook#33777 Test Plan: CI Reviewed By: cipolleschi Differential Revision: D36478984 Pulled By: cortinico fbshipit-source-id: 970fa7bcb77898d9defae18c20026a7783ba4108

Summary: Changelog: [RNTester][Internal] - Add basic pointermove test to RNTester platform test suite Reviewed By: lunaleaps Differential Revision: D37324483 fbshipit-source-id: 5c2fdd8ef4bb38052966116e46d3cfdf6c525ee0

Summary: Changelog: [iOS][Internal] - Emit move PointerEvents when hovering with an indirect pointer This diff ensures that when a user is hovering an RN app w/ an indirect pointer (mouse/trackpad/ect.) that `pointermove` events are emitted. Previously `pointermove` was only fired on touch interactions on iOS. Reviewed By: lunaleaps Differential Revision: D37353158 fbshipit-source-id: 30366324ea10c91a38dbbc1be1032c021fd8a0e0

Summary: Changelog: [Internal] - Fix a bug in dispatch filtering that was too aggressively filtering out events to fire. My flaw in logic was limiting the `isListening(view, bubble)` logic to `i==0` for relevant `ViewTargets`, when in reality, we need to be checking if every `ViewTarget` passed to `filterByShouldDispatch` is listening to a bubble event. Further, as vincentriemer pointed out, `ancestorListening` should only be set true if a `ViewTarget` is listening to a capture event. Reviewed By: vincentriemer Differential Revision: D37423952 fbshipit-source-id: 2ed08038632677c24766bca6214dc00013fa2446

Summary: TL;DR: For applications using JS navigation, save 50-95% of CPU during mounting phase in N>2 navigations that replace ~most of screen. During investigation of performance on the UI thread of React Native applications, I noticed that the /initial/ render of an screen for an application using JS navigation is /mostly/ consumed (on the UI thread) by tearing-down the previous View hierarchy. In one 185ms segment on the UI thread in production, 95% of the CPU time was Remove/Delete instructions and only 5% of CPU time was consumed by actually displaying the new hierarchy (this is specific to Android and also assumes that View Preallocation is being used, so post-commit work consists of Insert and UpdateLayout mutations primarily). There are /some/ cases where the C++ differ knows that we are deleting an entire subtree and therefore we could communicate this to the mounting layer. All that matters is that these Views are removed from the View hierarchy immediately; and secondarily that their memory is cleaned up ASAP, but that doesn't need to happen immediately. Some additional constraints and notes: 1) As noted in the comments, we cannot simply stop producing Remove and Delete instructions. We need to produce /both/ the new RemoveDeleteTree instruction, /and/ produce all the Remove/Delete instructions, primarily because LayoutAnimations relies heavily on these Remove/Delete instructions and certain things would break if we removed those instructions entirely. However, we can mark those Remove/Delete instructions as redundant, process them only in LayoutAnimations, and not send them to the Android mounting layer. 2) We want to make sure that View Recycling is not impacted. Since Android cannot take advantage of View Recycling until /after/ the second major render (preallocation of views will happen before any views are recycled), this doesn't impact View Recycling and we'll make sure Views are recycled whenever they are deleted. Thus, we do two things: 1) Introduce a new RemoveDeleteTree operation that can delete an entire subtree recursively as part of one operation. This allows us to avoid serializing hundreds or thousands of instructions and prevents JNI traffic. 2) Besides removing the topmost View from the View hierarchy, and ensuring it's not drawn, the full teardown and recycling of the tree can happen /after/ the paint. In some flows with JS navigation this saves us 95% of CPU during the mount phase. In the general case it is probably closer to 25-50% of CPU time that is saved and/or deferred. Changelog: [Android][Changed] Significant perf optimization to Fabric Remove/Delete operations Reviewed By: ryancat Differential Revision: D37257864 fbshipit-source-id: a7d33fc74683939965cfb98be4db7890644110b2

Summary: Pull Request resolved: facebook#34025 This diff moves the monkeypatch LocalPodspecPatch to a dedicated ruby file. It also adds test for that ## Changelog [iOS][Changed] - Move LocalPodspecPatch to dedicated file Reviewed By: cortinico Differential Revision: D37069361 fbshipit-source-id: 28fddb197484f45aa20ccac516c874e79448e999

Summary: Removes the `isTVOS` check, which just duplicated and returned the `isTV` check anyway. ## Changelog  [General] [Removed] - Remove deprecated `isTVOS` constant. Pull Request resolved: facebook#34071 Test Plan: Run against CI, and apply changes as needed. Reviewed By: cipolleschi Differential Revision: D37434978 Pulled By: cortinico fbshipit-source-id: 2b38253125251b0ce28cf10c88471d8f16704999

Summary: We will use this error reporting pipeline for all js errors not only early js errors, so remove all "early" prefixes. Changelog: [General][Changed] - Remove "Early" in Js error reporting pipeline Reviewed By: fkgozali Differential Revision: D37379339 fbshipit-source-id: d44772818ead977a164c8632c081863851046be6

Summary: setFocusable(int) was added in Android O, and setHyphenationFreqauency was added in M. Changelog: [Internal] Reviewed By: kacieb Differential Revision: D37462117 fbshipit-source-id: e59d2de49dbdcddfdba25def6bb39695c65efe89

Summary: This was introduced a while ago in D3635319 (facebook@0418353), and was never really adopted. Changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D37460402 fbshipit-source-id: 70586b23697e02208c393e556625ae534773177f

…acebook#34082) Summary: This is the companion PR of react-native-community/cli#1630 It extends the `ReactNative-application.cmake` file with instructions to pickup the autolinked libraries. ## Changelog [Internal] [Changed] - Extend the RN Application.cmake file to support Android autolinking Pull Request resolved: facebook#34082 Test Plan: Tested locally as we don't have a way to test autolinking on CI. Reviewed By: cipolleschi Differential Revision: D37463203 Pulled By: cortinico fbshipit-source-id: 0b28e7f214c265ebfec4ccc59ae321f682299cf8

Summary: Remove deprecated "Transform" style attributes. These attributes were first deprecated in commit [ed76d4d](facebook@ed76d4d) ## Changelog  [General] [Removed] - Remove previously deprecated Transform style-attribute props Pull Request resolved: facebook#34050 Test Plan: ~~TBD~~ CI checks are sucessful. Reviewed By: cortinico Differential Revision: D37483285 Pulled By: cipolleschi fbshipit-source-id: d1b9522f9194432a8ec6a4391715e23ac83199bf

Summary: I'm simplifying the `Android.mk` file inside the template as it was confusing. There are two ways to include the generated code from the codegen: 1. Importing the generated Android.mk file 2. Include the generate source files in the `_appmodules` source files. Those two approaches are mutually exclusive (as doing both will lead to duplicate symbols). Our template comments were confusing and were suggesting a combination of both. I'm simplifying the comments here by removing the one suggesting to go with option `1` instead. ## Changelog [Android][Changed] - Simplify the Android.mk file in the App Template Pull Request resolved: facebook#34080 Test Plan: Nothing to test here as it's a comments only change Reviewed By: cipolleschi Differential Revision: D37463222 Pulled By: cortinico fbshipit-source-id: 30ecc6fbbbcaf484272b4c724600cda588146506

Summary: `InputAccessoryView` works fine on iOS, but crashes on Android - you can see that by using an Android device on the [Expo Snack from the official doc](https://reactnative.dev/docs/inputaccessoryview). It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues. I am of course open to discussion about this change, as well as other implementation ideas. ## Changelog [Android] [Fixed] - Fix InputAccessoryView crash on Android Pull Request resolved: facebook#33803 Test Plan: `yarn test` gives out the following output: ![image](https://user-images.githubusercontent.com/3397791/167677057-3fda5b53-78bf-4bab-976f-c2e624f4a264.png) Reviewed By: cipolleschi Differential Revision: D37215394 Pulled By: cortinico fbshipit-source-id: 66c4401f7c61b745ea893969d69c8dde3e5afb03

facebook#34014) Summary: This fix solves a problem very well evaluated [here](Expensify/App#2727) as well as this [one](facebook#29290). The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app. I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening: 1. iPad is in landscape. 2. We move the app to inactive state. 3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1). 4. We restore the app to active state. 5. The app receives two queued orientation change events, one after another. 6. The quick transition between portrait and landscape happens even though it never went back to portrait. Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro Video presenting the issue (recorded while working on: Expensify/App#2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4 ## Changelog  [iOS] [Fixed] - Fix the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive Pull Request resolved: facebook#34014 Test Plan: ### Test Preparation 1. Make sure you have a working version of E/App. 2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line: `this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);` to `this.onDimensionChange = this.onDimensionChange.bind(this);` 3. Open the NewExpensify.xcodeproj in xCode. 4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR. 5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode. 6. From this point you can move to the test scenarios described below. ### iPad Mini tests: Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g **Test 1:** 1. Launch app in portrait, open chat - no sidebar visible. 7. Switch to landscape - sidebar shows. 8. Put app to background. 9. Put app back to foreground - make sure the side menu doesn't flicker. **Test 2:** 1. Launch app in portrait, open chat - no sidebar visible. 2. Switch to landscape - sidebar shows. 3. Put app to background. Switch orientation back to portrait. 4. Put app back to foreground - make sure the side menu hides again as it should be in portrait. ### iPad Pro tests: Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg iPad mini test 1 applies. Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always. **Test 3:** 1. launch the app. 2. Make sure you're in landscape mode. 3. See split screen with some other app. Make sure the side bar is visible. 4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it. 10. Move the app to background and back to foreground, please observe there are no flickers. **Test 4:** 1. Launch the app. 2. Make sure you're in landscape mode. 3. Make the multitasking view and make Expensify app a slide over app. 4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly 5. Move the app to background and back to foreground, please observe there are no flickers. ### iPhone: Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk Please perform standard smoke tests on transformation changes. Reviewed By: cipolleschi Differential Revision: D37239891 Pulled By: jacdebug fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf

Summary: Pull Request resolved: facebook#34085 Hermes is now the default engine on iOS. Apps can choose to continue using JSC by setting `hermes_enabled` to `false` in their Podfile. The RNTester app now uses Hermes, as well. Use JSC in RNTester by setting `USE_HERMES=0` when running `pod install`. Changelog: [iOS][Changed] Hermes is now the default engine on iOS. This setting is controlled via `flags[:hermes_enabled]` in the Podfile. Reviewed By: cortinico, cipolleschi Differential Revision: D37361468 fbshipit-source-id: e6dda6a23eea4a824ad157d1a26f17e181db33cd

Summary: Instead of directly scheduling a Runnable on the UI thread, use a GuardedFrameCallback which (1) guards against exceptions thrown on the UI thread (in this case, errors in deferred remove/delete work really should not disrupt the UI at all or cause user-visible crashes) (2) allows us to split work across multiple frames if necessary (3) is more consistent with how we schedule other work on Android. The only functionality change is that we might split work across multiple callbacks, in the case of tearing down a particularly large tree. Changelog: [Internal] Reviewed By: javache Differential Revision: D37470531 fbshipit-source-id: d9d1fc85c29e53addea886db975c0d914581e618

Summary: As title, destroy React Native instance after catching a fatal js error to avoid incoming calls into JS. Changelog: [Android][Changed] - Rename NativeModuleCallExceptionHandler to JSExceptionHandler for broader usage Reviewed By: fkgozali Differential Revision: D37379340 fbshipit-source-id: 465a30bc824a264b45df3e8b0b24edd61c4b571d

Summary: Pull Request resolved: facebook#34083 X-link: facebook/hermes#764 Changelog: [iOS][Added] - Enabled Hermes Intl Reviewed By: cortinico Differential Revision: D37457813 fbshipit-source-id: 717adad317d8620d77f73d1856d25dd4e9d8511c

…lier Summary: Due to the way we're dispatching queued MountItems on Android, we could be doing nothing on the UI thread for up to 15.99...ms before the start of the next frame, resulting in a delayed paint of up to 1 full (16ms) frame. The delay is totally random and depends only on when the work is scheduled. The tl;dr is that currently all MountItems are dispatched starting only at the /beginning/ of a UI frame. If we schedule work at FrameStart+0.000001ms, it will not be operated on until the start of the next frame, 16ms later. So the "wasted" time could be anywhere from 0 to ~16ms, but will result in at least 1 wasted frame regardless. The fix is fairly trivial: start working on large buffered work as soon as we schedule it. Changelog: [Android][Changed] Optimization to paint changes up to 1 frame earlier on Android/Fabric Reviewed By: NickGerleman Differential Revision: D37478885 fbshipit-source-id: 8af846736caf3a9d9f0d0c5e33328bebb87b1b32

Summary: Crashes can occur if we try to disassemble trees not managed by React Native - for example a native component tree, Litho hierarchies, etc. As we disassemble the tree, ensure that children are managed before disassembling a subtree. Changelog: [Internal] Reviewed By: ryancat Differential Revision: D37493854 fbshipit-source-id: fee4d303133edcef663abfe8637bce6b24627724

Summary: Fixes iOS build for React-RCTText with RN 0.69.0, fixes facebook#33976 PR contains changes from facebook#33976 (comment) PoC repo: https://github.com/ph4r05/poc-rn-34064 Related issues: - expo/expo#16283 - facebook#33815 - facebook#33976 ## Changelog  [iOS] [Fixed] - Fix build for React-RCTText Pull Request resolved: facebook#34064 Reviewed By: cortinico Differential Revision: D37420163 Pulled By: cipolleschi fbshipit-source-id: 68a831bce9f449348d13e040a1ba12726a66667d

Summary: Updating changelog for 0.69.1 ## Changelog  [Internal] - Update changelog for 0.69.1 Pull Request resolved: facebook#34097 Reviewed By: cortinico Differential Revision: D37518312 Pulled By: cipolleschi fbshipit-source-id: ba0784c371f0b771fc4f164a29aa24a1e7a46aa8

Summary: Changelog: [internal] Reviewed By: samwgoldman Differential Revision: D37469106 fbshipit-source-id: a28fc3f8a5947bb09a808a4162080c3fe6bfb1f5

Summary: Changelog: [internal] Reviewed By: neildhar, jpporto Differential Revision: D37454445 fbshipit-source-id: 423fa99f91e54ade807a56169204c523ad1f9d20

Summary: Before ``` "If you want to override a property, don't addthe ReactProp annotation to the property in the subclass", ``` After ``` "If you want to override a property, don't add the ReactProp annotation to the property in the subclass", ``` Reviewed By: michaeltangelo Differential Revision: D37526541 fbshipit-source-id: 850424a1b5a5aeb0abe64b6defcf6db96d2000cc

Summary: MSVC doesn't like Clang macros. Oops! Constraints with this bit of code: 1. I'm trying to enforce constexpr in the most obvious, intuitive way possible. Macros are ugly but a "proper" solution would result in 10x as much code that is, totally subjectively, less readable to me. 2. This is evaluating at compile-time a hash of a string which is usually used in the `case` line of a switch statement. For now I'm just hoping that MSVC will allow us to shadow `hash` which Xcode doesn't like. We might need to add a special pragma(s) for MSVC if it still doesn't like this. Changelog: [Internal] Reviewed By: lyahdav Differential Revision: D37529949 fbshipit-source-id: 9aa605a9786bf5d194819ef8dade778875ae744e

Summary: LA needs to ignore the new RemoveDeleteTree mutation coming from the differ. Changelog: [Internal] Reviewed By: jehartzog Differential Revision: D37531217 fbshipit-source-id: c05b4106b6e955083e5e7e93619a13c4a2858404

Summary: During the refactor in D36889794 (facebook@782e004) and later D37050215 (facebook@47280de) this block of code was erroneously deleted; add it back, because if the props iterator setter is disabled, nothing sets this property anymore. Changelog: [Internal] Reviewed By: ryancat, nscoding Differential Revision: D37539700 fbshipit-source-id: 0850180721e0549fed6089cb278402c56eb9d627

Summary: Changelog: [Internal] Reviewed By: evanyeung, SamChou19815 Differential Revision: D37541260 fbshipit-source-id: 8b8cdf72be57ce647b93f86c580becef2f96874c

…(blobs) (facebook#34096) Summary: ```js async () => { let blobs = []; for (let i = 0; i < 4; i++) { const res = await fetch(); blobs = [...blobs, await res.blob()] } const blob = new Blob(blobs); // <<<<<<<<<<<<<<< a return await new Promise((resolve, reject) => { const fileReader = new FileReader(); fileReader.onload = async () => { await RNFS.writeFile(destPath, (fileReader.result as string).split(',')[1], 'base64'); resolve(destPath); }; fileReader.onabort = () => { reject(''); }; fileReader.onerror = (event) => { reject(''); }; fileReader.readAsDataURL(blob); // <<<<<<<<<<<<<<< b }); } ``` Sometime `fileReader.readAsDataURL` is unable to get blob from the dictionary after `new Blob(blobs)` and then reject with `Unable to resolve data for blob: blobId` in iOS or `The specified blob is invalid` in android. Because line `a` and `b` can be run in different thread. `new Blob([])` is in progress and `fileReader.readAsDataURL` accesses the blob dictionary ahead of the blob creation. The expected behaviour is it should finish new Blob([]) first and then readAsDataURL(blob) To fix that, there should be a lock inside the method `createFromParts`. For iOS, It needs to be a recursive_mutex to allow same thread to acquire lock ## Changelog  [iOS] [Fixed] - fix the race condition when calling readAsDataURL after new Blob(blobs) Pull Request resolved: facebook#34096 Reviewed By: cipolleschi Differential Revision: D37514981 Pulled By: javache fbshipit-source-id: 4bf84ece99871276ecaa5aa1849b9145ff44dbf4

Summary: This PR adds a new method called **__apply_mac_catalyst_patches** to **scripts/react_native_pods.rb**. If it is enabled in the Podfile, it will apply three patches necessary for successful building not only for iOS and tvOS targets, but also for macOS using Apple's Mac Catalyst technology. These 3 patches are: - Fixing bundle signing issues by altering CODE_SIGN_IDENTITY - Explicitly setting dead code stripping flag in project.pbxproj - Modifying library search paths The details were discussed here reactwg/react-native-releases#21 (comment) ## Changelog [iOS] [Added] - Add Mac Catalyst compatibility (can be enabled in Podfile) Pull Request resolved: facebook#34026 Test Plan: 1. Go to project settings in Xcode, to General tab. Enable "iPad" and "Mac Catalyst" checkboxes 2. Go to "Signing & Capabilities" tab, ensure that a correct bundle id and development team are set 3. Edit Podfile, uncomment **__apply_mac_catalyst_patches(installer)** line 4. Run `pod install` in ios directory 5. Get back to Xcode, select "My Mac (Mac Catalyst)" as a target device 6. Build & run Reviewed By: cipolleschi Differential Revision: D37362054 Pulled By: cortinico fbshipit-source-id: 74636f716f112289ab40968bbc8e52406c1e9579

Summary: The initial version of this would result in LayoutAnimations running potentially much faster than 60FPS (incorrectly). Resolve by calling tryDispatchMountItems directly instead of the frame callback runner. Changelog: [Internal] Reviewed By: javache Differential Revision: D37543693 fbshipit-source-id: 91dbd961ecc155221c84148cb6b252a4aac9ec91

Summary: **Feature** Support pre-computing the dependency **Fixes** Wrongly loaded directApkLdPath(facebook/SoLoader#104) SoLoader causes crashes on migration to an Android 12 device(facebook/SoLoader#100, facebook/SoLoader#88 ) Fix race condition in SoLoader#init(facebook/SoLoader#99) **Full Changelog**: facebook/SoLoader@v0.10.3...v0.10.4 Reviewed By: charles011 Differential Revision: D37525875 fbshipit-source-id: a64e4021012128fe4a78d3ec9e955dae2ae35926

…he hierarchy are re-added to hierarchy Summary: There is a very small volume of production errors caused by a View that is already in the hierarchy being added to the hierarchy again; this results in a crash on the Android platform layer. We detect and attempt to silently recover from this case, while logging and collecting more diagnostics. This will still crash in debug mode. It is unclear what layer this error is coming from: it could be an issue with the C++ differ (ordering, or something more tricky); that is unlikely but there are few other hypotheses at the moment. Changelog: [Internal] Reviewed By: javache Differential Revision: D37557663 fbshipit-source-id: ffe320ff646e314fa921a2c2cf8058254713505c

Reviewed By: IanChilds Differential Revision: D37530941 fbshipit-source-id: ea545a241600edc7f01458be264734db41caaa7d

Summary: Changelog: [Internal] - Make the new architecture validation easier to understand by enabling validation with `RCTNewArchitectureSetMinValidationLevel(level)`. - When `RCT_ONLY_NEW_ARCHITECTURE` flag is enabled: - `RCTErrorNewArchitectureValidation` calls `RCTLogAssert` instead of `RCTLogError`. - `RCTNewArchitectureValidationPlaceholder` calls `RCTLog`, instead of no-op. Reviewed By: fkgozali Differential Revision: D37555667 fbshipit-source-id: 2c725c287a2dec19e8946c7fe5d8fa111e4a17fa

Summary: Changelog: [Interna] Reviewed By: fkgozali Differential Revision: D37573895 fbshipit-source-id: 840995c68e84e86260a07a5f771f7019a62e9759

Summary: Upgrade React Native's direct dependencies on Metro packages from 0.71.1 to 0.71.2. Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.2 Changelog: [General] Update direct Metro dependencies to 0.71.2 Reviewed By: jacdebug Differential Revision: D37593257 fbshipit-source-id: f56db766a6c63b74ab9feab31a9d7a1f50c5af23

Summary: This PR adds minimum token permissions for the GITHUB_TOKEN using https://github.com/step-security/secure-workflows. GitHub recommends defining minimum GITHUB_TOKEN permissions for securing GitHub Actions workflows - https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ - https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token - The Open Source Security Foundation (OpenSSF) [Scorecards](https://github.com/ossf/scorecard) treats not setting token permissions as a high-risk issue This project is part of the top 100 critical projects as per OpenSSF (https://github.com/ossf/wg-securing-critical-projects), so fixing the token permissions to improve security. Signed-off-by: Varun Sharma <varunsh@stepsecurity.io> ## Changelog [General] [Security] - Add GitHub token permissions for workflows  Pull Request resolved: facebook#34122 Test Plan: N/A Reviewed By: cipolleschi Differential Revision: D37597988 Pulled By: cortinico fbshipit-source-id: 2f45914e2202a7b5bf7fa60b019dd12cdcf31952

Summary: If you don't list `Cxx` as a supported platform, we will use Android builds, even when using `buck run` for local execution. Changelog: [Internal] Reviewed By: derolf Differential Revision: D37600464 fbshipit-source-id: 6ba8566cde4180524351c9d8c647ce1d4ac5279d

Summary: Changelog: [RNTester][Internal] - Add the ability to filter PlatformTest results by test name substrings In certain tests (such as the hoverable pointer attributes test) there are a super large number of results which can make it hard to focus on the ones you're actively trying to work on fixing. This diff adds the ability to filter those results with a simple substring filter on the test name of the results. Reviewed By: lunaleaps Differential Revision: D37558411 fbshipit-source-id: 8f4b19fed9bb9f1b08fd7470cd79d68b6c721c13

Summary: Changelog: [Internal] - Adding offsetX, offsetY to MouseEvent interface. It's currently provided in a draft form: https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface Reviewed By: vincentriemer Differential Revision: D37436051 fbshipit-source-id: b3bb85acb82db348d3e1085881232e5358674ed7

Summary: After D37553813, there are no more TV apps in `fbsource`. Thus, we can begin the sequential teardown of all of the `APPLETVOS` variants in the codebase, which should migrating to `select()` and buck parse times a bit faster. #nocancel Reviewed By: natestedman Differential Revision: D37594789 fbshipit-source-id: 830e40266654f948f39f5d10c32a080e970cf9d7

Summary: Internal tests are indicating that there's an OOM that happens during the RemoveDeleteTree worker loop while trying to expand the size of the tag stack. In practice during manual testing I was not able to get the capacity beyond 40, but for deletions of very large trees, it's easy to imagine the size of the stack growing to at least the number of nodes in the tree being deleted. To mitigate this, we relax our requirements around the order in which onViewStateDeleted can be called and call it top-down instead of bottom up to maintain a smaller stack (see comments for more details). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D37619259 fbshipit-source-id: 8f7af0137a868606a72fdc7bdca13c5e89b69573

Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them. Reviewed By: vincentriemer Differential Revision: D37545813 fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71

Summary: Changelog: [Internal] Allow for MotionEvents to indicate whether they are dispatched from an input device that supports hoverability Reviewed By: javache Differential Revision: D37543296 fbshipit-source-id: 4f70d2bf69ff1c563d8e4a6b5eb6b13b53996b9a

Summary: Pull Request resolved: facebook#34142 The `||=` operator in an expression like `x = a ||= b` works in a way that: - if a is null, it assigns b to x - if a is `falsy`, it assigns b to x - otherwise, it assigns a to x. In our setup, if the user set `hermes_enabled` to `false` in the Podfile (one of the suggested way to disabled Hermes), the `options[:hermes_enabled]` part will evaluate to false and, therefore, `hermes_enabled` will obtain the value of `true`. ## Changelog [iOS][Changed] - Use the correct operator to decide whether Hermes is enabled or not. Reviewed By: cortinico Differential Revision: D37643845 fbshipit-source-id: 387f7bd642250c40873400d22d7d85451462c073

Reviewed By: IanChilds Differential Revision: D37594044 fbshipit-source-id: 0bbcaaed951a212651d3cc0fc3371751ced13852

Summary: Upgrade React Native's direct dependencies on Metro packages from 0.71.2 to 0.71.3 Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.3 Changelog: [General] Update direct Metro dependencies to 0.71.3 Reviewed By: robhogan Differential Revision: D37647746 fbshipit-source-id: cb798c2c0d0d763ce5dd2af48f3877fab8e9fc0d

…ok#34134) Summary: `react-native@0.69` bumped minimum iOS version to 12.4. This change aligns the readme requirements section. Changelog: [General] [Changed] - Doc: fix minimum iOS version in requirements section Pull Request resolved: facebook#34134 Reviewed By: cortinico Differential Revision: D37656176 Pulled By: philIip fbshipit-source-id: 017147140340b4ccb6d8c4ff2eb50220fbdba22c

…w is not mounted Summary: This diff fixed a NPE in horizontal scroll view when calling scrollToEnd API in side effect. The problem here is we may trigger side-effects before the required view got mounted for performance reasons. We've been fixing this with retry logic on those side-effects and we've already done this in vertical scroll view. This is to fix on the horizontal scroll as well. Changelog: [Android][Fixed] - Fixed HorizontalScrollView API scrollToEnd causing NPE in side-effects. Reviewed By: lunaleaps, JoshuaGross Differential Revision: D37571847 fbshipit-source-id: 0a4dc38381008350fd09908aa3ebb64e3e65a424

Summary: Changelog: [Internal] Add `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInAppWideFabric)` to track RCTViewManagers used in Fabric using the legacy interop layer. They work for now in the interop layer, but they need to be migrated to Fabric to remove potential issues with using the legacy architecture and the new architecture simultaneously. RCTNewArchitectureValidationPlaceholder is a no-op used for tracking unmigrated callsites that may be used often. `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless. This diff adds the validation placeholder to legacy components registered in [RCTLegacyViewManagerInteropComponentView.mm](https://github.com/facebook/react-native/blob/743d0706e2099514b4603855bfc2b6505fcc10a5/React/Fabric/Mounting/ComponentViews/LegacyViewManagerInterop/RCTLegacyViewManagerInteropComponentView.mm#L92-L99). Reviewed By: fkgozali Differential Revision: D37635613 fbshipit-source-id: 5399dad822c8f5c11ef3b32297bf25214fd857dd

Summary: This component was unused (internal only), no callsite --> deleting. Changelog: [Internal] Reviewed By: RSNara Differential Revision: D37670499 fbshipit-source-id: df3105dbd5ba9c8ef4d4e69e024fc8ebe6c6ed5f

Summary: This diffs replaces uses of the deprecated fields from HermesInternal.getInstrumentedStats() with the ones from Hermes' TimedRuntime. Changelog: [General][Added] - JSITimerInternal descriptor Reviewed By: rubennorte Differential Revision: D36625701 fbshipit-source-id: fbdb554e5cfb0b3556fcbe01f9e2930ace66a619

Summary: These changes are a side-effect of a Meta-internal Buck macro change. This does not affect how RNTester is built in open source. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D37648363 fbshipit-source-id: 6fd5d56a7a7a9ea71dc3d0df91e510fcd45a1e17

Summary: Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D37700466 fbshipit-source-id: 66b9a032268daa0d5c27d74bf1c11cd290d1412c

Reviewed By: samwgoldman Differential Revision: D37701888 fbshipit-source-id: 80cf21e4c942f00695c08ea8671efba0109aad32

Summary: Pull Request resolved: facebook#34100 This Diff continue the effort of refactor and test the cocoapods script, moving hermes setup in a dedicated `hermes.rb` file and adding some tests on the logic of the hermes handling. ## Changelog [iOS][Changed] - move and test Hermes setup from react_native_pods script into a dedicated file Reviewed By: cortinico Differential Revision: D37522432 fbshipit-source-id: 91112476aac576a30110e5dcd4e46fa12241962a

Summary: Changelog: [Internal] Reviewed By: MartinSherburn Differential Revision: D37600540 fbshipit-source-id: 40cf30ec2960864fc862c31661b1308c57f33bec

Summary: Adds a jsi::BigInt skeleton. Changelog: [General][Added] jsi::BigInt Reviewed By: kodafb Differential Revision: D35706101 fbshipit-source-id: 435b108050279ff30953b3e209cdc2f0ff84f40b

Summary: Changelog: [Internal] - Clean up duplicate properties from pointer event rename Reviewed By: javache Differential Revision: D37662527 fbshipit-source-id: f310d16103f12cdfe4e02546ea156553c9cd5443

Summary: Changelog: [Internal] - If any relevant view events (pointer, touch events, gesture responder, etc.) are declared on view, then the view must form stacking context. We need this change for pointer events specifically to determine whether we've entered/exited a view Reviewed By: vincentriemer Differential Revision: D37678352 fbshipit-source-id: 02641549ef608b1c9468ac693c7da629143212cb

Summary: Changelog: [RNTester][Internal] Update event names in pointer event platform tests Reviewed By: lunaleaps Differential Revision: D37697922 fbshipit-source-id: ac0ad5111cc7be74ca4ad4a2e9e6c2dec15b49ce

Summary: Changelog: [iOS][Internal] - Add `buttons` implementation to the PointerEvent interface This diff adds an implementation of the `buttons` property by leveraging `UIEvent`'s `buttonMask` property. Reviewed By: lunaleaps Differential Revision: D37430270 fbshipit-source-id: 69fd3aebcb403e665349a24283a04c0eb82ff3e2

Summary: Changelog: [RNTester][Internal] - Add README for RNTesterPlatformTest framework This diff adds some initial documentation for `RNTesterPlatformTest` to give other pointers on how to contribute their own platform tests (both internally and externally). Reviewed By: lunaleaps Differential Revision: D37566632 fbshipit-source-id: c203045f79c3c5488fd0dcbb8077e9041bd62b0f

Summary: Changelog: [RNTester][Internal] - Create more mobile-friendly version of the platform test results UI The original UI design for displaying the test results was done with only really tablets in mind so in order to better accomidate mobile screen sizes this diff adds a new expanding UI for the test results. Reviewed By: lunaleaps Differential Revision: D37701638 fbshipit-source-id: a1789abb15db7ab162fe90afc32d23c435f1bdb5

…thoutLegacy Summary: Changelog: [Internal][iOS] Minor: Rename RCTNotAllowedInAppWideFabric to RCTNotAllowedInFabricWithoutLegacy `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless. `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInFabricWithoutLegacy` is to track legacy APIs that should not exist if the app was using Fabric **without any legacy architecture**. e.g. RCTBridgeModule, legacy interop view components. Reviewed By: fkgozali Differential Revision: D37659105 fbshipit-source-id: aee4e083820e83a8dac19eb3b5efc49b37d90039

Reviewed By: nlutsenko Differential Revision: D37734621 fbshipit-source-id: 3b24121c0926f4d8fcd1cdb8433cc89a3452eb20

Summary: This component is no longer relevant. Changelog: [Internal] Reviewed By: philIip Differential Revision: D37733807 fbshipit-source-id: 267d69e5ffbb9bf9281f715b3e4e07c1f2f7ca9a

…teropComponentView Summary: Changelog: [Internal][iOS] Reviewed By: fkgozali Differential Revision: D37733640 fbshipit-source-id: cb447ceba2a43fdd9808c80c54af99ff4d31305b

Summary: This error message doesn't format correctly when outputted to the terminal. It seems the 2nd line is missing ## Changelog  [iOS] [Fixed] - bug with error message formatting when bundle is missing Pull Request resolved: facebook#31338 Test Plan: Before: ![wHHXtKq](https://user-images.githubusercontent.com/4398635/114310176-f11f8700-9ab7-11eb-9de7-b80aab92d440.png) After: ![6nIjRHc](https://user-images.githubusercontent.com/4398635/114310470-d6014700-9ab8-11eb-9164-d6edde95c6f8.png) Reviewed By: cipolleschi, sota000 Differential Revision: D30912237 Pulled By: cortinico fbshipit-source-id: 68a4b29cdd93cbde7ba4611c5e38775561b73ea2

Summary: Upgrades the React Native CLI to v9.0.0-alpha.3 with autolinking adjustments from cortinico ## Changelog [General] [Changed] - Upgrade RN CLI to v9.0.0-alpha.3 Pull Request resolved: facebook#34160 Test Plan: CI Reviewed By: cortinico, cipolleschi Differential Revision: D37714146 Pulled By: GijsWeterings fbshipit-source-id: 03854003fbf82e10e5f8096dbdfe876b173e6da6

Summary: Pull Request resolved: facebook#34171 Changelog: [General][Added] - Added files for `avn`, `nodenv`, and other managers that set the node.js version in reactive native project including testing Reviewed By: cortinico Differential Revision: D37683291 fbshipit-source-id: ef0df0fb07f5cc0fa3591dde487f65e4b1b5f73f

Summary: Subclassing a ViewManager means an additional PropsSetter class is generated (and other overheads). Instead we can use a Factory/Provider to construct ReactTextViewManager, since we don't actually need a subclass. Changelog: [Internal] Reviewed By: rshest Differential Revision: D36411098 fbshipit-source-id: 11c5ba5c9683a3ae4741cf61338f1983c69d9b69

Summary: Ahead of enabling the `exact_empty_objects` option, suppress errors so that actually enabling the option is easier. We can do this without enabling the option by codemoding `{}` to `{...null}` in files that have errors. Process: 1) Get list of files with errors when enabling the option 2) Codemod `{}` to `{...null}` in those files 3) Suppress resulting errors 4) Land diff with `drop-conflicts` flag 5) Announce and enable option (with many fewer files to edit) 6) Codemod all `{...null}` to `{}` drop-conflicts We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed. More info in these posts: https://fb.workplace.com/groups/flowlang/posts/903386663600331, https://fb.workplace.com/groups/floweng/posts/8626146484100557 Reviewed By: pieterv Differential Revision: D37731004 fbshipit-source-id: a9305859ba4e8adbdb8ae8feff3ec8a2f07ed236

Reviewed By: strulovich Differential Revision: D37772421 fbshipit-source-id: 2c797653531e7963c08a21fc6bb6b0b5480a184a

Summary: - Fix: facebook#34103 - Follow-up: facebook#33817 ## Changelog  [Android] [Changed] - Bump Android Gradle Plugin to 7.2.1 Pull Request resolved: facebook#34166 Test Plan: Everything builds and runs as expected Reviewed By: javache Differential Revision: D37747754 Pulled By: cortinico fbshipit-source-id: b51f26d773ddfbdaf4490f89f3b207a41b225a82

Summary: Fix todo and inconsistency across codebase. It's better to have just one way to refer to these types. Changelog: [Internal] Reviewed By: philIip Differential Revision: D37653146 fbshipit-source-id: e82f09caa6cd6eec5512b78f413708d9c04a7a83

…acebook#34161) Summary: Pull Request resolved: facebook#34161 This is a follow up to D37648363 (facebook@64fe676) which breaks up `TestBundle.js` into two modules. This enables `TestApps.js` (which defines and exports the set of integration test apps) to be required in the Meta-specific dependency graph without violating our internal naming pattern for JS entry points. `force_include_bundles` is removed from the `js_glob` macro signature. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D37686883 fbshipit-source-id: 492c13dfcdd76ea8347d4d11c85818e31777c663

Summary: Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D37686882 fbshipit-source-id: 467575fa0effaf67524b2c56e65519c32ec6dbd9

Summary: Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D37717611 fbshipit-source-id: 77ddfb43bb8e9fef4306b6e701d34c4964549730

…acebook#34121) Summary: Before this change, during the "Start Packager" Xcode build step that runs the packager, `packager.sh` was using my system node version and not the one from `nvm` that is meant to be used with the project. ## Changelog [iOS] [Fixed] - Use `NODE_BINARY` from `.xcode.env` when running packager from Xcode Pull Request resolved: facebook#34121 Test Plan: Perform a build using Xcode and confirm that the packager is using the correct version of node. Reviewed By: cortinico Differential Revision: D37746951 Pulled By: cipolleschi fbshipit-source-id: de697c27fe86ce65e8e3646cb30309ecc7f6c247

Summary: This change replaces the text in `ColorStylesExample` with two different spans of nested text, which requires special attention with the native driver. Changelog: [Internal][Added] - Add Nested Text Animated Color RNTester Example Reviewed By: genkikondo Differential Revision: D37762708 fbshipit-source-id: 755e6dd922432781645cd84749a77f29ec57665d

Summary: Changelog: [iOS][internal] - Add tangentialPressure property to PointerEvent interface This diff adds the tangentialPressure property to the PointerEvent implementation on iOS. This one is pretty simple considering iOS doesn't have the concept of tangential pressure so we just hard code it to 0 as defined by the spec. Reviewed By: lunaleaps Differential Revision: D37759634 fbshipit-source-id: 7ca0e47267f5fde76ace2b96d05ea2e154cb4b8f

Summary: Changelog: [iOS][internal] - Add twist property to PointerEvent interface This adds the twist property to the PointerEvent implementation on iOS which similarly to tangentialPressure doesn't really apply so we default to a hard-coded value of 0. Reviewed By: lunaleaps Differential Revision: D37760511 fbshipit-source-id: f1fccfd6b5d07024cea83d86925a9bfc2e6cc8cf

Summary: Changelog: [RNTester][Internal] - Fix layout measurement in hoverable pointer attributes test This diff addresses an issue I've found with the hoverable pointer attributes test where before it was measuring the view seemingly on mount and it appears that for *some reason* that would be incorrect on the first mount of the view. This diff ensures that doesn't happen by measuring the view JIT when an event is recieved instead. Reviewed By: lunaleaps Differential Revision: D37765614 fbshipit-source-id: 8594677d98be8d3d4e75dbf5394c92ca49355d6d

Summary: Changelog: [iOS][Internal] - add x/y & pageX/Y implementations to PointerEvent interface This diff adds the x/y properties, which are defined as aliases of clientX/clientY respectively. In addition this diff adds pageX/pageY which, while not definted as aliases of clientX/clientY, are effectively aliases in React Native since the root view is not scrollable (client and page points only differ on the web when a user has scrolled the document element). Reviewed By: lunaleaps Differential Revision: D37766818 fbshipit-source-id: c7ad3750460b1913889c6d1a55b4c1edc6918f5b

Summary: The new props parsing path (introduced in https://www.internalfb.com/diff/D37051020 (facebook@af1eae9)) resulted in opacity and backgroundColor being applied twice. Specifically, the new prop setter path basically results in the ParagraphProps' textAttributes (via ConcreteComponentDescriptor.cloneProps, via ParagraphProps.setProp) to include opacity and backgroundColor, which is not desired as they are both applied again on view. Similar issue faced in the past: https://www.internalfb.com/diff/D19764144 (facebook@8fe6883) Changelog: [Internal] - Prevent double application of opacity and backgroundColor on text Reviewed By: ryancat Differential Revision: D37801663 fbshipit-source-id: 4b5ebe5ff20b80833edb2141df883f33c69ab5d6

Summary: Similarly to D37653146 (facebook@13a0556), standardize on one type to refer to this. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D37658743 fbshipit-source-id: 9834cfc4bbe4ca1a19f10c2c8718e3f74b88d9b6

Summary: Pull Request resolved: facebook#34185 Bumping React Native Codegen & Gradle plugin to prepare for the release of React Native 0.70 Changelog: [General] [Changed] - Bump dependencies before 0.70 branch cut Reviewed By: dmitryrykun Differential Revision: D37818496 fbshipit-source-id: 12b3f1af29d314c9acf270ca4dfb4c007a400076

Summary: The RN Hermes Inspector keeps a mapping of pageId to Connection. This mapping is created in the call to enableDebugging. Later, when disableDebugging is invoked, the inspector will iterate over the pageId to Connection map to find which page to is being disabled. The DecoratedRuntime enables debugging on construction, and disables on destruction. When disabling debugging, the DecoratedRuntime then passes the "naked" hermesRuntime, which in turn gets checked against all connections' runtimes. It turns our that ```HermesExecutorRuntimeAdapter::getRuntime``` returns the runtime **wrapped** by the DecoratedRuntime, and not hermesRuntime itself. This means that no connections match the request for disabling debugging. Which means the Connection never gets deleted, which in turns keep its underlying adapter (in this case, the ```HermesRuntimeExecutorAdapter```) alive, which has a shared_ptr to the runtime wrapped by the DecoratedRuntime. Other than effectively leaking this connection (and thus the runtime), this also causes an issue when the app tries to re-load the page -- at which point the inspector will remove the old entry from the page to connection mapping, thus initiating the destruction of the (leaked) Runtime in a thread other than the thread that created the runtime. Changelog: [Internal] Reviewed By: javache Differential Revision: D37809467 fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24

Summary: Changelog: [Internal] Provide Android backing for offsetX, offsetY values. Reviewed By: javache Differential Revision: D37734498 fbshipit-source-id: f0f6daea3a2da27c79d42b9546eafa757ec448e7

Summary: Changelog: [Internal] - Add support for legacy event emitter for PointerEvents because it's used by natively driven Animated events It works by * [NativeAnimatedNodesManager being a listener on every event dispatched](https://www.internalfb.com/code/fbsource/[b8fc8603f8d84003bcb73ec84e8490c136df290c]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/events/EventDispatcherImpl.java?lines=115-117) * NativeAnimatedNodesManager [re-dispatching the event onto an EventAnimationDriver to update the animated value.](https://www.internalfb.com/code/fbsource/[d5403bc1fa55a68d9346ac693378551b734c565b]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/animated/NativeAnimatedNodesManager.java?lines=597) As such, we need to make sure to implement the legacy event dispatch function. Reviewed By: vincentriemer Differential Revision: D37769785 fbshipit-source-id: c570896afc624193fdb636a302e9613ca6fee14d

Summary: Changelog: [Internal] - Add an example of pointermove using AnimatedEvent Reviewed By: vincentriemer Differential Revision: D37769263 fbshipit-source-id: 25de0ae88b55148d23fa388768707ea859e9ae4d

…ok#34183) Summary: Turbo module codegen supports arrays in both Flow and TypeScript, but it only recognize `Array<T>` and `ReadonlyArray<T>` in TypeScript. In this change, `T[]` and `readonly T[]` are made recognizable in codegen. ## Changelog [General] [Added] - Support TypeScript array types for turbo module (module only) Pull Request resolved: facebook#34183 Test Plan: `yarn jest` passed in `packages/react-native-codegen` Reviewed By: lunaleaps Differential Revision: D37812638 Pulled By: cipolleschi fbshipit-source-id: d63b0585497a43c274d50e1877baab5d1cc3f8fa

…`defaultValue` Summary: A layout-impacting style change will trigger a layout effect hook within `TextInput`. This hook fires a ViewManager command to set the text input based on the known JS value: https://github.com/facebook/react-native/blob/d82cd3cbce1597512bb2868fde49b5b3850892a0/Libraries/Components/TextInput/TextInput.js#L1009 The JS value is determined using `value` if set, falling back to `defaultValue`. If a component uses `TextInput` as an uncontrolled component, and does not set this value, the command wipes text input back to the default value. This does not happen on re-render of the JS side, despite setting text prop, since the underlying native property never changes/triggers a rerender. This change alters the logic to prefer `lastNativeText` instead of `defaultValue` when available, to retain the updated `TextInput` content on relayout. Reviewed By: javache Differential Revision: D37801394 fbshipit-source-id: d56c719d56bebac64553c731ce9fca8efc7feae9

Summary: The empty object literal `{}` now has the type `{}` - i.e. an exact empty object - rather than being unsealed. Enable the option in the github flowconfigs Changelog: [Internal] Reviewed By: pieterv Differential Revision: D37836634 fbshipit-source-id: 8ef0cfaf1d0420ae71723e04163f00c43c550e07

Summary: Changelog: [iOS][Internal] - Implement screenX/screenY properties on the PointerEvent interface This diff implements the screenX/screenY properties which report the position of a pointer in the device's physical screen coordinates. Reviewed By: lunaleaps Differential Revision: D37794415 fbshipit-source-id: 6c39c3651812f99e66b93647579a2935598ef6f2

Summary: Changelog: [general][change] - Use RuntimeConfig instead of VM Experiment Flag to set up the micro task queue. Reviewed By: neildhar Differential Revision: D37353947 fbshipit-source-id: 5c8f35c0a79d70cb0d234e881e55058cffb44ac8

Summary: This cleans up a bit our dependency list inside `ReactAndroid`. I've re-sorted the lists, and exported everything I could in the `gradle.properties`. I wish we could move to the Gradle Version Catalog for Android, but that's not possible at the moment (it will make impossible for users to build from source). ## Changelog [Internal] - Cleanup some of the dependencies inside ReactAndroid Pull Request resolved: facebook#34191 Test Plan: Will rely on a Green CircleCI Reviewed By: huntie Differential Revision: D37828614 Pulled By: cortinico fbshipit-source-id: f433d08d691db4145e0c72ca4dab2f0350e4101f

Summary: Currently `react-native-codegen` uses `prepublish` to pre-build before publishing. Moving to `prepare` as `prepublish` is deprecated and not invoked anymore: https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts ## Changelog [Internal][Fixed] - [codegen] Update script from prepublish (deprecated) to prepack Pull Request resolved: facebook#34198 Test Plan: Tested locally with: ``` cd packages/react-native-codegen/ && rm -rf lib && npm publish --dry-run --foreground-scripts ``` output is: ``` > react-native-codegen@0.70.1 prepare > yarn run build yarn run v1.22.18 $ yarn clean && node scripts/build.js --verbose $ rm -rf lib react-native-codegen........................................................... • src/__tests__/__snapshots__/SchemaValidator-test.js.snap (ignore) • src/__tests__/SchemaValidator-test.js (ignore) • src/cli/combine/combine-js-to-schema-cli.js ⇒ lib/cli/combine/combine-js-to-schema-cli.js • src/cli/combine/combine-js-to-schema.js ⇒ lib/cli/combine/combine-js-to-schema.js • src/cli/generators/generate-all.js ⇒ lib/cli/generators/generate-all.js • src/cli/parser/parser-cli.js ⇒ lib/cli/parser/parser-cli.js • src/cli/parser/parser.js ⇒ lib/cli/parser/parser.js • src/cli/parser/parser.sh ⇒ lib/cli/parser/parser.sh (copy) • src/CodegenSchema.js ⇒ lib/CodegenSchema.js • src/generators/__test_fixtures__/fixtures.js ⇒ lib/generators/__test_fixtures__/fixtures.js • src/generators/__tests__/RNCodegen-test.js (ignore) • src/generators/components/__test_fixtures__/fixtures.js ⇒ lib/generators/components/__test_fixtures__/fixtures.js • src/generators/components/__tests__/__snapshots__/GenerateComponentDescriptorH-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateComponentHObjCpp-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateEventEmitterCpp-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateEventEmitterH-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GeneratePropsCpp-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GeneratePropsH-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GeneratePropsJavaDelegate-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GeneratePropsJavaInterface-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GeneratePropsJavaPojo-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateShadowNodeCpp-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateShadowNodeH-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateTests-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateThirdPartyFabricComponentsProviderH-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateThirdPartyFabricComponentsProviderObjCpp-test.js.snap (ignore) • src/generators/components/__tests__/__snapshots__/GenerateViewConfigJs-test.js.snap (ignore) • src/generators/components/__tests__/GenerateComponentDescriptorH-test.js (ignore) • src/generators/components/__tests__/GenerateComponentHObjCpp-test.js (ignore) • src/generators/components/__tests__/GenerateEventEmitterCpp-test.js (ignore) • src/generators/components/__tests__/GenerateEventEmitterH-test.js (ignore) • src/generators/components/__tests__/GeneratePropsCpp-test.js (ignore) • src/generators/components/__tests__/GeneratePropsH-test.js (ignore) • src/generators/components/__tests__/GeneratePropsJavaDelegate-test.js (ignore) • src/generators/components/__tests__/GeneratePropsJavaInterface-test.js (ignore) • src/generators/components/__tests__/GeneratePropsJavaPojo-test.js (ignore) • src/generators/components/__tests__/GenerateShadowNodeCpp-test.js (ignore) • src/generators/components/__tests__/GenerateShadowNodeH-test.js (ignore) • src/generators/components/__tests__/GenerateTests-test.js (ignore) • src/generators/components/__tests__/GenerateThirdPartyFabricComponentsProviderH-test.js (ignore) • src/generators/components/__tests__/GenerateThirdPartyFabricComponentsProviderObjCpp-test.js (ignore) • src/generators/components/__tests__/GenerateViewConfigJs-test.js (ignore) • src/generators/components/CppHelpers.js ⇒ lib/generators/components/CppHelpers.js • src/generators/components/GenerateComponentDescriptorH.js ⇒ lib/generators/components/GenerateComponentDescriptorH.js • src/generators/components/GenerateComponentHObjCpp.js ⇒ lib/generators/components/GenerateComponentHObjCpp.js • src/generators/components/GenerateEventEmitterCpp.js ⇒ lib/generators/components/GenerateEventEmitterCpp.js • src/generators/components/GenerateEventEmitterH.js ⇒ lib/generators/components/GenerateEventEmitterH.js • src/generators/components/GeneratePropsCpp.js ⇒ lib/generators/components/GeneratePropsCpp.js • src/generators/components/GeneratePropsH.js ⇒ lib/generators/components/GeneratePropsH.js • src/generators/components/GeneratePropsJavaDelegate.js ⇒ lib/generators/components/GeneratePropsJavaDelegate.js • src/generators/components/GeneratePropsJavaInterface.js ⇒ lib/generators/components/GeneratePropsJavaInterface.js • src/generators/components/GeneratePropsJavaPojo/index.js ⇒ lib/generators/components/GeneratePropsJavaPojo/index.js • src/generators/components/GeneratePropsJavaPojo/PojoCollector.js ⇒ lib/generators/components/GeneratePropsJavaPojo/PojoCollector.js • src/generators/components/GeneratePropsJavaPojo/serializePojo.js ⇒ lib/generators/components/GeneratePropsJavaPojo/serializePojo.js • src/generators/components/GenerateShadowNodeCpp.js ⇒ lib/generators/components/GenerateShadowNodeCpp.js • src/generators/components/GenerateShadowNodeH.js ⇒ lib/generators/components/GenerateShadowNodeH.js • src/generators/components/GenerateTests.js ⇒ lib/generators/components/GenerateTests.js • src/generators/components/GenerateThirdPartyFabricComponentsProviderH.js ⇒ lib/generators/components/GenerateThirdPartyFabricComponentsProviderH.js • src/generators/components/GenerateThirdPartyFabricComponentsProviderObjCpp.js ⇒ lib/generators/components/GenerateThirdPartyFabricComponentsProviderObjCpp.js • src/generators/components/GenerateViewConfigJs.js ⇒ lib/generators/components/GenerateViewConfigJs.js • src/generators/components/JavaHelpers.js ⇒ lib/generators/components/JavaHelpers.js • src/generators/modules/__test_fixtures__/fixtures.js ⇒ lib/generators/modules/__test_fixtures__/fixtures.js • src/generators/modules/__tests__/__snapshots__/GenerateModuleCpp-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleH-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleHObjCpp-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleJavaSpec-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleJniCpp-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleJniH-test.js.snap (ignore) • src/generators/modules/__tests__/__snapshots__/GenerateModuleMm-test.js.snap (ignore) • src/generators/modules/__tests__/GenerateModuleCpp-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleH-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleHObjCpp-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleJavaSpec-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleJniCpp-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleJniH-test.js (ignore) • src/generators/modules/__tests__/GenerateModuleMm-test.js (ignore) • src/generators/modules/GenerateModuleCpp.js ⇒ lib/generators/modules/GenerateModuleCpp.js • src/generators/modules/GenerateModuleH.js ⇒ lib/generators/modules/GenerateModuleH.js • src/generators/modules/GenerateModuleJavaSpec.js ⇒ lib/generators/modules/GenerateModuleJavaSpec.js • src/generators/modules/GenerateModuleJniCpp.js ⇒ lib/generators/modules/GenerateModuleJniCpp.js • src/generators/modules/GenerateModuleJniH.js ⇒ lib/generators/modules/GenerateModuleJniH.js • src/generators/modules/GenerateModuleObjCpp/header/serializeConstantsStruct.js ⇒ lib/generators/modules/GenerateModuleObjCpp/header/serializeConstantsStruct.js • src/generators/modules/GenerateModuleObjCpp/header/serializeRegularStruct.js ⇒ lib/generators/modules/GenerateModuleObjCpp/header/serializeRegularStruct.js • src/generators/modules/GenerateModuleObjCpp/header/serializeStruct.js ⇒ lib/generators/modules/GenerateModuleObjCpp/header/serializeStruct.js • src/generators/modules/GenerateModuleObjCpp/index.js ⇒ lib/generators/modules/GenerateModuleObjCpp/index.js • src/generators/modules/GenerateModuleObjCpp/serializeMethod.js ⇒ lib/generators/modules/GenerateModuleObjCpp/serializeMethod.js • src/generators/modules/GenerateModuleObjCpp/source/serializeModule.js ⇒ lib/generators/modules/GenerateModuleObjCpp/source/serializeModule.js • src/generators/modules/GenerateModuleObjCpp/StructCollector.js ⇒ lib/generators/modules/GenerateModuleObjCpp/StructCollector.js • src/generators/modules/GenerateModuleObjCpp/Utils.js ⇒ lib/generators/modules/GenerateModuleObjCpp/Utils.js • src/generators/modules/Utils.js ⇒ lib/generators/modules/Utils.js • src/generators/RNCodegen.js ⇒ lib/generators/RNCodegen.js • src/generators/Utils.js ⇒ lib/generators/Utils.js • src/parsers/flow/components/__test_fixtures__/failures.js ⇒ lib/parsers/flow/components/__test_fixtures__/failures.js • src/parsers/flow/components/__test_fixtures__/fixtures.js ⇒ lib/parsers/flow/components/__test_fixtures__/fixtures.js • src/parsers/flow/components/__tests__/__snapshots__/component-parser-test.js.snap (ignore) • src/parsers/flow/components/__tests__/component-parser-test.js (ignore) • src/parsers/flow/components/commands.js ⇒ lib/parsers/flow/components/commands.js • src/parsers/flow/components/events.js ⇒ lib/parsers/flow/components/events.js • src/parsers/flow/components/extends.js ⇒ lib/parsers/flow/components/extends.js • src/parsers/flow/components/index.js ⇒ lib/parsers/flow/components/index.js • src/parsers/flow/components/options.js ⇒ lib/parsers/flow/components/options.js • src/parsers/flow/components/props.js ⇒ lib/parsers/flow/components/props.js • src/parsers/flow/components/schema.js ⇒ lib/parsers/flow/components/schema.js • src/parsers/flow/errors.js ⇒ lib/parsers/flow/errors.js • src/parsers/flow/index.js ⇒ lib/parsers/flow/index.js • src/parsers/flow/modules/__test_fixtures__/failures.js ⇒ lib/parsers/flow/modules/__test_fixtures__/failures.js • src/parsers/flow/modules/__test_fixtures__/fixtures.js ⇒ lib/parsers/flow/modules/__test_fixtures__/fixtures.js • src/parsers/flow/modules/__tests__/__snapshots__/module-parser-snapshot-test.js.snap (ignore) • src/parsers/flow/modules/__tests__/module-parser-e2e-test.js (ignore) • src/parsers/flow/modules/__tests__/module-parser-snapshot-test.js (ignore) • src/parsers/flow/modules/errors.js ⇒ lib/parsers/flow/modules/errors.js • src/parsers/flow/modules/index.js ⇒ lib/parsers/flow/modules/index.js • src/parsers/flow/modules/schema.js ⇒ lib/parsers/flow/modules/schema.js • src/parsers/flow/modules/utils.js ⇒ lib/parsers/flow/modules/utils.js • src/parsers/flow/utils.js ⇒ lib/parsers/flow/utils.js • src/parsers/schema/index.js ⇒ lib/parsers/schema/index.js • src/parsers/typescript/components/__test_fixtures__/failures.js ⇒ lib/parsers/typescript/components/__test_fixtures__/failures.js • src/parsers/typescript/components/__test_fixtures__/fixtures.js ⇒ lib/parsers/typescript/components/__test_fixtures__/fixtures.js • src/parsers/typescript/components/__tests__/__snapshots__/typescript-component-parser-test.js.snap (ignore) • src/parsers/typescript/components/__tests__/typescript-component-parser-test.js (ignore) • src/parsers/typescript/components/commands.js ⇒ lib/parsers/typescript/components/commands.js • src/parsers/typescript/components/events.js ⇒ lib/parsers/typescript/components/events.js • src/parsers/typescript/components/extends.js ⇒ lib/parsers/typescript/components/extends.js • src/parsers/typescript/components/index.js ⇒ lib/parsers/typescript/components/index.js • src/parsers/typescript/components/options.js ⇒ lib/parsers/typescript/components/options.js • src/parsers/typescript/components/props.js ⇒ lib/parsers/typescript/components/props.js • src/parsers/typescript/components/schema.js ⇒ lib/parsers/typescript/components/schema.js • src/parsers/typescript/errors.js ⇒ lib/parsers/typescript/errors.js • src/parsers/typescript/index.js ⇒ lib/parsers/typescript/index.js • src/parsers/typescript/modules/__test_fixtures__/failures.js ⇒ lib/parsers/typescript/modules/__test_fixtures__/failures.js • src/parsers/typescript/modules/__test_fixtures__/fixtures.js ⇒ lib/parsers/typescript/modules/__test_fixtures__/fixtures.js • src/parsers/typescript/modules/__tests__/__snapshots__/typescript-module-parser-snapshot-test.js.snap (ignore) • src/parsers/typescript/modules/__tests__/typescript-module-parser-e2e-test.js (ignore) • src/parsers/typescript/modules/__tests__/typescript-module-parser-snapshot-test.js (ignore) • src/parsers/typescript/modules/errors.js ⇒ lib/parsers/typescript/modules/errors.js • src/parsers/typescript/modules/index.js ⇒ lib/parsers/typescript/modules/index.js • src/parsers/typescript/modules/schema.js ⇒ lib/parsers/typescript/modules/schema.js • src/parsers/typescript/modules/utils.js ⇒ lib/parsers/typescript/modules/utils.js • src/parsers/typescript/utils.js ⇒ lib/parsers/typescript/utils.js • src/SchemaValidator.js ⇒ lib/SchemaValidator.js [ OK ] ✨ Done in 2.27s. npm notice npm notice 📦 react-native-codegen@0.70.1 npm notice === Tarball Contents === npm notice 383B README.md npm notice 3.2kB lib/cli/combine/combine-js-to-schema-cli.js npm notice 1.8kB lib/cli/combine/combine-js-to-schema-cli.js.flow npm notice 2.5kB lib/cli/combine/combine-js-to-schema.js npm notice 1.3kB lib/cli/combine/combine-js-to-schema.js.flow npm notice 1.5kB lib/cli/generators/generate-all.js npm notice 1.4kB lib/cli/generators/generate-all.js.flow npm notice 1.7kB lib/cli/parser/parser-cli.js npm notice 386B lib/cli/parser/parser-cli.js.flow npm notice 777B lib/cli/parser/parser.js npm notice 811B lib/cli/parser/parser.js.flow npm notice 483B lib/cli/parser/parser.sh npm notice 222B lib/CodegenSchema.js npm notice 8.8kB lib/CodegenSchema.js.flow npm notice 1.8kB lib/generators/__test_fixtures__/fixtures.js npm notice 1.9kB lib/generators/__test_fixtures__/fixtures.js.flow npm notice 43.6kB lib/generators/components/__test_fixtures__/fixtures.js npm notice 44.0kB lib/generators/components/__test_fixtures__/fixtures.js.flow npm notice 5.7kB lib/generators/components/CppHelpers.js npm notice 6.4kB lib/generators/components/CppHelpers.js.flow npm notice 2.0kB lib/generators/components/GenerateComponentDescriptorH.js npm notice 2.3kB lib/generators/components/GenerateComponentDescriptorH.js.flow npm notice 9.3kB lib/generators/components/GenerateComponentHObjCpp.js npm notice 10.3kB lib/generators/components/GenerateComponentHObjCpp.js.flow npm notice 6.3kB lib/generators/components/GenerateEventEmitterCpp.js npm notice 7.2kB lib/generators/components/GenerateEventEmitterCpp.js.flow npm notice 6.5kB lib/generators/components/GenerateEventEmitterH.js npm notice 7.4kB lib/generators/components/GenerateEventEmitterH.js.flow npm notice 4.0kB lib/generators/components/GeneratePropsCpp.js npm notice 4.3kB lib/generators/components/GeneratePropsCpp.js.flow npm notice 23.4kB lib/generators/components/GeneratePropsH.js npm notice 26.1kB lib/generators/components/GeneratePropsH.js.flow npm notice 9.4kB lib/generators/components/GeneratePropsJavaDelegate.js npm notice 10.0kB lib/generators/components/GeneratePropsJavaDelegate.js.flow npm notice 7.1kB lib/generators/components/GeneratePropsJavaInterface.js npm notice 7.8kB lib/generators/components/GeneratePropsJavaInterface.js.flow npm notice 2.0kB lib/generators/components/GeneratePropsJavaPojo/index.js npm notice 2.1kB lib/generators/components/GeneratePropsJavaPojo/index.js.flow npm notice 4.0kB lib/generators/components/GeneratePropsJavaPojo/PojoCollector.js npm notice 4.7kB lib/generators/components/GeneratePropsJavaPojo/PojoCollector.js.flow npm notice 7.2kB lib/generators/components/GeneratePropsJavaPojo/serializePojo.js npm notice 7.5kB lib/generators/components/GeneratePropsJavaPojo/serializePojo.js.flow npm notice 2.0kB lib/generators/components/GenerateShadowNodeCpp.js npm notice 2.2kB lib/generators/components/GenerateShadowNodeCpp.js.flow npm notice 2.8kB lib/generators/components/GenerateShadowNodeH.js npm notice 3.1kB lib/generators/components/GenerateShadowNodeH.js.flow npm notice 5.3kB lib/generators/components/GenerateTests.js npm notice 5.9kB lib/generators/components/GenerateTests.js.flow npm notice 2.5kB lib/generators/components/GenerateThirdPartyFabricComponentsProviderH.js npm notice 2.7kB lib/generators/components/GenerateThirdPartyFabricComponentsProviderH.js.flow npm notice 2.6kB lib/generators/components/GenerateThirdPartyFabricComponentsProviderObjCpp.js npm notice 2.8kB lib/generators/components/GenerateThirdPartyFabricComponentsProviderObjCpp.js.flow npm notice 13.4kB lib/generators/components/GenerateViewConfigJs.js npm notice 14.0kB lib/generators/components/GenerateViewConfigJs.js.flow npm notice 2.7kB lib/generators/components/JavaHelpers.js npm notice 3.2kB lib/generators/components/JavaHelpers.js.flow npm notice 47.0kB lib/generators/modules/__test_fixtures__/fixtures.js npm notice 47.2kB lib/generators/modules/__test_fixtures__/fixtures.js.flow npm notice 8.4kB lib/generators/modules/GenerateModuleCpp.js npm notice 7.3kB lib/generators/modules/GenerateModuleCpp.js.flow npm notice 8.5kB lib/generators/modules/GenerateModuleH.js npm notice 7.0kB lib/generators/modules/GenerateModuleH.js.flow npm notice 16.8kB lib/generators/modules/GenerateModuleJavaSpec.js npm notice 15.6kB lib/generators/modules/GenerateModuleJavaSpec.js.flow npm notice 14.9kB lib/generators/modules/GenerateModuleJniCpp.js npm notice 13.9kB lib/generators/modules/GenerateModuleJniCpp.js.flow npm notice 4.7kB lib/generators/modules/GenerateModuleJniH.js npm notice 4.9kB lib/generators/modules/GenerateModuleJniH.js.flow npm notice 9.5kB lib/generators/modules/GenerateModuleObjCpp/header/serializeConstantsStruct.js npm notice 7.9kB lib/generators/modules/GenerateModuleObjCpp/header/serializeConstantsStruct.js.flow npm notice 9.1kB lib/generators/modules/GenerateModuleObjCpp/header/serializeRegularStruct.js npm notice 7.6kB lib/generators/modules/GenerateModuleObjCpp/header/serializeRegularStruct.js.flow npm notice 720B lib/generators/modules/GenerateModuleObjCpp/header/serializeStruct.js npm notice 836B lib/generators/modules/GenerateModuleObjCpp/header/serializeStruct.js.flow npm notice 6.4kB lib/generators/modules/GenerateModuleObjCpp/index.js npm notice 6.6kB lib/generators/modules/GenerateModuleObjCpp/index.js.flow npm notice 14.6kB lib/generators/modules/GenerateModuleObjCpp/serializeMethod.js npm notice 13.1kB lib/generators/modules/GenerateModuleObjCpp/serializeMethod.js.flow npm notice 2.9kB lib/generators/modules/GenerateModuleObjCpp/source/serializeModule.js npm notice 3.6kB lib/generators/modules/GenerateModuleObjCpp/source/serializeModule.js.flow npm notice 6.8kB lib/generators/modules/GenerateModuleObjCpp/StructCollector.js npm notice 5.4kB lib/generators/modules/GenerateModuleObjCpp/StructCollector.js.flow npm notice 549B lib/generators/modules/GenerateModuleObjCpp/Utils.js npm notice 673B lib/generators/modules/GenerateModuleObjCpp/Utils.js.flow npm notice 848B lib/generators/modules/Utils.js npm notice 1.3kB lib/generators/modules/Utils.js.flow npm notice 7.1kB lib/generators/RNCodegen.js npm notice 8.4kB lib/generators/RNCodegen.js.flow npm notice 647B lib/generators/Utils.js npm notice 700B lib/generators/Utils.js.flow npm notice 14.1kB lib/parsers/flow/components/__test_fixtures__/failures.js npm notice 14.1kB lib/parsers/flow/components/__test_fixtures__/failures.js.flow npm notice 27.8kB lib/parsers/flow/components/__test_fixtures__/fixtures.js npm notice 27.9kB lib/parsers/flow/components/__test_fixtures__/fixtures.js.flow npm notice 2.6kB lib/parsers/flow/components/commands.js npm notice 2.9kB lib/parsers/flow/components/commands.js.flow npm notice 6.2kB lib/parsers/flow/components/events.js npm notice 6.6kB lib/parsers/flow/components/events.js.flow npm notice 1.2kB lib/parsers/flow/components/extends.js npm notice 1.6kB lib/parsers/flow/components/extends.js.flow npm notice 8.1kB lib/parsers/flow/components/index.js npm notice 6.5kB lib/parsers/flow/components/index.js.flow npm notice 1.8kB lib/parsers/flow/components/options.js npm notice 2.1kB lib/parsers/flow/components/options.js.flow npm notice 13.1kB lib/parsers/flow/components/props.js npm notice 13.8kB lib/parsers/flow/components/props.js.flow npm notice 2.1kB lib/parsers/flow/components/schema.js npm notice 1.3kB lib/parsers/flow/components/schema.js.flow npm notice 738B lib/parsers/flow/errors.js npm notice 849B lib/parsers/flow/errors.js.flow npm notice 5.7kB lib/parsers/flow/index.js npm notice 3.7kB lib/parsers/flow/index.js.flow npm notice 5.3kB lib/parsers/flow/modules/__test_fixtures__/failures.js npm notice 5.4kB lib/parsers/flow/modules/__test_fixtures__/failures.js.flow npm notice 15.4kB lib/parsers/flow/modules/__test_fixtures__/fixtures.js npm notice 15.4kB lib/parsers/flow/modules/__test_fixtures__/fixtures.js.flow npm notice 8.6kB lib/parsers/flow/modules/errors.js npm notice 9.5kB lib/parsers/flow/modules/errors.js.flow npm notice 25.7kB lib/parsers/flow/modules/index.js npm notice 21.8kB lib/parsers/flow/modules/index.js.flow npm notice 416B lib/parsers/flow/modules/schema.js npm notice 557B lib/parsers/flow/modules/schema.js.flow npm notice 595B lib/parsers/flow/modules/utils.js npm notice 830B lib/parsers/flow/modules/utils.js.flow npm notice 4.4kB lib/parsers/flow/utils.js npm notice 5.1kB lib/parsers/flow/utils.js.flow npm notice 428B lib/parsers/schema/index.js npm notice 526B lib/parsers/schema/index.js.flow npm notice 12.9kB lib/parsers/typescript/components/__test_fixtures__/failures.js npm notice 13.0kB lib/parsers/typescript/components/__test_fixtures__/failures.js.flow npm notice 28.1kB lib/parsers/typescript/components/__test_fixtures__/fixtures.js npm notice 28.1kB lib/parsers/typescript/components/__test_fixtures__/fixtures.js.flow npm notice 3.1kB lib/parsers/typescript/components/commands.js npm notice 3.0kB lib/parsers/typescript/components/commands.js.flow npm notice 7.0kB lib/parsers/typescript/components/events.js npm notice 7.4kB lib/parsers/typescript/components/events.js.flow npm notice 1.3kB lib/parsers/typescript/components/extends.js npm notice 1.6kB lib/parsers/typescript/components/extends.js.flow npm notice 8.2kB lib/parsers/typescript/components/index.js npm notice 6.6kB lib/parsers/typescript/components/index.js.flow npm notice 1.8kB lib/parsers/typescript/components/options.js npm notice 2.1kB lib/parsers/typescript/components/options.js.flow npm notice 19.4kB lib/parsers/typescript/components/props.js npm notice 18.0kB lib/parsers/typescript/components/props.js.flow npm notice 2.1kB lib/parsers/typescript/components/schema.js npm notice 1.3kB lib/parsers/typescript/components/schema.js.flow npm notice 738B lib/parsers/typescript/errors.js npm notice 849B lib/parsers/typescript/errors.js.flow npm notice 5.8kB lib/parsers/typescript/index.js npm notice 3.9kB lib/parsers/typescript/index.js.flow npm notice 4.7kB lib/parsers/typescript/modules/__test_fixtures__/failures.js npm notice 4.7kB lib/parsers/typescript/modules/__test_fixtures__/failures.js.flow npm notice 18.8kB lib/parsers/typescript/modules/__test_fixtures__/fixtures.js npm notice 18.8kB lib/parsers/typescript/modules/__test_fixtures__/fixtures.js.flow npm notice 8.6kB lib/parsers/typescript/modules/errors.js npm notice 9.5kB lib/parsers/typescript/modules/errors.js.flow npm notice 26.8kB lib/parsers/typescript/modules/index.js npm notice 22.9kB lib/parsers/typescript/modules/index.js.flow npm notice 416B lib/parsers/typescript/modules/schema.js npm notice 557B lib/parsers/typescript/modules/schema.js.flow npm notice 595B lib/parsers/typescript/modules/utils.js npm notice 830B lib/parsers/typescript/modules/utils.js.flow npm notice 4.6kB lib/parsers/typescript/utils.js npm notice 5.3kB lib/parsers/typescript/utils.js.flow npm notice 1.4kB lib/SchemaValidator.js npm notice 1.6kB lib/SchemaValidator.js.flow npm notice 1.4kB package.json npm notice === Tarball Details === npm notice name: react-native-codegen npm notice version: 0.70.1 npm notice filename: react-native-codegen-0.70.1.tgz npm notice package size: 168.4 kB npm notice unpacked size: 1.3 MB npm notice shasum: 10bf591db802342bd5ac38352821ad6452ba4b52 npm notice integrity: sha512-KXRXARscSO4mt[...]WCnuO5sLFEYQg== npm notice total files: 167 npm notice + react-native-codegen@0.70.1 ``` Reviewed By: dmitryrykun Differential Revision: D37851965 Pulled By: cortinico fbshipit-source-id: 4d8c80831691e5f671c234bc3a1678ccb7435ff4

Summary: Automatically create a GitHub Release draft when a new React Native release is created. The GitHub Release will be created by the same Circle CI job that publishes the package to npm. This job will also upload the built Hermes binaries to the GitHub release. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D36646696 fbshipit-source-id: 0a863dc4e3215fc95f7852f8dc43858cdd852aaa

Summary: Changelog: [iOS][Internal] - Implement offsetX/offsetY properties on the PointerEvent interface Simple diff implementing the offsetX/offsetY properties on PointerEvent — thankfully the touch events already kept track of these so it was mostly a matter of forwarding that data to the pointer events. Reviewed By: lunaleaps Differential Revision: D37830139 fbshipit-source-id: 77f33a99393350d32cbe449e6a009bdeb2a12d08

Summary: Changelog: [RNTester][Internal] - Fix incorrect pointer event name in move test We recently removed the '2' suffix from certain pointer event names and I forgot to update this test. Reviewed By: lunaleaps Differential Revision: D37857862 fbshipit-source-id: 6f37dce139772cd16d663961dbcbbf68dde83101

Summary: Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent. 1) Run my one-off jscodeshift codemod 2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change) drop-conflicts Reviewed By: bradzacher Differential Revision: D37834078 fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581

Summary: Pull Request resolved: facebook#34195 Bumping React Native Codegen to prepare for the release of React Native 0.70 Changelog: [General] [Changed] - Bump react-native-codegen before 0.70 branch cut Reviewed By: cortinico Differential Revision: D37849972 fbshipit-source-id: 4c61baab937a7c44745b3597c575ca8b525e69bf

Summary: Changelog: [internal] The dafault UIKit value of `UIScrollView.contentInsetAdjustmentBehavior` is automatic. Fabric had incorrect value never. source: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc This was causing bug for one navigation library that's migrating to Fabric: reactwg/react-native-new-architecture#43 (comment) Reviewed By: javache Differential Revision: D37881453 fbshipit-source-id: 290ae428a720f00ed61f2a3e5c2c9bbf54e1ac6e

… build failures Summary: This diff is reverting D37801394 (facebook@51f49ca) D37801394 (facebook@51f49ca) has been identified to be causing the following test or build failures: Tests affected: - https://www.internalfb.com/intern/test/844424989736255/ Here's the Multisect link: https://www.internalfb.com/intern/testinfra/multisect/1062919 Here are the tasks that are relevant to this breakage: T116036972: 105 tests started failing for oncall bridgeless_jest_e2e_tests in the last 2 weeks We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it. **To Address Land blocker from previous version (see pic):** {F752642767} ``` Changelog: [General][Change] - Revert breaking change in MPay order creation screen (user input in duplicated, and then not deletable. See T126127801 for more details) ``` Reviewed By: philIip Differential Revision: D37863306 fbshipit-source-id: 24f2448d7bc9761ec31edd6f6b97c668171027d3

…vior" Summary: changelog: [internal] Original commit changeset: 290ae428a720 Original Phabricator Diff: D37881453 (facebook@e98a835) in the original diff I made a mistake. The default value for RN is never, we override it in one of our subclasses. Reviewed By: cortinico Differential Revision: D37884715 fbshipit-source-id: 3c5b5ef5550120034e33ae9047292f38159dea3e

…urbo module (facebook#34158) Summary: According Flow's document, a maybe type of T means `T | null | undefined`, instead of `T | null | void`. I think keeping TypeScript and Flow being consistent to each other is better. ## Changelog  [General] [Changed] - Accept TypeScript type `T | null | undefined` as a maybe type of T in turbo module. Pull Request resolved: facebook#34158 Test Plan: `yarn jest` passed in `packages/react-native-codegen` Reviewed By: yungsters Differential Revision: D37731169 Pulled By: philIip fbshipit-source-id: b6d9b7e8991f60e12c1004bed5b937b34fb02c47

Summary: Changelog: [internal] - Upgrade ESLint version to the latest - Upgrade ESLint plugin versions to the latest to ensure compatibility - Switch from eslint-plugin-flowtype to eslint-plugin-ft-flow - Updates lint suppressions - all `flowtype/` rules to `ft-flow/` ### `flowtype` vs `ft-flow` `eslint-plugin-flowtype` is well out of date and no-longer maintained. It's been abandoned by its owner. This means it crashes on ESLint v8. `eslint-plugin-ft-flow` is a fork of the above and is maintained by the same people that own the `flow-typed` project. Reviewed By: jacdebug Differential Revision: D37727177 fbshipit-source-id: 516be42f947fec9c886526c182a608b3311c0b50

Summary: Changelog: [iOS][Internal] - Add key modifier properties to the PointerEvent interface This diff adds implementations of the `ctrlKey`, `shiftKey`, `altKey`, and `metaKey` properties on the PointerEvent interface for iOS. Reviewed By: lunaleaps Differential Revision: D37869377 fbshipit-source-id: b187bae93fbfc97b6ca1d8d9786ad85343484b3d

Summary: Changelog: [RNTester][Internal] - Add the ability for platform tests to be marked as skipped There are some properties/tests in the web platform tests that we don't want to especially priorities (especially if they aren't especially relevant to the specification and just legacy browser compat) so this adds the ability for us to mark these tests as skipped. This is so that we can ensure that our platform tests are "complete" while decreasing the noise and distraction from failing tests that don't really apply to RN. Reviewed By: lunaleaps Differential Revision: D37889470 fbshipit-source-id: 6516ac90c242d662518a95cb9ba8ce643f6bb09c

…ndAccessibilityEvent Summary: Changelog: [Internal] Rename AccessibilityInfo.sendAccessibilityEvent_unstable to sendAccessibilityEvent In Fabric, we want people to use `AccessibilityInfo.sendAccessibilityEvent` instead of `UIManager.sendAccessibilityEvent` for Android. The API is not unstable. There is a test in [AccessibilityExample.js](https://github.com/facebook/react-native/blob/c940eb0c49518b82a3999dcac3027aa70018c763/packages/rn-tester/js/examples/Accessibility/AccessibilityExample.js#L959) in RNTester to confirm that it works. A search for [`AccessibilityInfo.sendAccessibilityEvent_unstable` in Github](https://github.com/search?q=AccessibilityInfo.sendAccessibilityEvent_unstable&type=Code) shows that it's not being used yet, which makes sense because it's an Fabric API. Therefore it's safe to rename it. Reviewed By: sammy-SC Differential Revision: D37901006 fbshipit-source-id: 73f35b09ca8f9337f4d66a431f0a3f815da38249

Summary: Add API for setting/getting native state. When present, the internal NativeState property of an object always stores a NativeState with a pointer to a heap-allocated shared_ptr + a finalizer that simply `delete`s it. Changelog: [Internal][Added] - JSI API for setting/getting native state on a JS object Reviewed By: jpporto Differential Revision: D36499239 fbshipit-source-id: a1ff1905811db1aac99ece3f928b81d0abfb342b

Summary: Log whether bridgeless mode is enabled or not when calling into a JavaScript module method fails. We are seeing a surge of these crashes in MessageQueue.js bridgeless mode. This temporary log will help us drill down into the issue. Changelog: [Internal] Created from CodeHub with https://fburl.com/edit-in-codehub This should not mess with the sitevar overrides. These are the two diffs where we mapped the venice and bridge errors to the same mid: D36649249, D36649249. Reviewed By: fkgozali Differential Revision: D37898744 fbshipit-source-id: 0ab337c8c0d73bd70c4756a16b8ece8ba8730c47

Summary: D37801394 (facebook@51f49ca) attempted to fix an issue of TextInput values being dropped when an uncontrolled component is restyled, and a defaultValue is present. I had missed quite a bit of functionality, where TextInput may have child Text elements, which the native side flattens into a single AttributedString. `lastNativeValue` includes a lossy version of the flattened string produced from the child fragments, so sending it along with the children led to duplicating of the current input on each edit, and things blow up. With some experimentation, I found that the text-loss behavior only happens on Fabric, and is triggered by a state update rather than my original assumption of the view manager command in the `useLayoutEffect` hook. `AndroidTextInputShadowNode` will compare the current and previous flattened strings, to intentionally allow the native value to drift from the React tree if the React tree hasn't changed. This `AttributedString` comparison includes layout metrics as of D20151505 (facebook@061f54e) meaning a restyle may cause a state update, and clear the text. I do not have full understanding of the flow of state updates to layout, or the underlying issue that led to the equality check including layout information (since TextMeasurementCache seems to explicitly compare LayoutMetrics). D18894538 (facebook@254ebab) used a solution of sending a no-op state update to avoid updating text for placeholders, when the Attributed strings are equal (though as of now this code is never reached, since we return earlier on AttributedString equality). I co-opted this mechanism, to avoid sending text updates if the text content and attributes of the AttributedString has not changed, disregarding any layout information. This is how the comparison worked at the time of the diff. I also updated the fragment hashing function to include layout metrics, since it was added to be part of the equality check, and is itself hashable. Changelog: [Android][Fixed] - Fix `AttributedString` comparison logic for TextInput state updates Reviewed By: sammy-SC Differential Revision: D37902643 fbshipit-source-id: c0f8e3112feb19bd0ee62b37bdadeb237a9f725e

…book#34176) Summary: Pull Request resolved: facebook#34176 It extracts the code related to the codegen from the main `react_native_pods` script to a dedicated file, adding also tests. ## Changelog [iOS][Changed] - Move codegen in separate files Reviewed By: cortinico Differential Revision: D37755818 fbshipit-source-id: 99760d1def26ddbf065fdd234e0d183c2795513c

Summary: Pull Request resolved: facebook#34177 This Diff destructures the parameters of the use_react_native! function. It does that in a backward compatible way, so we there should be no disruptions. It also adds documentation to the various public method we want to export to our users. ## Changelog [iOS][Changed] - Destruct use_reactnative parameters and ad ddocumentation Reviewed By: cortinico Differential Revision: D37787365 fbshipit-source-id: 27f9030db2e8c6c66b9548b4c1287eb8165ae5fc

…ook#34206) Summary: I just opened another PR and noticed the changelog page in the wiki redirected to the react native documentation. ## Changelog  [Internal] [Changed] - Update link to changelog documentation in PULL_REQUEST_TEMPLATE Pull Request resolved: facebook#34206 Reviewed By: NickGerleman Differential Revision: D37920424 Pulled By: cortinico fbshipit-source-id: f4e47172a13fe5b42c29e320d34816b490a14b6c

…correctly (facebook#34221) Summary: This fix is necessarly to ensure that when working on the codebase in the `0.XX-stable` branches (ex. when you are working on a release) the Hermes podfile is correctly set against the right commit for that branch, and not latest commit from main branch of Hermes repo. I didn't add a check to verify that the file `.hermesversion` exists because I think it's safe to assume that the file and the tag correctly exists when this step (doing a pod install on the `0.XX-stable` branch). Once this is merged, we need to cherry pick it on both the 0.69 and 0.70 branches ## Changelog [iOS] [Fixed] - Hermes pod: change logic to use the hermes tag to set the pod source correctly Pull Request resolved: facebook#34221 Test Plan: * git clone the repo * checkout 0.69-stable branch * follow https://reactnative.dev/contributing/release-testing * without this commit, when testing RNTester + iOS + Hermes the app will insta-crash on opening * with it, the app gets build successfully Reviewed By: cortinico Differential Revision: D37957660 Pulled By: cipolleschi fbshipit-source-id: 4e50099ed712b1ad8e6439822e3f530142982c1b

…facebook#34215) Summary: This resolves issues where the node_modules structure is not hoisted (like with pnpm). Since the template does not directly depend on the cli, it doesn't exist in the pnpm node_modules root. Moving it to the rn scripts makes sure that the relative require starts in the correct directory for both hoisted and pnpm structures. ## Changelog [iOS] [Fixed] - Fix cocoapods cli native_modules require for pnpm node_modules Pull Request resolved: facebook#34215 Test Plan: 1. react-native init 2. rm -rf node_modules 3. pnpm i 4. bundle install 5. bundle exec pod install --project-directory=ios This should succeed. Without the patch, it will fail with ``` [!] Invalid `Podfile` file: cannot load such file -- /.../node_modules/react-native-community/cli-platform-ios/native_modules. # from /.../ios/Podfile:2 # ------------------------------------------- # require_relative '../node_modules/react-native/scripts/react_native_pods' > require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules' # # ------------------------------------------- ``` Reviewed By: cortinico Differential Revision: D37959152 Pulled By: cipolleschi fbshipit-source-id: 7fa9af4a8c153cfd38360f57eca415a8c252dbd5

Summary: soloader 0.10.3 will apparently cause crashes in instrumented tests, 0.10.4 appears to fix these crashes Related: facebook/SoLoader#94 Related: reactwg/react-native-releases#26 (comment) ## Changelog [Android] [Changed] - Bump Soloader to 0.10.4 Pull Request resolved: facebook#34213 Test Plan: This is hard to test since it's in the AAR etc., I'm hoping CI is sufficient as the previous soloader bump PR went through similarly Reviewed By: cipolleschi Differential Revision: D37960320 Pulled By: cortinico fbshipit-source-id: ce1611d7b30df737c8525a70839b5491a6585c75

Summary: There are many files across fbobjc relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff was generated by a codemod and fixes these missing includes. More details on the missing imports https://fb.workplace.com/groups/929548250966094/permalink/981237982463787/ Changelog: [Internal] Reviewed By: yannickl Differential Revision: D37282740 fbshipit-source-id: 0f419025b3cf2f811e96ff464cb19e8e5a25aa09

Builds upon the `CellRenderMask` data structure added with facebook#31420, and VirtualizedList coverage added with facebook#31401. VirtualizedList currently keeps a [first, last] range as state, tracking the region of cells to render. The render functions uses this as an input, along with a few special cases to render more (sticky headers, initial render region.) This change moves to instead keep state which describes discontiguous render regions. This mask is continually updated as the viewport changes, batch renders expand the region, etc. Special cases are baked into the render mask, with a relatively simple tranformation from the mask to render function. This representation makes it much easier to support keyboarding scenarios, which require keeping distinct regions (e.g. for last focused) realized while out of viewport. MS/FB folks have a video discussion about VirtualizedList here: https://msit.microsoftstream.com/video/fe01a1ff-0400-94b1-d4f1-f1eb924b1809 facebook#31401 added quite a few snapshot tests, centering around the logic this change is touching. I manually validated RNTester FlatList examples (and their should be some upstream UI testing for them).

This change also includes the contents of facebook#32638 This change makes VirtualizedList track the last focused cell, through the capture phase of `onFocus`. It will keep the last focus cell, and its neighbors rendered. This allows for some basic keyboard interactions, like tab/up/down when on an item out of viewport. We keep the last focused rendered even if blurred for the scenario of tabbing in and and out of the VirtualizedList. Validated via UT.

…last-focused

Do not virtualize items adjacent to the last focused item #2

Are you sure you want to change the base?

Do not virtualize items adjacent to the last focused item #2

Commits on Jun 2, 2022

Commits on Jun 3, 2022

Commits on Jun 5, 2022

Commits on Jun 6, 2022

Commits on Jun 7, 2022

Commits on Jun 8, 2022

Commits on Jun 9, 2022

Commits on Jun 10, 2022

Commits on Jun 12, 2022

Commits on Jun 13, 2022

Commits on Jun 14, 2022

Commits on Jun 15, 2022

Commits on Jun 16, 2022

Commits on Jun 17, 2022

Commits on Jun 18, 2022

Commits on Jun 21, 2022

Commits on Jun 22, 2022

Commits on Jun 23, 2022

Commits on Jun 24, 2022

Commits on Jun 25, 2022

Commits on Jun 27, 2022

Commits on Jun 28, 2022

Commits on Jun 29, 2022

Commits on Jun 30, 2022

Commits on Jul 1, 2022

Commits on Jul 4, 2022

Commits on Jul 5, 2022

Commits on Jul 6, 2022

Commits on Jul 7, 2022

Commits on Jul 8, 2022

Commits on Jul 9, 2022

Commits on Jul 11, 2022

Commits on Jul 12, 2022

Commits on Jul 13, 2022

Commits on Jul 14, 2022

Commits on Jul 15, 2022

Commits on Jul 16, 2022

Commits on Jul 18, 2022

Commits on Jul 19, 2022

Commits on Jul 20, 2022