Summary:
We see crashes in `updateProps:oldProps:` methods in several components, and we suspect it might happen because of the props object being null.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535605
fbshipit-source-id: f278a5cec47b7fd54d31d015427fa918c02d913b
Summary:
We see crashes in this method, so we need asserts to understand why exactly it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535606
fbshipit-source-id: 8b0d275825a028f51343e4ab91682c8299904e8d
Summary:
This should make `testID` prop work as it works in pre-Fabric renderer on iOS.
On Android it should already work fine.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D25524890
fbshipit-source-id: 3f25eb427d4449abaab790099546be18ae573f98
Summary:
Changelog: [internal]
This avoids getting NaN in JS. Paper does it as well.
Reviewed By: shergin
Differential Revision: D25243147
fbshipit-source-id: 48dd1aa6daa7de23550850bd5d30fc3b20e6828d
Summary:
This method allows a surface to re-render from scratch, without having to delete and reinstantiate the surface.
Changelog: [iOS] Added reset method to RCTFabricSurface to help with reloads
Reviewed By: RSNara
Differential Revision: D25000509
fbshipit-source-id: f74170aa78cc84491ad2679f130ed3c8965bbe34
Summary:
Before this change, RCTImageComponentView on every state update extracted the raw pointer to ImageResponseObserverCoordinator and stored this as an instance variable. This worked fine but the code relied on an assumption that `oldState` argument of `updateState:oldState` is always valid (because the `oldState` is what retained that pointer).
Now, because of some issue, seems that `oldState` value is not always correct, so to work around this problem and to make the code more robust, this diff implements a slightly different approach.
Now we don't store the raw pointer to ImageResponseObserverCoordinator as an instance variable; instead, we store a retaining pointer to a state object and retrieve the pointer to an ImageResponseObserverCoordinator on demand. The diff also introduces a new function `_setStateAndResubscribeImageResponseObserver` that incapsulates updating `_state` object, unsubscribing from the previous coordinator, and subscribing for a new one.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24880820
fbshipit-source-id: 1c4d8ea91ae07dd217447e43cd3dde7b6f02dc40
Summary: We don't need ConcreteStateTeller in <Image> component because we don't even update the state from the component. I will change the logic around the state in the next diff, so we have to remove ConcreteStateTeller first.
Reviewed By: sammy-SC
Differential Revision: D24880822
fbshipit-source-id: bc993bc04ef9f6df79bcbc51941ad6bf64baae58
Summary:
This change introducing using `updateStateWithAutorepeat` for state updates in RCTSafeAreaViewComponentView. This way we can reduce the number of active commits and reduce jumps & relayout passes.
The approach with a callback is better than using `_lastPaddingStateWasUpdatedWith` because:
* When we compare the values, we can compare them with actual previous padding numbers stored in Shadow Tree.
* The value stored in a UIView instance can go away because of a view being remounted because of flattening.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24719345
fbshipit-source-id: 9bf1ae284875b4c99cf23be2fcc9a829eb8a895e
Summary:
Historically, `UIScrollView`s in React Native do not cancel touches started on `UIControl`-based views (as normal iOS `UIScrollView`s do).
This diff implements this behavior.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24661106
fbshipit-source-id: 1fb98d62f9e1528f11e7699d460aaefcec534e97
Summary:
Cleaning up an old experiment, it was `static true` for a couple of months already.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24642808
fbshipit-source-id: 50ba955490d848a9c1698e1c6d0c296e833386f3
Summary:
Changelog: [internal]
Problem:
`props.transform` gets out of sync with `self.layer.transform`.
To avoid writing out value of transform matrix, in the follow example I will only consider identity matrix and non-identity matrix. It is sufficient to demonstrate the point.
1. View is reused with transform being something besides identity. This causes `props.transform` and `self.layer.transform` to be non-identity.
2. View is taken from pool and animated with transform set to non-identity.
3. React JS props arrive and set `view.props` to identity but `self.layer.transform` stays unchanged because it is managed by native animation. This is the point where `props.transform` and `self.layer.transform` get out of sync.
4. Native animation wants to set transform to identity to finish the animation. But inside `[RCTViewComponentView updateProps:oldProps:]` `self.layer.transform` does not get set because current `view.props` is already identity.
Solution:
After native animation layer calls `[RCTViewComponentView updateProps:oldProps:]`, verify that values were set. If they weren't, set them directly without depending on `[RCTViewComponentView updateProps:oldProps:]`.
Reviewed By: JoshuaGross
Differential Revision: D24538442
fbshipit-source-id: ba8c59c5c9bb751306118bd1c7f0ccd9d0fb7fba
Summary:
Changelog: [internal]
`onScroll` event needs to be fired when scroll view ends the scrolling animation and when scrollTo is called.
This is how Paper does it and client code might depend on it.
Reviewed By: JoshuaGross
Differential Revision: D24527189
fbshipit-source-id: bdec099f16b3d8c97686975a1f769db4d2c0d832
Summary:
Changelog: [internal]
ScrollTo command needs to clamp the value in order to not scroll out of content view of scroll view. Paper does the same thing.
Reviewed By: JoshuaGross
Differential Revision: D24526992
fbshipit-source-id: 47c48ecb01f4ae40791306016dd7847079263128
Summary:
Changelog: [internal]
Copy `blurRadius` into a variable instead of accessing it through a reference which might not exist when the block is dispatched.
Reviewed By: cpojer
Differential Revision: D24472850
fbshipit-source-id: 936ef671255ae0e825e1d2dfda9649824b63d297
Summary:
The previous implementation always replaced the prop set on every props update coming from Animated. Now, we merge the new set of props with the previous one.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24370751
fbshipit-source-id: 779272d47c776cc42071d3c93d06443b6c96a877
Summary:
Fabric has a feature that preallocates views before mounting even need them. We never tested the impact of this feature thought. This diff adds a way to enable/disable it and run an experiment.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24355612
fbshipit-source-id: fefd653e57232044cd7b28b160e12a4ef85dbb8b
Summary:
RCTSurfaceTouchHandler is not a thread-safe object and must be used (and initialized) on the main thread. Therefore we need to move the initialization to `view` method which is guaranteed to be called on the main thread.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290776
fbshipit-source-id: fc1f2f157599aff6fca053451f89bf7cca3c812a
Summary:
This adds support for a controlled `<Picker/>` component .
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D24005475
fbshipit-source-id: c50e9918f74f6ef5cdfbfe67cb6c132c12d64916
Summary:
This adds support for `<Picker style={}/>` prop for text styling. It reuses most of conversion logic from BaseText. This means that it actually supports more styles than Paper Picker supported. (Paper picker only supported ~4 styles, this supports everything that Text supports, so 10+ styles).
The only tricky thing is that Picker supports multiple ways of setting text color. Both
<Picker
itemStyle={{color: '#008BD0'}} >
<Picker.Item label="Java" value="java" />
<Picker.Item label="JavaScript" value="js" />
</Picker>
and
<Picker>
<Picker.Item label="Java" value="java" color={'#008BD0'} />
<Picker.Item label="JavaScript" value="js" />
</Picker>
technically work in Paper. I've decided to maintain this behaviour (since there's lots of product code callsites to both options).
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23980319
fbshipit-source-id: e469a837e28af0ad97cf0e171df26ee19adff3ab
Summary:
This builds on previous diff to properly parse `<Picker.Item/>` into a cpp struct.
This fixes the dummy text and text color TODOs.
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23964557
fbshipit-source-id: f42c6c9cf410bfc5e66ff078645b6378548481de
Summary:
This is a starting point for the handwritten Fabric Picker component. It is incomplete, and needs to be landed with the rest of the stack above it.
In general, this creates a new `ComponentView`, `ComponentDescriptor`, `ShadowNode`, `Props` and a few other boilerplate classes for Picker. A bunch of the logic in `ComponentView` was copied over from the Paper `RCTPicker` and `RCTPickerManager`.
What works in this diff:
- A `<Picker>` with items can be created in JS, and a corresponding `UIPicker` is created in native with placeholder text, default styling and the correct amount of items
What doesn't work yet (implemented in later diffs):
- Parsing items to use correct text and styling in native
- Events/commands
Reviewed By: sammy-SC
Differential Revision: D23941821
fbshipit-source-id: e049ca6004757fbd1361985644d5dbb8f53e1ce6
Summary:
Changelog: [Internal]
If `uiTouch.view` isn't managed by Fabric, go up the view hierarchy to find first view that is.
This is important for host views wrapped by <Touchable>, otherwise touches are not delivered to the component.
Reviewed By: yungsters
Differential Revision: D24219223
fbshipit-source-id: 17b4e3460735371553ee0d30b41776a977f8eafb
Summary:
Changelog: [internal]
RCTViewComponent view should have multipleTouchEnabled set to YES.
Paper has it enabled by default as well.
Reviewed By: JoshuaGross, yungsters
Differential Revision: D24219076
fbshipit-source-id: 74c18632457147b944a8abbacdbecb57e57f62ef
Summary:
Now we check for `_state` being nullptr before dereferencing this.
`accessibilityElements` (as a bunch of other methods that have the same check) can be called by OS any moment (we cannot predict when), so at some very rare moments, it can be called when the view is not fully initialized yet. To prevent crashing we just need to return some default value indicating that the view is empty.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24095654
fbshipit-source-id: d8a37f269c5bf7718acb0b512e7a9313e199398e
Summary:
RCTParagraphComponentView does not need to have the state teller because it does not change the state.
Also, we are thinking about removing State Teller, so to simplify a fix coming in the next diff, we are backout the introducing a state telled in RCTParagraphComponentView.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24095655
fbshipit-source-id: 90bd21cb8b01056c0db902a604b4088bf8c7750e
Summary:
Changelog: [internal]
Changing value of Switch should animate except for first rendering of the switch.
Reviewed By: JoshuaGross
Differential Revision: D24046268
fbshipit-source-id: d0b2a1a4837fc8daebce2f0e6d3d82212b490ba4
Summary:
Changelog: [internal]
# Problem
Fabric doesn't know when NativeAnimatedModule control a prop and overrides its change whenever any prop changes. For example component A is animating its opacity from 1 to 0. NativeAnimatedModule starts calling `[RCTViewComponentView updateProps:oldProps:]` method interpolating opacity from 1 to 0.
After it is finished, if any prop is updated on the component. Its opacity will be set to default.
# Fix
This is a temporary problem until Unified Animation System is put in place. To work around the issue for now, we keep a set of prop keys controlled by animated and only update the prop if it isn't in this list. List is cleared when the component is reused.
Reviewed By: JoshuaGross
Differential Revision: D24046848
fbshipit-source-id: 63cca6854f97b2de764cb3ed505d328323c64525
Summary:
This is a different approach to break the retain cycle: instead of detaching a view manually, we store a pointer to a view weakly.
I am working on some change that will make possible (and make use of it) to call `start` and `stop` on Surface objects mutiple times, so to make it happens we need to remove detaching from `stop` method.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24041524
fbshipit-source-id: 700b13d715d2eb84d52bf3e51e0fd2896a55baf8
Summary:
With this change a RCTFabricSurface instance will not longer to hold a `RCTSurfacePresenter`. This change will enforce the guarantee that retaining a `RCTFabricSurface` is not enough for the service to run (something also should retain a `RCTSurfacePresenter`).
For now it's a very small fix that should not anything, but this is a crusial part of some changes I am working on (one aspect of which implied calling unregistration in a `RCTFabricSurface`'s destructor). I need to decouple this part to test this change earlier and decouple this part of the complexity from the future diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24039581
fbshipit-source-id: c289ae057f0cd5b438f0aa9a1eb8577e1e00b39c
Summary:
This diff removes an incorrect assert and replaces it with a debug-only verification phase that compares "what we want" with "what we get".
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: PeteTheHeat
Differential Revision: D23983123
fbshipit-source-id: 03a628b4f8baa1f5fe4b55354b7c943e38b5e537
Summary:
Remove the older implementation of image instrumentation in Fabric by removing, RCTImageInstrumentationProxy, ImageInstrumentation from ImageRequest, and trackURLImageContentDidSetForRequest from RCTImageLoaderWithAttributionProtocol.
Changelog: [RN][Fabric][Image] Remove unused Fabric image instrumentation
Reviewed By: fkgozali
Differential Revision: D23990606
fbshipit-source-id: 004d04025d031af11377a73e5bfb64b1e0449962
Summary:
Changelog: [Internal]
Fabric removes components bottom up (from leafs to the root).
This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation.
To fix this, we snapshot contents of the Modal before any of its contents are removed.
Reviewed By: shergin
Differential Revision: D23976244
fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## 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
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Changelog: [Internal]
value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum.
Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value).
See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more.
Reviewed By: JoshuaGross
Differential Revision: D23903545
fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd
Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO.
Reviewed By: sammy-SC
Differential Revision: D23844265
fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810
Summary:
Changelog: [Internal]
There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper.
Reviewed By: JoshuaGross
Differential Revision: D23903493
fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc
Summary:
Changelog: [internal]
If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter.
To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter.
Reviewed By: shergin
Differential Revision: D23840054
fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
Samuel Susla
Valentin Shergin
Peter Argany
Paige Sun
simek
generatedunixname89002005287564