Summary:
This diff adds a NativeLogBox module implementation on iOS to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a hidden window (the way redbox does) and render the LogBox to it
- show: will show the window
- hide: will hide the window
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the window with the `initialize` function so that it's warm by the time LogBox needs to render.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D18750008
fbshipit-source-id: 013e55ded55c8572bb08e0219ff4cd0060ebe0da
Summary:
`accessibilityTraits` was missing, this diff adds it.
Also there is a name mis match, in javascript it is called `accessibilityRole`.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18857668
fbshipit-source-id: 10656e8fb4e8c1d771a72c7f354b845e41cfc313
Summary:
We are seeing some non-trivial amount of crashes happened because `[RCTSurfacePresenter synchronouslyUpdateViewOnUIThread:props:]` requests a Component Descriptor which does not register in the registry.
And the problem here is that ComponentDescriptors are not being designed to be used outside of C++ UIManager, and we only use that in RCTSurfacePresenter only because it's an old workaround that makes Native Animation Driver works with Fabric.
Messing with ComponentDescriptors are in general dangerous. Accessing them outside of UIManager means that they might be deallocated at any time, extending their lifetime will cause other crashes on the other side. So, that's why this is "BROKEN".
This diff does not make the code worse, it just designates the problem that was there for a long time, so it kinda makes it better.
We don't know for sure why some ComponentDescriptors are not registered but this diff at least makes it not crash in such case.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18869651
fbshipit-source-id: 9d945ac7a2bd24a69a9bbb83b4fdd3cd19808f87
Summary:
It closes https://github.com/facebook/react-native/issues/24855
In the endRefreshProgrammatically of RCTRefreshControl.m there is calculation for content offset when spinner is shown CGPoint offset = {scrollView.contentOffset.x, scrollView.contentOffset.y - self.frame.size.height};
However self.frame.size.height is always 0 and therefore spinner is not visible
This change should fix that
Since the owner of the following PR is quite busy and won't be able to resolve the merge conflict anytime soon, I created this PR here to get the fix merged soon.
Ref: https://github.com/facebook/react-native/pull/27236
Thanks to [IgnorancePulls](https://github.com/IgnorancePulls)
## Changelog
[iOS] [Fixed] - Fix spinner visibility on beginRefreshingProgrammatically
Pull Request resolved: https://github.com/facebook/react-native/pull/27397
Test Plan:
IOS tests passed
Check whether this issue is reproduced or not for the repro which is described inside the issue.
https://github.com/facebook/react-native/issues/24855
Reviewed By: sammy-SC
Differential Revision: D18801307
Pulled By: hramos
fbshipit-source-id: d12af236778441a136dbe6b03dfd3495a465ae0f
Summary:
This diff allows re-connecting to the debugger websocket after reloading so that if, for example, metro has restarted, we'll reconnect to allow for debugging. Previously you would need to kill the app and re-open it to re-register the debugger websocket.
Changelog: [iOS] [Fixed] Reconnect to debugger websocket after metro is restarted.
Reviewed By: motiz88
Differential Revision: D18820399
fbshipit-source-id: ddbfa4476e70a6313c877a050ef2d77c04d1657e
Summary:
Adds requiresMainQueueSetup YES to top 16 components warning to help clean up the console. This should cut down ~50% of native warnings from React Native.
This should not change any behavior, just make the existing behavior explicit.
Changelog: [Internal]
Reviewed By: mmmulani
Differential Revision: D18774349
fbshipit-source-id: 5a74967280812ebfd859d7d976487d264b5820c7
Summary:
This diff disables the feature that propagates ScrollView's content offset to ShadowNode hierarchy making measuring content-offset-aware.
Seems that feature breaks FlatList because it does not expect measure calls to be content-offset-aware. We need to validate which legacy `measure*` calls should be content-offset-aware and which should not, and then verify that actual feature works (it's not clear why it worked with FlatList before) well before re-enabling this.
For now, the most safer choice is to disable this feature because I don't think some call sites actually rely on it now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18777939
fbshipit-source-id: 20d6c1081e7d2cc3b5a7a172ed947a9ae9cdfaab
Summary:
This diff moves the delegate splitter from RCTScrollViewComponentView class to RCTEnhancedScrollView. Now, it's a key feature of RCTEnhancedScrollView.
We need this to make `delegate` property of our UIScrollView subclass as resilient to any abuse as possible. E.g., if some other part of the app, unrelated to RN (e.g. BottomSheet component), nils the property, all dependent RN specific infra should continue to work. To make it possible, we make an exposed property to use the internal delegate splitter instead of providing direct access to the property of a superclass.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18752886
fbshipit-source-id: 04ec4758afefb8e17481d69471d53c61ab396698
Summary:
Surprisingly, `UITouch::view` property might be nil in some cases (the documentation does not specify in which ones), and that actually happens. That breaks the calculation of a touch position relative to a view on which the touch began. This diff implements storing the view inside ActiveTouch, so we always can access it when we need it. That's similar to how it's implemented in Paper's TouchHandler.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18752887
fbshipit-source-id: b412047132238ab4fc265e6c4fbcfb732ed27518
Summary:
Since extensions does not have access to sharedApplication, give them an option to set the presentedViewController.
This will allow modules such as RCTAlertsManager to function correctly in extensions.
Changelog: [General] [Added] - Added RCTUtilsUIOverride as a way to shortcut obtaining presentedViewController from sharedApplication to a supplied view controller for extensions.
Reviewed By: PeteTheHeat
Differential Revision: D18620886
fbshipit-source-id: c752a6e328588f388e23be5270bf7da277182cca
Summary:
Changelog: [Internal]
Load components only if they are used. This way we avoid upfront cost associated with loading components that are not used.
Reviewed By: fkgozali
Differential Revision: D18504437
fbshipit-source-id: 815dd0799f87e254ce0b899ee52a9bec8da45451
Summary:
RCTDevLoadingView wasn't hooked up to the codegen. This diff makes RCTDevLoadingView type-safe and also makes it TurboModule-compatible.
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D16969764
fbshipit-source-id: 47e6682eea3fc49d3f0448c636b5f616d5bce220
Summary:
Changelog: [Internal]
Introduce native command `setNativeRefreshing`, it has the word Native in order to avoid name conflict with setRefreshing in Android implementation. Even this component is iOS only, it would make it easier to merge them in the future.
Introduce `RCTRefreshableProtocol` and make `RCTRefreshControl` and `RCTPullToRefreshViewComponentView` to conform to the protocol so view manager can forward command to both, Paper and Fabric component.
Reviewed By: mmmulani
Differential Revision: D18475804
fbshipit-source-id: 4c19225784efc931b7b8f2d2671cc839bce429bf
Summary:
We see a quite small but probably dangerous crash in RCTMountingTransactionObserverCoordinator, it's unclear why exactly it happens but seems it's somehow connected with a shape of RCTComponentViewDescriptor struct.
Specifying storage attribute (`__strong`) correctly/explicitly might fix the issue.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18567763
fbshipit-source-id: 57d9f96c4609a38ddf44ce02df53f2d713dfb116
Summary:
Changelog: [Internal]
In paper implementation:
`accessibilityActivate` returns NO in case `onAccessibilityTap` is nil.
In Fabric we have no option to detect whether `onAccessibilityTap` is nil or isn't but we don't want to prevent VoiceOver from tapping an element. This could potentially trigger action associated with element twice.
Let's say you have `onPress` and `onAccessibilityTap`, it will trigger both if you trigger action through VoiceOver.
Reviewed By: shergin
Differential Revision: D18572432
fbshipit-source-id: c5ac002317c798a10045b6f05738299d0ae27456
Summary:
Just asserts to be sure that we don't over-insert or over-erase to/from the collection.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18567732
fbshipit-source-id: 569dbce6e62380ae3a0716448ad10bf418aa4f9c
Summary:
The removed code is fragments of one of failed approches to implement the functionality of RCTMountingTransactionObserverCoordinator.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18567733
fbshipit-source-id: cd7d6abc91394a2755866c35ff43d2c4f0271470
Summary:
`onLoadEnd` event should be called when load either succeeds or fails.
Before the fix, we didn't call it on error case.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18566996
fbshipit-source-id: 92727e91be167eb1e8eec4a40e90097972097c05
Summary:
Imagine a case where we initiate a synchronous state update right in the middle of the mount transaction. With the current implementation, the mount transaction caused by the change will be mounted right inside the in-flight transaction, which will probably cause a crash or incorrect mounting side-effects (which will cause a crash later).
Instead of executing all mounting instructions cased by the state change, we actually need to execute them right after the end of the current transaction (synchronously, inside the same main run loop tick).
This diff implements exactly this.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18444730
fbshipit-source-id: 3e777a7aa70ff28205d40588970c7478869b6899
Summary:
* Previously we called `onScrollEndDrag` in `scrollViewWillEndDragging` which was not correct.
* Now we also call `_updateStateWithContentOffset` in the method to update the stored in state `contentOffset`. This fixes all `measure*` infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18563050
fbshipit-source-id: ade696eda579642c22927c8a56ff122cd61a7534
Summary:
Changelog: [Internal]
The main use-case here is to get the rootTag off RCTImageView, for image loading instrumentation. The fact is, each RCTView subclass already has `reactTag` attached today. We already have the `rootTag` when the view is created by the UIManager, so why not just attach it like reactTag? If we don't, looking up the rootTag from the native component is non-trivial and extremely inefficient (have to jump to shadow queue, back to main queue, etc).
Reviewed By: sammy-SC
Differential Revision: D18497002
fbshipit-source-id: 8409e3a1c95e09accedd959592cbf178fab0b2c3
Summary:
Changelog: [Internal]
For attribution purpose, pass in the surfaceId and let the app-specific image loader handle it.
Reviewed By: shergin
Differential Revision: D18494106
fbshipit-source-id: e22ca339a2dd12c5bd619b596c7db9c49dc111d0
Summary:
Extracts a new `RCTFormatStackTrace` function from `RCTFormatError`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18114387
fbshipit-source-id: 4466f52d75d9da3a257cd1cc7067492a0c19a7d5
Summary:
We already have the exact same function in RCTConvertions.h, why have a copy of it here?
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18444731
fbshipit-source-id: ba1ebd538f92145c2ec0c30e0f7d14f1d05b381c
Summary:
Changelog: [internal] Fixes fabric specific crash
`_viewRegistry` is not thread safe and accessing it on another thread can cause a crash.
Calling it inside `RCTUnsafeExecuteOnMainQueueSync` shouldn't degrade performance because it is only used as a fallback.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18421789
fbshipit-source-id: 2adff434afe0a3c19318c95b051ee91ccf6293e5
Summary:
ScrollView isn't using codegen, therefore we need to manually write commands interface. I also typed commands so it uses `Double` instead of `number`.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18371887
fbshipit-source-id: 3bd11b9969b80ce6d2302e2f0da28884e9221b7e
Summary:
There's a Wilde OOM. We suspect that RCTTiming's conversion to TurboModule could be the cause. There could be a memory leak in the TurboModule system that RCTTiming exposes, or RCTTiming itself could have a memory leak. Therefore, I'm making RCTTiming a regular NativeModule for now.
Changelog:
[iOS][Changed] - Make RCTTiming a regular NativeModule
Reviewed By: fkgozali
Differential Revision: D18410788
fbshipit-source-id: 29567f899dcb82988bc265242e98cc35e878e749
Summary:
In D17880909 I migrated `[bridge reload]` to RCTReloadCommand.
One thing I didn't consider too much is the plethora of things which trigger a reload, and the `RCTAssertMainQueue()` constraint. I'd rather use locking (to protect listeners list) than requiring reloads be called from main thread.
Changelog: [iOS][Fixed] Fix potential assert firing in RCTReloadCommand
Reviewed By: rodrigos-facebook
Differential Revision: D18353156
fbshipit-source-id: d20b851fc5fe6c3518dfa3db8f1fc075cf7edee9
Summary:
PushNotificationiOS wasn't used by anything in ReactInternal, so I just removed it from the target.
## Codemod
Everywhere we required `ReactInternal`, we now also require `RCTPushNotification`:
```
> xbgr -f 'BUCK$' 'ReactInternal"' -l | xargs -I {} sed -i '' $'s|ReactInternal",|ReactInternal",\"fbsource//xplat/js:RCTPushNotification",|g' $HOME/{}
> xbgr -f 'BUCK$' 'ReactInternalApple"' -l | xargs -I {} sed -i '' $'s|ReactInternalApple",|ReactInternalApple",\"fbsource//xplat/js:RCTPushNotificationApple",|g' $HOME/{}
> arc f
```
Changelog:
[Internal] - Separate RCTPushNotification from ReactInternal
Reviewed By: PeteTheHeat
Differential Revision: D18363643
fbshipit-source-id: b8d123f40741c6d200dc9e736e64e885c2572e15
Summary:
None of the code inside `ReactInternal` depended on the `RCTLinkingManager` NativeModule. So I extracted `RCTLinking` into its own BUCK target. This will make it easier to make `RCTLinkingManager` TurboModule-compatible.
## Codemod
Everywhere we required `ReactInternal`, we now also require `RCTLinking`:
```
> xbgr -f 'BUCK$' 'ReactInternal"' -l | xargs -I {} sed -i '' $'s|ReactInternal",|ReactInternal",\"fbsource//xplat/js:RCTLinking",|g' $HOME/{}
> xbgr -f 'BUCK$' 'ReactInternalApple"' -l | xargs -I {} sed -i '' $'s|ReactInternalApple",|ReactInternalApple",\"fbsource//xplat/js:RCTLinkingApple",|g' $HOME/{}
> arc f
```
Changelog:
[Internal] - Separate RCTLinking from ReactInternal
Reviewed By: fkgozali
Differential Revision: D18314747
fbshipit-source-id: d9b5f536a6e93a0aca8721801a2ee5d446e0d4a6
Summary:
The diff moves an invocation of `_synchronizeAllSettings` from the constructor to `setBridge`. The side-effects of `_synchronizeAllSettings` rely on a bridge not being nil, so we need to ensure that the bridge is assigned to the instance before calling `_synchronizeAllSettings`.
Before the fix, enabling JavaScript debugger caused a stale and opening many copies of a debugger in Chrome.
Changelog: [Internal] Fixed race and possible stale in RCTDevSettings
Reviewed By: RSNara
Differential Revision: D18379596
fbshipit-source-id: 9f64b9bc5426720948113de61bc9ccc8c39193b4
Summary:
Interop layer can now forward commands to paper components.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D18285766
fbshipit-source-id: 33fe071c3000569d52fedcbcdeccc354dfe277d9
Summary:
This implement new <UnimplementedView> (only for iOS for now) that relies on the new "reactive component registration" functionality.
The `UnimplementedView` component is the perfect example of that. It's simple and uniquely required some constraints that we want to implement: the same component class registered several times with different handles and names.
This change serves two needs:
1. Providing an example of how that functionality can be used in more complex cases.
2. That will allow removing some `UnimplementedView`-specific code from the core (and very hot pathes of the system) and make them `noexcept`. That will eventually allow removing some public APIs from RawValue (constructing from folly::dynamic) that currently impose some implementation details and probably prevent us from making it slightly faster. There are only two consumers of this API, this is one of them.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D17211913
fbshipit-source-id: df1a1ac1a36289ef79904d509d38ee8b3f5588fb
Summary:
This diff removes `ComponentDescriptorProviderRegistry::remove()` and two derivative interfaces.
First, we don't use that and there is no concrete idea why we would need to use that. Those were originally built only for symmetry with limited knowledge about what exactly we need.
Second, those methods are actually dangerous and probably must not be supported by design. Removing a ComponentDescriptorProvider destroys already registered `ComponentDescriptor`s, and at the same time we might have ShadowNodes referring to that (which will cause a crash), and there is no reasonable way to check for the existence of those nodes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18285497
fbshipit-source-id: b461e38b923c217a256e1155689311397a994feb
Summary:
Revert some changes from D18148890 as they broke loading of RN surfaces with following error
``Invariant Violation: Expected HMRClient.setup() call at startup`
Changelog: [internal]
Reviewed By: mmmulani
Differential Revision: D18324764
fbshipit-source-id: f1b4af630f8330444f70a4d93be2b53f6d8e31c2
Summary:
In next diff Coordinator will have get more responsibilities therefore it's better to separate the concerns to different class
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18304834
fbshipit-source-id: 168a68969ed9da5772895f2da87e5273dccbaf30