Summary:
Removing unsafe cast from `int` to `uint16_t`.
Also, adding code to detect multiplication overflow during buffer resize.
## 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] [Fix] - Fix unsafe cast and detect overflow in MapBuffer.
Pull Request resolved: https://github.com/facebook/react-native/pull/31106
Test Plan: Code compiles in Visual Studio 2019 without the unsafe cast warning (or error depending on the configuration).
Reviewed By: mdvacca
Differential Revision: D26865138
Pulled By: rozele
fbshipit-source-id: 4692a38b05fc873e31fbbe94d70803244e82de5d
Summary:
This mode re-implements parts of the types-first architecture, and is a step
toward types-first 2.0, which will greatly reduce memory usage. In this mode,
Flow finds some errors that were missed before.
Changelog: [Internal][Changed] Updated to Flow's new signatures mode for types-first
Reviewed By: panagosg7
Differential Revision: D26890348
fbshipit-source-id: 4c0bc4960a79ae2c4fa4c420bac506c9b2565beb
Summary:
Create MC to gate execution of JS Responder in Fabric Android
MC.react_fabric.enable_js_responder_fabric_android is enabled by default in the server
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26905296
fbshipit-source-id: 82504174394d1e10fd017435cccd38952404fda0
Summary:
We can override the `scrollTo` method and it's likely/possible that Android internals are calling scrollTo directly. So, we can capture
more cases where the scroll position is changing and needs to be updated in Fabric State.
Unfortunately we still cannot override smoothScrollTo because it is marked as final. For now we just keep the custom `reactSmoothScrollTo` method
and hope that we can catch more cases with `scrollTo`.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D26887028
fbshipit-source-id: e2678f1a20640d598abbec9671d6102635f65bb2
Summary:
Changelog: [Internal]
Updates `ReactSurface` to use `SurfaceHandler` internally.
This removes most of the internal state in `ReactSurface` and propagates all the calls to the `SurfaceHandler`.
`FabricUIManager` now uses `SurfaceHandler` to start/stop the surface.
SurfaceId is still used for view operations. SurfaceId is also now mutable to play better with existing Android infra.
Reviewed By: shergin, mdvacca
Differential Revision: D26112992
fbshipit-source-id: 52e6860084d739381317035dc3011956d452063c
Summary:
Changelog: [internal]
The assumption was wrong. There can be more than one view on iOS in ScrollView. The other view is pull the refresh component.
Reviewed By: mdvacca
Differential Revision: D26880403
fbshipit-source-id: 69fb1668b5ee7d5f4a4ab3c89222587689c10591
Summary:
Followup to D26858584 (00959ffd6b). We should also immediately destroy C++ state memory (which will decrement a shared_ptr) when deleting a view.
This could improve memory while a surface is being used.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26876537
fbshipit-source-id: fc8353bed47db8fdbf5c7f6c6253ac788c460d9a
Summary:
Changelog: [internal]
UIManager shouldn't be retained in lambda because if it outlives runtime it causes a crash.
UIManager -> ComponentDescriptorRegistry -> ParagraphComponentDescriptor -> TextLayoutManager's cache -> AttributedString::Fragment -> ShaviewView -> EventEmitter -> EventTarget -> Pointer
This is the chain of ownership that can cause a crash if UIManager is retained for longer than JS runtime.
{F459238235}
Reviewed By: JoshuaGross
Differential Revision: D26851194
fbshipit-source-id: 644cdee34ba9286618659d847fb2e78bc301d049
Summary:
NativeModules have an initialize() method that they use to allocate any resources, set up listeners, etc. This diff imports that method into the TurboModule interface. This way, we don't have to cast TurboModules to NativeModules to initialize them. Also, it makes sense to import this initialization mechanism into the TurboModule infra.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871552
fbshipit-source-id: b8ae515b22928ed678b4003096e0756e991e10ff
Summary:
This diff migrates all NativeModules away from onCatalystInstanceDestroy() to the invalidate() method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871595
fbshipit-source-id: 132f6b75e485361835769a2b53bc742eefa47b59
Summary:
## Rationale
The CatalystInstance is going away after we delete the bridge. So, we should migrate away from onCatalystInstanceDestroy() to something else: invalidate().
## Changes
- Introduce the NativeModule.invalidate() cleanup hook.
- Both the NativeModule and TurboModule infra now call this invalidate() method, **as opposed to** onCatalystInstanceDestroy(), to perform NativeModule cleanup.
- **Is this safe?** All our NativeModules extend BaseJavaModule. BaseJavaModule.invalidate() delegates to NativeModule.onCatalystInstanceDestroy(), so NativeModules that implement onCatalystInstanceDestroy(), but not invalidate(), still have their onCatalystInstanceDestroy() method called.
Changelog: [Android][Deprecated] - Deprecate NativeModule.onCatalystInstanceDestroy() for NativeModule.invalidate()
Reviewed By: JoshuaGross
Differential Revision: D26871001
fbshipit-source-id: e3bdfa0cf653ecbfe42791631bc6229af62f4817
Summary:
When debugging this class a lot, I found it helpful to have these logs and it would have been nice if they were here already - I had to rewrite these several times.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26836318
fbshipit-source-id: 08eb9ae19923fc593d1aba031586a02a193d6b2d
Summary:
changelog: [internal]
There were three separate problems preventing measure infra to work correctly with views inside horizontal scroll view in RTL environment.
1. Initial offset is wasn't communicated to Fabric. This is resolved separately as it doesn't affect only RTL: D26778991 (630ac87591).
3. On Android when layout direction is RTL, offset of scrollview is calculated from right.
Reviewed By: mdvacca
Differential Revision: D26779860
fbshipit-source-id: 61572c78091a1f5417102eb38d88ba7d172e6102
Summary:
Whenever layout updates in a horizontal scrollview, in RTL mode we adjust the position - the impact *should* be that initially, we jump from position 0 to the right side of the scroll view,
such that scrolling starts from the right.
However, we were doing this entirely too aggressively before. We should only make this adjustment *if the layout changes the width*.
Changelog: [Android][Changed] Fixed jumpy RTL horizontal ScrollViews. If you have Android-specific JS hacks for handling RTL in ScrollViews, you probably can/probably want to remove them, because they should be reliable now and require fewer hacks.
Reviewed By: mdvacca
Differential Revision: D26771366
fbshipit-source-id: de11bd1cae1414018d88ce44b3583a8b15f3b330
Summary:
There are races between BackgroundExecutor and Fabric/View teardown, where, because of the way things are set up currently, a View will strongly retain a pointer into some native State object which can keep a host of other objects alive in C++, even after stopSurface, and even after RN itself starts tearing down.
To alleviate this, we more aggressively clear State from Java, without waiting for Java GC: 1) on stopSurface, 2) whenever a State object is stale from Java's perspective.
This should allow us to keep all common updateState semantics, while only introducing a new edge-case that stateWrapper can be destroyed during mounting if stopSurface happens at the same time. In those cases, checking for NPEs should be sufficient.
The possible race condition only really happens with updateState, so it's easier to check for. There should practically be no cases where there's a race between `stopSurface` and `getState`, because `getState` is only really called around state updates and view preallocation, and never after; we still check for NPEs in those cases, but it shouldn't be an issue.
Changelog: [Internal]
Reviewed By: thurn, sammy-SC, mdvacca
Differential Revision: D26858584
fbshipit-source-id: 2ef7467220865380037d69d8de322fe8797f6a12
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859161
fbshipit-source-id: 654c055c53c0e420c6d9f2b0135055aec34269c9
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859157
fbshipit-source-id: 754a5b4ede8defa8b7742cc42e09cc7cbfe4e18d
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859160
fbshipit-source-id: ce84deafd1f20d1680d333d1a176b0493623a4ee
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859205
fbshipit-source-id: 5398d24d2592de3fbb80ca59192b5b46543aa5c5
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859159
fbshipit-source-id: 8e47cedd4b218a47b33d1209f3ede2fd1531015d
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859158
fbshipit-source-id: 4966d3c49d194c4cb4063edf3a035f6077b76cd9
Summary:
I'm not sure what broke this, but in some cases, DialogModule doesn't get subscribed to LifecycleEventListener events.
This seems to fix it.
Changelog: [Internal]
Reviewed By: mdvacca, RSNara
Differential Revision: D26856016
fbshipit-source-id: 868baf102b85b202180adcbb8bb181dfe603188f
Summary:
Changelog: [internal]
Yoga offsets content view of scrollview in RTL environment. React Native Classis deals with it by using a separate component [ScrollContentView](6e6443afd0/React/Views/ScrollView/RCTScrollContentShadowView.m (L18-L25)
) and making the adjustment there.
In New React Native Renderer, it can be handled inside `ScrollViewShadowNode`.
Reviewed By: JoshuaGross
Differential Revision: D26817121
fbshipit-source-id: ad48374ef19b802d25e919ac0aae05c5890762f2
Summary:
Found this crash when rendering ReactEditText under Venice, from comment it's supposed to be called only in Paper, so I adde a Venice check to avoid calling this method.
{F446844248}
Changelog:
[Android][Changed] - Add a new check to avoid calling this method
Reviewed By: mdvacca
Differential Revision: D26781457
fbshipit-source-id: f4c2e890156a37e35aa153c736b50924254e67bc
Summary:
Ship responsibility for most View creation logic to ViewManager, where it already largely lies, and simplify code in Fabric and non-Fabric mounting layers.
Notably, some of this work was *already* being duplicated so we can expect an extremely tiny perf gain here.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26742711
fbshipit-source-id: 4213766d4cd366bc69cd47d4654f7b269bb9e7f4
Summary:
https://github.com/facebook/react-native/issues/31051
When trying to create custom viewmanagers, we don't have props, I have a use case where I want to create views on the basis of provided react prop from react native.
## 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
-->
[Android] [Changed] - pass initial props to ViewManager createViewInstance method in non-Fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/31053
Test Plan:
Tested Manually.
(Facebook - see D26719538, which should land first)
Reviewed By: mdvacca
Differential Revision: D26719510
Pulled By: JoshuaGross
fbshipit-source-id: ced78aa919e6b433e22ddb7c9eccc3e3e91950e9
Summary:
This diff migrates AndroidDropdownPicker 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: yungsters
Differential Revision: D26810196
fbshipit-source-id: 7be0396d49d9e1413d424ab1be035cbb6a211706
Summary:
This diff migrates AndroidDialogPicker 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: yungsters
Differential Revision: D26799476
fbshipit-source-id: d6605f60cc083d1d22b4f0fc0a2f79881502b1b4
Summary:
This diff migrates RCTPicker 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: yungsters
Differential Revision: D26799477
fbshipit-source-id: 2f5935e0a4796c7a76921762a087cf7823ebd62e
Summary:
Changelog: [internal]
StateWrapperImpl shouldn't retain State strongly because cleanup of `StateWrapperImpl` is triggered from Java and isn't guaranteed to take happen before runtime is destroyed.
This should resolve crash where `StateWrapperImpl`'s destruction causes a `~Pointer` to be called after runtime is destroyed.
Chain of ownership that will be broken by storing State weakly inside `StateWrapperImpl`.
`StateWrapperImpl -> ParagraphState -> TextLayourManager's cache -> AttributedString -> ShadowView -> EventEmitter -> EventTarget -> Pointer`
{F451105831}
Reviewed By: JoshuaGross
Differential Revision: D26815275
fbshipit-source-id: 0703c6dccc62c1d152923b786a83273fa8a03694
Summary:
std::thread's constructor is nodiscard. This breaks in MSVC 16.9 when nodiscard starts to be enforced. Either we should hold on to the created object or detach the temporary which is what I think this function intends to do anyway.
Fixes https://github.com/facebook/react-native/issues/31088
Fixes an invalid usage of std::thread's constructor
## 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] - fixes usage of std::thread in runtime executor
Pull Request resolved: https://github.com/facebook/react-native/pull/31090
Reviewed By: sammy-SC
Differential Revision: D26783963
Pulled By: appden
fbshipit-source-id: fed4d072792aafa058dd742e8fce30a207f991c1
Summary:
Changelog: [internal]
Add missing implementation of caretHidden to multiline text input. This will work for both React Native Classic and New React Native Renderer.
Reviewed By: shergin
Differential Revision: D26818087
fbshipit-source-id: 3597604a6bd414a4a3b292d809d63a18efa8acb3
Summary:
setRemoveClippedSubviews in ReactHorizontalScrollContainerView.java in RTL mode is overzealous and unexpectedly clips out views in a way that is not desirable.
It seems like what is actually happening is that the computed rect for the view is "0,0" and so contents are assumed to always be outside of this rect.
For now I've disabled this feature. We can investigate as a followup.
Changelog: [Android][Changed] Clipping subviews has been temporarily disabled in HorizontalScrollView in RTL mode. Minor/negligible perf impact.
Reviewed By: sammy-SC
Differential Revision: D26808937
fbshipit-source-id: 85af9c3fb542db9ca3aae03413a475695cd53391
Summary:
We need to register a root view component here synchronously because right after we start a surface, it can initiate an update that can query the root component.
This fixes an issue in Fabric Surface caused by a data race between registration of root component and concurrent call to `constraintLayout` on the main thread.
This how it happens:
1. We call `startSurface` on some background thread;
2. As a result `[RCTFabricSurface start]` schedules a lambda to the main thread that will register a root component.
3. Meanwhile some other code on the main thread changes the layout and requests the relayout of a surface.
4. Because the surface is already running, the `constraintLayout` method works as expected and schedules a mutation instruction that changes the size of the root component.
5. The mutation instruction is being delivered synchronously on the main thread and fails because the root component was not yet registered. Boom.
For now, it's not fully clear how to solve this problem properly. I suspect that the good solution would be to shift the responsibility of registering a root component to the MountingCoordinator side (so, we will have an explicit instruction prescribing creating and registering the root component). This will probably be a quite invasive change though.
For now, I think it's fine to make the block synchronous to avoid the race.
Reviewed By: mdvacca
Differential Revision: D26802418
fbshipit-source-id: d49484c90d1ac61ac595caf486562fc6f4843e2f
Summary:
Debugging with not having Metro console.log() working in Venice is inconvenient.
After PeteTheHeat's fixes in diff series D26624224 the ground issues should be gone, so I tried removing the guard for Android and it worked.
The only issue I found is that when connected to Hermes Debugger in Flipper it keeps refreshing (reloading?), I posted here https://fb.workplace.com/groups/2308952995990093/permalink/2899448643607189/, with this found, I think it's a good start to iterate on since there are no crashes and this would help us a lot on Venice debugging.
Changelog:
[Android][Changed] - Remove developer tool guard for android
Reviewed By: PeteTheHeat
Differential Revision: D26779418
fbshipit-source-id: 96bb18771e01a25f84f845833a4f71e70433ef2b
Summary:
Changes `Appearance.addChangeListener` to return an `EventSubscription` object that has a `remove()` method on it.
In an upcoming commit, calling `Appearance.removeChangeListener` will lead to a deprecation warning.
Changelog:
[General][Change] - `Appearance.addChangeListener` now returns an `EventSubscription`.
Reviewed By: kacieb
Differential Revision: D26696388
fbshipit-source-id: d0bdeffff3a2a366b3c11b6dc1417dfb2f1455c2
Summary:
This diff adds buttons to scroll to top and scroll to end to the invertStickyHeaders ScrollView test. This will allow programmatic scrolling to test sticky header behavior in end-to-end tests.
NOTE: This prop doesn't seem to work at all to invert the sticky header.
NOTE: There is also a bug where on first render, the sticky header does not "stick" correctly. My diff has not changed this and it seems to be a JS issue - I will investigate in another diff.
Changelog:
[General][Added] Added scroll buttons to invertStickyHeaders ScrollView test
Reviewed By: nadiia
Differential Revision: D26735461
fbshipit-source-id: 66db39ab9c9dbc9c62f50c5ff56db67a829f6db8
Summary:
# The bug
Sticky headers would not "stick" to the top of the ScrollView on initial render. On subsequent redners, all sticking would work correctly.
# Why the bug existed
This code to initialize the animated values used for sticky headers was in `UNSAFE_componentWillMount` prior to D26375818 (1641d46529). `UNSAFE_componentWillMount` is called before `render`.
In D26375818 (1641d46529), I moved the code into `componentDidMount`, which is called after `render`.
This caused a problem because code in `render` was relying on these initializations being done already.
# How I resolved the bug
To resolve this, I initialize these values in the constructor.
# Reference
Docs for React mount ordering: https://reactjs.org/docs/react-component.html#mounting
Changelog:
[General][Fixed] Fix sticky header not sticking on first render in ScrollView
Reviewed By: nadiia
Differential Revision: D26792003
fbshipit-source-id: c575e8cdd1d986ce3c38941d95d763e329e74874
Summary:
This diff extracts ComponentNameRegistry out of Fabric modules
This is necessary to avoid depending on Fabric and regressing APK size for other RN apps (e.g. IG)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26765328
fbshipit-source-id: 0a22c4279146f5243473c74a84e78fad7f08f956
Summary:
This diff integrates the ComponentNameResolver class into ReactInstanceManager
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716900
fbshipit-source-id: e3a5f44485f659a32bf6094eee7985daf634f50f
Summary:
This diff introduces the ComponentNameResolverManager and ComponentNameResolver classes. The purpose of these classes is to integrate NativeComponentRegistryBinding into RN Android
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716899
fbshipit-source-id: c62fb5c38ddce5325890d2506a6fb17d26043175
Summary:
Introduce the NativeComponentRegistryBinding class, the purpose of this class is to register the global function __nativeComponentRegistry__hasComponent into JS
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D26716902
fbshipit-source-id: d883b195b30600d3781d41158fd8c57cf22431df
Summary:
Changelog: [internal]
Calling `scrollTo` does not report offset change to Fabric core and measure infra can't compute correct values. This results in unresponsive buttons if horizontal scroll view on Android has initial offset set to anything besides default value 0.
Reviewed By: JoshuaGross
Differential Revision: D26778991
fbshipit-source-id: 5cad5cb9926c7923f6efcd56cb4e15c3b958c245
Igor Klemenski
Sam Goldman
David Vacca
Joshua Gross
Andrei Shikov
Samuel Susla
Ramanpreet Nara
Hans Halverson
Lulu Wu
Gaurav Gupta
Alexander Sklar
Valentin Shergin
Tim Yung
Kacie Bawiec
Micha Reiser