Summary:
Currently, various CircleCI jobs intermittently fail when trying to fetch dependencies via Maven.
This adds a few retries before failing the CircleCI job to reduce noise from intermittent network fetch failures.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D28153008
fbshipit-source-id: ac944882ff0495f568973a709d6d61ef7b51b318
Summary:
Recent changes to `MapBuffer` have broken the compilation on Windows.
This fix is similar to this recently-merged change: https://github.com/facebook/react-native/pull/31106
Side note - this PR only addresses a build break, but doesn't address the unsafe casting semantics in `MapBuffer`, which can still cause overflows.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix compilation errors on Windows.
Pull Request resolved: https://github.com/facebook/react-native/pull/31363
Test Plan: RN now builds in Visual Studio on Windows.
Reviewed By: mdvacca
Differential Revision: D28028342
Pulled By: rozele
fbshipit-source-id: 77d8d4870c59b77acfc0ab2f4c3b7df40b59851d
Summary:
Changelog: [iOS] Use visible prop to dismiss Modal on old renderer.
Visible prop is used on Fabric so that onDismiss can be passed with the the bridgeless per-component event emitter, rather than the bridge global event emitter. The old renderer still uses the global event emitter.
I needed to use the visible prop for Paper too because in diff 6/7, Modal.js [no longer uses visible prop to return null](https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Modal/Modal.js#L221-L222), and Modal.js can't distinguish on whether it's a Fabric or Paper component.
Reviewed By: JoshuaGross
Differential Revision: D28137929
fbshipit-source-id: f6ede0019fbe498a10b822ff09fc135a9fff8ec0
Summary:
Changelog:
[Internal][Changed] - Fix Picker's item value in the ModalCustomizable example
This surface was removed a few days ago in D27926745 (https://github.com/facebook/react-native/commit/23ae702d97103105a24d85fc7d26f9fb9f15bb3e). Add it back to be able to test Modals manually.
There's no e2e test associated with this surface at the moment.
Reviewed By: nadiia, kacieb
Differential Revision: D28074150
fbshipit-source-id: dbcceed75e982d211b5c74cdf5f80aee59f54678
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Summary:
This diff migrates RCTMultilineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116333
fbshipit-source-id: b245026ebcd564380d0c74bbd6d9a36c661a8e71
Summary:
This diff migrates RCTSingelineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116332
fbshipit-source-id: d0a1a512a1cd967608512423db3dffa7c68fd2c5
Summary:
This diff reports warning when a method of the LazyUIManager is called when using fabric and StaticViewConfigs enabled
changelog: [Android][changed] Deprecate UIManager methods when using the new architecture enabled
Reviewed By: fkgozali
Differential Revision: D28108804
fbshipit-source-id: 4b430bdefa67914883a595dff97ea6c9ffd93361
Summary:
This diff and stack migratest Migrate UIManager.getViewManagerConfig -> UIManager.hasViewManagerConfig
This is necessary to avoid initializing UIManagerModule to detect if a component is registered into the native platform
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D27983716
fbshipit-source-id: 504180d8883959835e736f8081610b8c49810803
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 (https://github.com/facebook/react-native/commit/eeb36f470929c2fdd8e1ed69898a5ba9144b8715).
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:
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
Tim Yung
Igor Klemenski
Paige Sun
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
