Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
This fixes multiple compile errors when building RNTester with Hermes enabled:
- `Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')`
- `'event2/event-config.h' file not found`
- tons of missing files (all added to RCT-Folly/Futures)
Changelog: [iOS] Fix Hermes build on folly version 2021.04.26.00
allow-large-files
Reviewed By: RSNara
Differential Revision: D28128087
fbshipit-source-id: ee7cb6fda72d00d22f6182d958aa8ba55939f158
Summary:
Implement the API for querying the properties of an object found in a
heap snapshot.
Now when you are debugging and take a heap snapshot, you can hover
over an object and inspect it!
Only works for subclasses of JSObject. Doesn't work for stuff like HiddenClass,
PropertyAccessor, native objects like WeakValueMap, etc. Those internal objects
display "Preview is not available" which matches what Chrome prints for its own
internal stuff.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D27834672
fbshipit-source-id: 607a8984b5a48b76c5ae57f9bd5bf53168f3ec3f
Summary:
Changelog: Fix main thread access to UIKit in RCTRedBox
{F611784226}
Xcode's main thread checker complains about this during reload. it is not needed to set `dataSource` and `delegate` to nil because the table view is about to be destroyed.
Reviewed By: mdvacca
Differential Revision: D28089039
fbshipit-source-id: 13b62cafb4790fc15b5a5dde131d4ae64bd97c82
Summary:
NativeAnimationModule on Android is using batches to combine related updates together. In Fabric, this process is controlled by JS, which schedules starts batching when Animated component props are about to be updated.
In rare cases when there's no prop update (like calls to `setValue` on `AnimatedValue`), changes weren't applied until the next batch was scheduled. This change ensures that such changes get applied directly.
This problem doesn't happen on iOS or non-Fabric surfaces, because they use per-frame scheduling instead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28100641
fbshipit-source-id: 87b3acb3a8de131cdcb2104dc121d40eccfbc29d
Summary:
In development, we can specify a debug name to force the whole React tree to have a meaningful name. This is useful for debugging: React DevTools, component stack traces, etc. More context in D26637787 (eeb36f4709).
This worked fine until now because `renderApplication` is never called more than once per React Native root. With pre-rendering, this won't be true as we'll be able to re-render the whole React tree with new props (after navigating to the screen).
The problem with the current implementation is that we generate a new component every time `renderApplication` is called, which makes the React reconciliation consider them different components and discards the whole sub-tree.
This fixes it by caching those components so we always return a component with the same identity (exactly the same function) when we call `renderApplication` repeatedly.
This won't have any effect in production where these components aren't created at all.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D28061384
fbshipit-source-id: 95833a5b74bb622896cb47426f74324d8740e5d7
Summary:
Runs an A:A react sync against the current revision to pick up the updates from the sync script.
Changelog: [Internal]
Reviewed By: yungsters, kacieb
Differential Revision: D28103715
fbshipit-source-id: 3593909e999bdceeb95423dc37dc0ee4282963d9
Summary:
Changelog:
[General] - Reflect Hermes release version from HermesBadge
It was a common footgun that an unexpected version of Hermes
engine is used in a RN app. To help with indicating this from
the runtime, Hermes exposes its OSS release version from
`HermesInternal.getRuntimeProperties()` Starting from 0.8.0.
This diff updates the `HermesBadge` used by `NewAppScreen`
header to reflect the version.
Reviewed By: nadiia
Differential Revision: D24436609
fbshipit-source-id: 8ba45be598a7d5af0e38f5044f9370fc7e1eb9a1
Summary:
React DevTools has gotten pretty outdated in React Native. Let's fix that!
Last time I tried this it caused a lot of churn for tools like Flipper, so I approached this in two steps ([detailed in this post](https://fb.workplace.com/groups/rnsyncsquad/permalink/808063140086959/)).
First was a short term plan (as implemented in [PR 21344](https://github.com/facebook/react/pull/21344)) to:
1. Branch and make a patch release of DevTools 4.10 that adds a protocol check to the frontend (to detect any newer backends).
2. Upgrade Flipper (and recommend upgrade for the OSS React Native Debugger as well) to this new frontend.
3. Wait for the updated frontend to roll out.
The short term plan is now done, at least for the internal build of Flipper, and both GitHub PRs to update Flipper and React Native Debugger have been merged.
So this diff moves forward with the longer term plan (implemented in [PR 21331](https://github.com/facebook/react/pull/21331)):
1. Add an explicit version to the protocol used by the DevTools "backend" and "frontend" components to talk to each other.
2. Check this protocol during initialization to ensure it matches.
3. Show upgrade/downgrade instructions if there's a mismatch (or if the check times out without a response– indicating an older backend).
4. Release this as 4.13.
---
Changelog:
[General][Changed] - Upgrade `react-devtools-core` from ~4.6.0 to ^4.13.0
Reviewed By: yungsters
Differential Revision: D28103394
fbshipit-source-id: 21114294144bde9aede63cb3ba98a240082299bd
Summary:
When REMOVE animations finish, they are hitting asserts in StubViewTree because of UPDATEs and REMOVEs being out-of-order. By simply not forcing REMOVEs to happen before UPDATEs, this problem seems to go away.
Long-term (in a couple weeks, likely) I want to add unit tests to catch all cases like this, but I'm comfortable with this change since it does fix a known assert failure.
Changelog: [Internal]
Differential Revision: D28086223
fbshipit-source-id: eb77ea94d76e996d7b2cb37038ce6f2a9799f8b4
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.
Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293
Reviewed By: lunaleaps
Differential Revision: D25507604
fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
From looking at other implementations of setJSResponder, we need the MountingManager to have access to "blocksNativeResponder" param, but do not need to pass that through to individual views (see also Android implementation).
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D28066257
fbshipit-source-id: e1420431478fd27d2e1463e291a0bbc600d3f0a6
Summary:
This diff ships the virtualizedlist remeasure fix implemented in D27003249 (1bc06f18c6)
For more details about experiment see: https://fb.workplace.com/groups/rn.engineering/permalink/2831770330485832/
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28072308
fbshipit-source-id: c23c958ca9f2991236cb5a5c02084722aa6de919
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
Changelog: [internal]
`accessibilityFrame` needs to take scrolling position into account. To fix that, we calculate the position dynamically.
Reviewed By: mdvacca
Differential Revision: D28056789
fbshipit-source-id: 3247b3e6fd64934e99563de83d163f657828e933
Summary:
Changelog: Fix possible sizing issue with DatePicker
Changing `preferredDatePickerStyle` changes size of the component without triggering re-layout of the react native screen. The fix is to make sure the size stays the same after changing the style.
Reviewed By: mdvacca
Differential Revision: D28035226
fbshipit-source-id: 2dcb50fd5ebaa0c0d01d3289c4ffa77a053cfc4a
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
Changelog: [internal]
state infra uses rvalue references until this point. I assume the original author intended to rvalue reference even here.
This way, we avoid unnecessary copy.
Reviewed By: JoshuaGross
Differential Revision: D28057570
fbshipit-source-id: 19af480234d44acffcdbb22606607279e25c8aed
Summary:
This diff fixes an IllegalArgumentException that's thrown when creating layout with negative width.
This is not a new bug, but it started firing recently (probably caused by a change in text being measured)
stacktrace:
```
stack_trace: java.lang.IllegalArgumentException: Layout: -2 < 0
at android.text.Layout.<init>(Layout.java:265)
at android.text.Layout.<init>(Layout.java:241)
at android.text.BoringLayout.<init>(BoringLayout.java:179)
at android.text.BoringLayout.make(BoringLayout.java:61)
at com.facebook.react.views.text.TextLayoutManager.createLayout(TextLayoutManager.java:290)
at com.facebook.react.views.text.TextLayoutManager.measureText(TextLayoutManager.java:384) [inlined]
at com.facebook.react.views.text.ReactTextViewManager.measure(ReactTextViewManager.java:172) [inlined]
at com.facebook.react.fabric.mounting.MountingManager.measure(MountingManager.java:349) [inlined]
at com.facebook.react.fabric.FabricUIManager.measure(FabricUIManager.java:461)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28015820
fbshipit-source-id: 129cd2a4c492d95d57fcdf3883b967a0b5df639a
Summary:
## Context
A React Native application can configure its RCTNetworking by initializing it with id<RCTURLRequestHandler> objects.
Therefore, RCTNetworking supports this initializer:
```
- (instancetype)initWithHandlersProvider:(NSArray<id<RCTURLRequestHandler>> * (^)(void))getHandlers
```
Right now, all id<RCTURLRequestHandler> are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTNetworking](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1471) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the request handlers: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTNetworking gives its _handlersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows the _handlersProvider to load id<RCTURLRequestHandler> from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTNetworking handler provider block RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28013000
fbshipit-source-id: 956d660771ab18f5e7f24fcc28792f9a217146e7
Summary:
## Context
A React Native application can configure its RCTImageLoader by initializing it with two different sets of objects:
- id<RCTImageURLLoader>
- id<RCTImageDataDecoder>
Therefore, RCTImageLoader supports this initializer:
```
- (instancetype)initWithRedirectDelegate:(id<RCTImageRedirectProtocol>)redirectDelegate
loadersProvider:(NSArray<id<RCTImageURLLoader>> * (^)(void))getLoaders
decodersProvider:(NSArray<id<RCTImageDataDecoder>> * (^)(void))getHandlers
```
Right now, both the id<RCTImageURLLoader>s and id<RCTImageDataDecoder>s are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTImageLoader](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1462-1469) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the loaders/decoders: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTImageLoader gives its loadersProvider and decodersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows these two blocks to load the RCTImageURLLoaders and RCTImageDataDecoder from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTImageURLLoader's loader/decoder provider blocks RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28012999
fbshipit-source-id: 09c787923b57bbf72aff95b504f88ee1f2f44283
Summary:
Refactor a code block that is duplicated 2x. Logic stays the same besides renaming, and a ternary operator to decide between getting the children from "old" or "new" tree.
Tests can help us refactor knowing that the logic is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018994
fbshipit-source-id: d34a033444e67091e44ff6a747fd39846c165238
Summary:
There's a case here where we do a loop, with a map loopup, and nested map lookup inside of that. It's not particularly efficient and was done because we have multiple distinct pointers to distinct ShadowViews that are backed by the same ShadowNode. Now due to previous, recent refactoring, we can simplify this case a lot.
The code WAS correct before, just confusing and not particularly efficient. Tests can prove that this is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018996
fbshipit-source-id: a7c8148802650c88888960c9c099954e0f8bc357
Summary:
This is no longer true because of the "scope" mechanism.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018995
fbshipit-source-id: 91470234bb15f7feeb92b41613b0bbdbe42ccb27
Summary:
I am deduping a duplicated block, and adding comments to explain when we create INSERT/REMOVE mutations immediately and when we defer creation.
Theoretically the ordering of mutations will be more consistent now, which ~shouldn't matter, but is probably a decent property to have. In particular, before, in some cases
both of these orderings were possible in various scenarios:
```
INSERT X -> Y
INSERT Y -> Z
```
and
```
INSERT Y -> Z
INSERT X -> Y
```
Both of those are fine/correct/won't cause issues on any known platforms. But now, at least for the two cases touched here, only this ordering will be produced:
```
INSERT Y -> Z
INSERT X -> Y
```
meaning we build the tree from the bottom-up (the "bottom" being the root) and do out-of-order inserts less frequently.
Again, the biggest part of this diff should be readability/refactoring/de-duplicating logic, but more consistent orderings is a nice-to-have.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28017926
fbshipit-source-id: 5941588d0c8bba8b0df7d0084d5d198f4b7c2427
Summary:
This change broke some animations on non-Fabric surfaces due to inconsistent batching of animation operations.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013968
fbshipit-source-id: 2f65c799dbe00168f1e756ef0af60206df5a8fcc
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
Summary:
This was missing, causing the test to fail.
Changelog:
[Internal]
Reviewed By: mhorowitz
Differential Revision: D28009429
fbshipit-source-id: 51d4366b4feb6a2300c5bd05007dd9455bdcd77b
Summary:
Changelog:
[General][Changed] Convert require statements to use import from in Libraries/Components
Reviewed By: lunaleaps
Differential Revision: D27921557
fbshipit-source-id: 3f1618455a47a56c4a090f3ececfef88476c0b8a
Summary:
Unit test case seed 1167342011 encodes a case where the differ produces a DELETE and CREATE of the same node in the same frame, which we consider an error.
It turns out this was caused by nested "unflatten" operations and this bit of deleted code specifically. We were deleting an unmatched node from a parent call's dictionary of nodes,
which prevented it from being matched in the "old" tree later on.
This is only possible now that we attach pointers to the "other" ViewNodePair when they're matched, so we can check existence of that pointer instead of inclusion in dictionaries to decide if we need to DELETE/CREATE a node and its subtree.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003330
fbshipit-source-id: 305440ef20b921883c1d6e38a4a4072e5a7f95ac
David Vacca
Ramanpreet Nara
Peter Argany
Riley Dulin
Samuel Susla
Andrei Shikov
Rubén Norte
Nat Mote
Rick Hanlon
Kevin Gozali
Xuan Huang
Brian Vaughn
Joshua Gross
Neal Poole
ananta
Kacie Bawiec
Scott Kyle
Adam Cmiel
Micha Reiser
Nadiia D
Tim Yung
