Summary:
This diff adds and displays errors in LogBox. We will now toast both warnings and errors, open errors for inspection, and allow paginating through errors and warnings.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18091519
fbshipit-source-id: c155969dc505de5cfb0e95bb5a8221b9f8cfe4f7
Summary:
This diff adds a level to LogBox logs so that we can store and display errors in later diffs
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18091101
fbshipit-source-id: 21661d28a7945bdcb56702e2a03ab3612c11fe35
Summary:
Because the `mCatalystInstance` of the ReactContext can be null during teardown, there are technicaly cases where `UIManagerHelper.getUIManager` can return null. In those cases we check for a CatalystInstance and raise a SoftException, and return null. We must then guard in every case where we call `getUIManager` to prevent NullPointerExceptions.
See T56103679.
Currently crashes are coming from `PropsAnimatedNode.restoreDefaultValues` calling `UIManagerModule.synchronouslyUpdateViewOnUIThread` on teardown/at the end of an animation as RN is being torn down.
This can happen in both Paper and Fabric.
In dev this will still crash because the SoftException will trigger a crash. It will be a noop with logged warnings in production builds.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18165576
fbshipit-source-id: 7059e04ca339208dd64a0a08a375b565cb8cda02
Summary:
In previous diffs I migrated many (all?) NativeModules in FB and open-source to check for `hasActiveCatalystInstance` before calling `getJSModule`. We log SoftExceptions in those cases to find more potential race condition and lifecycle bugs without crashing.
In this diff, I migrate all the non-NativeModule callsites that I could find.
Previous diffs: see D18032458, D18035359, D18032788, D18092136, D18092137, D18112989, D18134400
Changelog: [Internal]
Reviewed By: mdvacca, mmmulani
Differential Revision: D18134694
fbshipit-source-id: 4729abfb84280b634463b1cd9b4dd808f310b6e7
Summary:
Simplify the API of `getReactApplicationContextIfActiveOrWarn`. We don't need to pass so much information into this method to collect good SoftExceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18134400
fbshipit-source-id: 0a250ab0252a44121f3339a31506a0a6c4c7cd35
Summary:
This diff annotates FabricUIManager class with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to FabricUIManager API
Reviewed By: JoshuaGross
Differential Revision: D18010917
fbshipit-source-id: 760ba04b78693cb184172c0fe613c7f808a49031
Summary:
This diff refactors the execution of the logging of Fabric React markers to be executed after the MountItems are executed on the UI Thred
Changelog: Improve logging of Fabric react markers
Reviewed By: JoshuaGross
Differential Revision: D18010920
fbshipit-source-id: e36306102d190119a89c16e660b855acab1528fe
Summary:
This diff refactors the stopping of DispatchUIFrameCallback on FabricUIManager to make it thread safe
Changelog: Refactor the cancellation of dispatching of Mounting operations for Fabric
Reviewed By: JoshuaGross
Differential Revision: D18010922
fbshipit-source-id: 305bc65576698cb785a2a2308cbd03db4a9a97e4
Summary:
This diff annotates core classes of Fabric with NonNull and Nullable annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to Fabric core classes
Reviewed By: shergin
Differential Revision: D18010918
fbshipit-source-id: 40fe68470b97cdf740f52dfeb9130465aab5e6df
Summary:
This diff annotates Fabric MountingManager and Events classes with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to Fabric Event classes
Reviewed By: shergin
Differential Revision: D18010923
fbshipit-source-id: fb9d5683bbd51fa25dda9b2023f9c411c3ff541d
Summary:
This diff annotates MountItems classes with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to Fabric MountItems
Reviewed By: JoshuaGross
Differential Revision: D18010921
fbshipit-source-id: 4c2bded87f7af1ddb941b2a49e390e51984890c0
Summary:
This diff extends the rendering on Text on Android to support textBreakStrategy prop.
Changelog: Add support for Text.textBreakStrategy prop into RN Android for Fabric
Reviewed By: JoshuaGross
Differential Revision: D18101403
fbshipit-source-id: c7f0b1cdc0de05172f0978d4dd3493620dcd941a
Summary:
This diff exposes textBreakStrategy as part of ParagraphAttributes. This is necessary to support the textBreakStrategy prop into Text for Android
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101404
fbshipit-source-id: e7b665cefe48cf8c764f73a1c51eede16245d1ec
Summary:
This diff extends ParagraphState to expose not only the AttributedString associated to Text components, but also ParagraphAttributes that describes the visual high level props of the Paragraph
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101407
fbshipit-source-id: 5f5d5ca35cc03e4bf983fd24654be9506d1901a1
Summary:
Previously, Fabric (RCTSurfacePresenter) was unaware of the bridge being valid or not. That caused the strange situations where the bridge might be already dead is still running.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050888
fbshipit-source-id: 34e3ec4b6991034410a40c041cfdcca36be8d743
Summary:
This diff introduces a new broadcasting event for Bridge that communicates that the bridge is being invalidated. This notification can be used by interested parties as a signal to start tearing down all bridge-dependant processes.
The biggest difference between the new event and `RCTBridgeWillInvalidateModulesNotification` is that the latter is being called asynchronously on the JavaScript thread, whereas the new one is being called on whatever thread caused the Bridge invalidation (deallocation) *synchronously*. In most cases that happens on the main thread that allows destroying strictly-main-threaded infra (mostly UI) synchronously and avoids races.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050889
fbshipit-source-id: 9364c820ea2b0358edf45f0e2b3e16a13d730a9c
Summary:
The purpose of RCTRuntimeExecutorFromBridge is to create/implement RuntimeExecutor using some JS queue implemented as part of the Bridge. This diff changes the implementation of this method, specifically:
Removing dispatching a sync block. This causes a deadlock with TM sometimes and should not be generally required.
The implementation does not retain the Bridge anymore.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D17960236
fbshipit-source-id: 0ddea561a6884f066e483d6b0f41ddd1621df73c
Summary:
Yes, this is a pretty big diff; because of the high interconnectedness of the things, I failed to split it apart.
This change does:
Introduces a new class RCTSurfacePresenterBridgeAdapter which decouples all Bridge-related functionality from RCTSurfacePresenter.
The new class allows "replacing" one instance of the bridge with another for a single RCTSurfacePresenter.
This change allows implementing unloading a bridge (e.g. during memory pressure warning) and suspending all RN surfaces with the future possibility of reloading a bridge and resuming surfaces.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D17960239
fbshipit-source-id: 7ae556ed91030f4c5ab187689ce6bd161fabde93
Summary:
The new method allows updating a ContextContainer using another one.
We will need that in the coming diffs.
Changelog: [Internal] Introducing `ContextContainer::update`
Reviewed By: sammy-SC
Differential Revision: D17960238
fbshipit-source-id: 187dcecbeee8c3de082575e53d5430d91b5338c5
Summary:
We need this for better decoupling RCTSurfacePresenter from Bridge.
Changelog: [Internal] - Changes in RCTSurfacePresenter (Fabric)
Reviewed By: sammy-SC
Differential Revision: D17960237
fbshipit-source-id: e91cd04eab967745c6e5151187eb68ba108f3986
Summary:
In D18032458 we introduce getReactApplicationContextIfActiveOrWarn. In this diff, modules that access a JS or Native module through ReactApplicationContext need to check if the CatalystInstance is still alive before continuing.
Modules that don't derive from `ReactContextBaseJavaModule` manually check for the catalyst impl and log their own SoftExceptions.
In this diff we also introduce SoftExceptions that by contract never cause crashes, even in debug mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18112989
fbshipit-source-id: 868f01f388aa2db3518db9f873f2afc2a62eed45
Summary:
Used `yarn` to update all of them except `react-native-github`. That one I did by hand. Sandcastle will let me know if I screwed it up too badly.
## Changelog:
[General] [Internal] - Upgrade `flow-bin` from 0.110.0 to 0.110.1
(Note: this ignores all push blocking failures!)
Reviewed By: mroch
Differential Revision: D18108512
fbshipit-source-id: a04b38f0fd4ec3a4008d7c61c23fa01eaaf8a8e4
Summary:
At times, the OS updates the color scheme without any active listener on RN side, e.g. if all RCTRootView's in iOS have been deallocated, no one will tell JS that the color scheme changes. So let's just always ask native side for the latest value.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18117334
fbshipit-source-id: e8564fb284c5720061592ba72e5b4907e5b48853
Summary:
This would cause a crash on iOS 9.3 because this method does not exist on UIView on that platform. By wrapping it in an availability check, we provide some safety.
Changelog: [iOS] [Fixed] safeAreaInsets call would crash on older versions of iOS
Reviewed By: fkgozali
Differential Revision: D18118025
fbshipit-source-id: fb7e517b3bcb3e0ba11ae81d8bf8397abc227e04
Summary:
* Fabric surface hosting view should emit the same event as RCTRootView
* Before emitting to JS, make sure to check if the color scheme really changed to avoid unnecessary re-render in JS
Changelog: [Internal]
Reviewed By: mdvacca, mmmulani
Differential Revision: D18100700
fbshipit-source-id: 451199beac07cdfb3833131ee429cc151391d8dd
Summary:
Some apps may need to disable the automatic dark mode color scheme assignment. This provides such kill switch.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18088313
fbshipit-source-id: 75abf34e92f8a4a637daa26135adf85965cb9df5
Summary:
When testing out the NetworkOverlay, I noticed that we were creating a lot of WebSocket connections for localhost:8097. Rick found that this is because we're trying to connect to React devtools every 2 seconds: https://github.com/facebook/react/blob/master/packages/react-devtools-core/src/backend.js#L67 and it appears we create a new WebSocket every time.
Dan suggested that we use opening the dev menu as a trigger for attempting to connect to React devtools. This diff uses RCTNativeAppEventEmitter to emit an event from native when the dev menu/dialog is shown, and listening to that event in JS to attempt to connect to devtools.
I'm also making the change of passing in a websocket instead of just passing in the host + port; this way it will only attempt to connect once on each call to `connectToDevTools` (otherwise, we would attempt to reconnect every 2 seconds as soon as the dev menu is opened, and then the next time the menu is opened we'd so start that *again*, and so on - I could have it keep track of whether it's already connecting and avoid doing it again, but this is easier and should be sufficient, I think).
We should probably also update the suggested troubleshooting tips on the devtools page to reflect this change, so that people don't get confused.
Changelog: [General] [Fixed] Fix issue where we attempt to connect to React devtools every 2 seconds
Reviewed By: mmmulani
Differential Revision: D17919808
fbshipit-source-id: 4658d995c274574d22f2f54ea06d7f29ef2f54dc
Summary:
setStyleInputs batching API was added to reduce the number of jni calls and although it improved performance in yoga world but was not impactful in litho and is not used anywhere.
Removing this saves around 500 bytes per architecture
#Changelog:
[Internal][Yoga] Removed unused code setStyleInputs batching API form Yoga
Reviewed By: amir-shalem
Differential Revision: D18036536
fbshipit-source-id: 7436b55dcd464dd9f9cc46406d4fd78d12babe55
Summary:
`responseType` should be a string, not an Object (which gets converted to a NativeMap by TM).
Changelog: [General] [Fixed] Fix the flow type for NativeNetworkingModule
Reviewed By: fkgozali
Differential Revision: D18019418
fbshipit-source-id: 316470ca82241223eafb5b05a54fc2bbf3074821
Summary:
Changelog: [Internal] Convert scrollTo, scrollToEnd, flashScrollIndicators to use native commands
This was reverted because of a circular dependency that was found in AMA. See D18065033 for fixing the circular dependency
Reviewed By: TheSavior
Differential Revision: D18063703
fbshipit-source-id: 7bd0125833f4f9e9e2f227732af0d6e38f009c06
Summary:
Text font size should not be negative, this diff throws an exception if TextView uses negative of zero font size
Changelog: [[internal]]
Reviewed By: shergin
Differential Revision: D18068071
fbshipit-source-id: 4074dca2019b6223eef68a407570258adbceaa43
Summary:
All struct args are passed into NativeModule methods via references. If blocks access those references, we don't move those references to the heap. This means that by the time that the block accesses the struct arg, it could be freed. This can crash the program.
The solution is simple: we copy the struct arg, and access the copy in the block. This ensures that the block will make a copy, which prevents the underlying data structures from being released by the time that the block accesses the struct arg.
Changelog:
[iOS][Fixed] - Retain cropData struct arg in ImageEditingManager.cropImage call
Differential Revision: D18076026
fbshipit-source-id: 1a7bb602606ff1afac38ad5451662c82fa86f205
Summary:
Text didn't support horizontal textAlign in Fabric for Android, this diff fixes that
Changelog: Add support for TextAlign prop in Fabric
Reviewed By: makovkastar
Differential Revision: D18068072
fbshipit-source-id: 3f8b1ba46989b55197fe9aa60ba2fb055b003d67
Summary:
This diff cleans up some of the message substitution logic and adds unit tests
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18056241
fbshipit-source-id: 6173961c049071ab8aeff6cd273bd3590ee21e60
Summary:
Previously we were should the count for the group (similar to how Chrome show the count on logs). This makes it difficult (impossible) to know how many logs are in the console without opening up the inspector.
This diff changes it so that the count shows the total number of warnings in the console instead.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18056028
fbshipit-source-id: c94a446708fb0885962e5c7dde75300cbedbab9b
Summary:
This diff improves LogBox performance by not storing and updating logs that are ignored.
Previous we stored all logs, including ignored, as a set. This was so that later, when we show a list of all logs, we would be able to show the ignored logs as well if toggled on. We stored the logs as:
```
const logs = new Set([
{
message: "Not ignored",
ignored: false,
},
{
message: "Ignored",
ignored: true,
},
// 100s more ignored logs
]);
```
But it turns out, we can have hundreds of ignored logs within seconds in some parts of the app. This means we we're re-rendering the LogBoxContainer hundreds of times with a filter on this set to filter out the ignored logs, just to change none of the content.
Now we store as:
```
const logs = new Set([
{
message: "Not ignored",
},
]);
```
Later, when we want to show ignored logs, we'll store these separately.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18055799
fbshipit-source-id: f5e21f66bb4ab6137d5d3908e8c03e119e3805d5
Summary:
In YellowBox we were parsing the component stack trace in a narrow set of use cases, which are commonly missed (I see this working ~50% of the time). That seems to be overly cautious. In LogBox, since there's a nice UI for component stack traces, let's be more aggressive about finding the component stack and we can address it with feedback if we find that there are real issues with this strategy in practice
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18053389
fbshipit-source-id: 48f116e2bd3f8cc43d53d3668fd6d5b8d7cba2a4
Summary:
There is a mixed usage of `folly::make_unique` and `std::make_unique`. Soon, `folly::make_unique` may be removed (see [this PR](https://github.com/facebook/folly/pull/1150)). Since `react-native` only supports C++14-compilers and later, switch to always using `std::make_unique`.
## Changelog
[Internal] [Removed] - Replace folly::make_unique with std::make_unique
Pull Request resolved: https://github.com/facebook/react-native/pull/26730
Test Plan:
Running the existing test suite. No change in behavior is expected.
Joshua Gross: buck install -r fb4a, make sure MP Home and forced teardown works okay on android
Reviewed By: shergin
Differential Revision: D18062400
Pulled By: JoshuaGross
fbshipit-source-id: 978ca794c7e972db872a8dcc57c31bdec7451481
Rick Hanlon
Samuel Susla
Joshua Gross
Adam Ernst
David Vacca
Dulmandakh
Valentin Shergin
glevi@fb.com
Kevin Gozali
Mehdi Mulani
Panagiotis Vekris
Kacie Bawiec
Emily Janzer
Sidharth Guglani
Moti Zilberman
Luna Wei
Ramanpreet Nara
Eli White
Joe Loser