Summary:
This diff fixes an issue where errors in LogBox during tests would cause the tests to crash.
The crash is due to the NativeExceptionsManager module not being mocked (as all native module need to be in tests). The fix is to properly mock the NativeExceptionManger.
This fix exposed an infinite loop issue where failures in LogBox will be logged to the ExceptionManager, which logs to the console, which logs to LogBox, creating a loop. This diff also fixes that look by moving the LogBox internal error check to the top of the monkey patched console methods.
Changelog: [Internal]
Differential Revision: D20428590
fbshipit-source-id: 7289a480c99ba8dee67772178b7629afb40b330a
Summary:
## Description
In T63516227, we're seeing a crash that occurs because `networking.methodQueue` is `nil`, and we try to `dispatch_async` to it.
## Hypothesis
This looks like a problem with NativeModule cleanup:
1. Some JS executes a call to `RCTBlobManager.addNetworkingHander`. This schedules an async method call on the `RCTBlobManager` method queue.
2. In `RCTCxxBridge invalidate`, on the JS thread, we loop through all the `RCTModuleData`s, and invalidate them. This invalidates our NativeModules (perhaps not all but only `RCTNetworking`).
3. The `RCTBlobManager.addNetworkingHander` method call finally executes, with `RCTNetworking`'s methodQueue set to nil, which throws this error.
Changelog:
[iOS][Fixed] - Fix RCTBlobManager cleanup crash
Reviewed By: PeteTheHeat
Differential Revision: D20498096
fbshipit-source-id: d2d60984637ddf883278289258aa9b2ae81bb172
Summary:
A few recent imports have explicitly added ".js" to the end of their path. This prevents Metro from resolving platform-specific JS files, e.g. "Foo.android.js" or "Foo.windows.js" instead of "Foo.js".
React Native Windows provides its own implementation of files in a few cases where stock React Native will share them between Android and iOS. We hope to reduce/eliminate these long term, but requiring explicit ".js" files currently breaks us in a couple of places where we have custom implementations.
This change is a quick regex replace of ES6 and CommonJS imports in 'Libraries/" to eliminate ".js".
## Changelog
[General] [Fixed] - Do not explicitly include ".js" in Library imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28311
Test Plan: I haven't done any manual validation of this, but `flow-check` should catch any issues with this during CI.
Reviewed By: cpojer
Differential Revision: D20486466
Pulled By: TheSavior
fbshipit-source-id: 31e1ccc307967417d7d09c34c859f0b2b69eac84
Summary:
Fixed some url in the code that was outdated.
## Changelog
[Internal] [Fixed] - Fix outdated url in Image Example of RNTester and comment in StyleSheet Type
Pull Request resolved: https://github.com/facebook/react-native/pull/28285
Test Plan: Url can be accessed, and content displayed makes sense.
Differential Revision: D20464293
Pulled By: shergin
fbshipit-source-id: f0c97f7a95ed2a3d6c396cff6cda0bdaab7f5c35
Summary:
This PR is to address https://github.com/facebook/react-native/issues/28200
Even though GeoLocation was extracted from the Core, there are still libraries i.e. the CoreLocation.h library included which cause Apple to reject Apps, as mentioned here.
This removed all references to the CoreLocation library that where remaining.
## Changelog
[iOS] [Removed] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28300
Test Plan:
- Flow check passes.
- RNTest built successfully.
Differential Revision: D20441145
Pulled By: shergin
fbshipit-source-id: 03faa4d20dc15cea931b42f34f13814df9c94a01
Summary:
The current implementation of `Pressability` has a bug related to `onLongPress`.
When a user starts a press gesture, we keep track of the activation position (occurs after waiting `delayPressIn` milliseconds). If the touch moves away from that position by more than 10dp, we rule out the long press gesture. This means no matter how long you hold down the press, even if you move it back to within 10dp, we will not fire `onLongPress`.
However, there is currently a bug where we never reset the cached activation position. This means that after the first press gesture, all subsequent long press gestures must start within 10dp of that first press gesture. This leads to seemingly intermittent missing long press gestures.
This fixes the bug by ensuring that whenever a press gestures is terminated (either via a cancel or release), we reset the activation position.
Changelog:
[General][Fixed] - Fixed Pressability to properly fire `onLongPress`.
Reviewed By: TheSavior
Differential Revision: D20410075
fbshipit-source-id: e4727b7a9585ce3ea39481fc13e56b6b91740c8c
Summary:
Apps implementing `UISceneDelegate` no longer clear out images when backgrounded because `UIApplicationDidEnterBackgroundNotification` no longer gets fired.
## Changelog
[iOS] [Added] - UIScene support for RCTImageView
Pull Request resolved: https://github.com/facebook/react-native/pull/28141
Test Plan:
1. Create a new iOS app implementing `UISceneDelegate` or modify an existing one
2. Open a React view with some images
3. Switch to another app, or background the current app
4. Observe that `-[RCTImageView clearImageIfDetached]` gets called
Reviewed By: shergin
Differential Revision: D20009200
Pulled By: hramos
fbshipit-source-id: bdbf79d6cf56a295344c036b9225efec672fa780
Summary:
Switching queues in `RCTLocalAssetImageLoader` is unnecessary. We dispatch to main queue before assigning the image to `UIImageView`.
Changelog: Remove redundant queue switch from RCTLocalAssetImageLoader
Reviewed By: PeteTheHeat
Differential Revision: D20347223
fbshipit-source-id: ff6215838f0462356d4a516e6ec31c82a742881a
Summary:
Allow JS to keep track of mostRecentEventCount and pass it into each event or prop update. We really don't want to separately keep track of that data.
In non-Fabric, the ShadowNode will keep track of the mostRecentEventCount associated to prop updates. In Fabric, that happens on the C++ ShadowNode.
Changelog: [Internal] Simplification to TextInput native state
Reviewed By: mdvacca
Differential Revision: D20374573
fbshipit-source-id: 385fba6ec69a071c78832a686b397699a6c55d67
Summary:
This PR only fixes a little typo that I noticed working on the documentation of React Native website taking reference from this source code, and then saw it 😅
## Changelog
[General] [Fixed] - Fixed typo from `inly` to `only` inside `Modal.js` library code.
Pull Request resolved: https://github.com/facebook/react-native/pull/28057
Test Plan: Not needed.
Reviewed By: cpojer
Differential Revision: D20197178
Pulled By: TheSavior
fbshipit-source-id: 372f263a16a2de665ced7c0d3f10e3897777d19f
Summary:
Changelog: [Internal]
Add one more error around AnimatedValue.js returning an undefined value for "value" property.
Since this error happens in construction of the animated node, it makes sense that the constructor could be passed an undefined value?
Reviewed By: zackargyle
Differential Revision: D20354532
fbshipit-source-id: ba35172cd91977c48c849a2b1e27596c4dd8b4d4
Summary: Added markerDrop API that will replace markerCancel in future.
Reviewed By: furdei
Differential Revision: D20003457
fbshipit-source-id: 38cf68455d9274761a49014d9cbb50d82f4e9437
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
This diff updates the errors thrown by Metro for invalid requires, and fixed a bug in Fast Refresh that was failing to handle errors returned by metro. The net result is that invalid requires are displayed as syntax errors with code frames.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20107057
fbshipit-source-id: 59f77aa1da620d2c619a7cc45d90f40ef8b54448
Summary:
When any list cell that may contain nested VirtualizedLists is laid out, it's possible that the offset of any child lists relative to the outermost list has changed. We need to tell these children to re-measure themselves relative to that outermost list, so that their viewability calculations are correct.
We already do this for regular list cells -- we just need to extend that logic to any child lists that may live in the ListFooterComponent.
Changelog: [General] [Fixed] - Fix viewability calculations for nested VirtualizedLists inside of a parent list's FooterComponent
Differential Revision: D20310961
fbshipit-source-id: 4bfcfb95c87329f2ee337d5499e5c7162ba692e8
Summary:
Similar to the previous diff in this stack, I'm adjusting the React files we use to make sure require and import statements don't get extracted by Jest. Right now Jest extracts them, and when it looks up dependencies in reverse it just ignores the ones that don't exist.
Corresponding React PR (to make sure this change doesn't get reverted during the next sync): https://github.com/facebook/react/pull/18222
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D20282829
fbshipit-source-id: 5ff6a64d31672dd29243d020e8174797a44d9267
Summary:
I noticed that there was a `height` and `width` props in `Image` component, but those props are not being used in `RCTImageView`(ios) or `ReactImageView`(android).
## Changelog
[GENERAL] [Removed] - Remove Unused ImageProp
Pull Request resolved: https://github.com/facebook/react-native/pull/28151
Test Plan: Start a new React Native Project, and use `Image` component with `width` and `height` props and verify that it does not display the image on both iOS and Android
Reviewed By: shergin
Differential Revision: D20197126
Pulled By: TheSavior
fbshipit-source-id: 186119448826659d7c01c7c8a271157228169c30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
During the development of `Pressability`, I removed the default "press in delay" in order to minimize differences between `Touchable` (as used by `TouchableWithoutFeedback`) and `Pressability`. However, it was a bug that `TouchableWithoutFeedback` zero'd out the default press delay.
This restores the original "press in delay". This will make it so that when users swipe over a pressable element in a scroll view, the scroll view will have time to cancel the touch and prevent a press in behavior (visual jank).
Changelog:
[General] [Changed] - Increase default `delayPressIn` value for `Pressability` to 130ms.
Reviewed By: TheSavior
Differential Revision: D20176152
fbshipit-source-id: 5d6481395ee501bcab20ab98cb46a6be2c423ddf
Summary:
I propose this change because we (and a lot of other people, I'd guess) pass an `async` function as a parameter to `onRefresh`. Because the `async` function returns a `promise`, flow is reporting an error. I think the type checking here can be relaxed either all the way to `any` (because RN does not care here what we return) or to `void | Promise<void>` to account for async functions.
looking at fb7b2d3533 (diff-a9c5687ae65236ba3e7f34bfdcdec81d) seems like the second is preferred
## Changelog
[General] [changed] - relax RefreshControl's onRefresh flow typing
Pull Request resolved: https://github.com/facebook/react-native/pull/28167
Test Plan: * flow passes
Reviewed By: hramos
Differential Revision: D20196529
Pulled By: TheSavior
fbshipit-source-id: bb5a314bcfb5fb9c8ab71eccb449f1322aeebacb
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
In heap snapshots, it was found that really large (20 MB) strings representing network data
were being logged as part of `Systrace.beginEvent` strings from `MessageQueue` in DEV mode.
To combat this, use `JSON.stringify` with limits to keep the depth, strings, arrays, and objects
in check.
Changelog: [Internal] Change `stringifySafe` to have max limits on string size
Reviewed By: yungsters
Differential Revision: D20016501
fbshipit-source-id: e123016557bc154e4210e0b4df44360570da8016
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
Changelog: [Internal] Throw error when setting Animated value to undefined.
Background:
ReadableNativeMap removes keys that have undefined values. Somewhere some animation is setting the value to be undefined.
Follow up: Find a way to warn generally that undefined values are being set for maps that become ReadableNativeMaps
Reviewed By: JoshuaGross
Differential Revision: D20169325
fbshipit-source-id: 404b727dc238703ebe5f71a0939340d5f1b3b211
Summary:
This is a redo of D16969764, with a few extensions.
## Changes
1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}`
2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`.
3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView`
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D18642554
fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
Summary:
We will soon be enforcing that flow suppressions will only apply when on an error's primary location ([post](https://fb.workplace.com/groups/179614562644215/permalink/559286354677032/)). This diff uses the codemod created in D20008770 to move all suppression comments to their primary locations in the `xplat/js` flow root, and deletes suppression comments that are not on any primary locations.
This diff was generated with:
```
~/fbsource/fbcode/flow/packages/flow-dev-tools/bin/tool suppression-primary-locations --json-file ~/www/errors.json ~/fbsource/xplat/js
hg st -n | xargs grep -l -P '@(partially-)?generated' | xargs hg revert
hg st -n | xargs grep -l 'format' | xargs prettier --write
```
Changelog: [Internal]
bypass-lint
Reviewed By: dsainati1
Differential Revision: D20122544
fbshipit-source-id: d94e409aadb18bb399a1ddbf9f3f2494fe4fb54c
Summary:
Changelog: [internal]
# Problem
Implementation of `matricesDiffer` was ignoring first element in the matrix, therefore two matrixes that were different were actually evaluated as same and React didn't pass value to native.
# Solution
Take first element in the matrix into account when comparing matrices.
Reviewed By: cpojer
Differential Revision: D20117210
fbshipit-source-id: 84c3b4e580da44bda4fc8bd8669318282ae9aa32
Summary:
Changelog: [Android] [Changed] - Internal storage now will be preferred for caching images from ImageEditor.
Now we try to write to internal cache directory first.
If that fails (due to no memory error or other IOException), we attempt to write to external storage (if that is allowed).
I introduced additional configuration flag, `allowExternalStorage` which is true by default.
And i updated documentation for new behaviour - see
`ImageEditor.cropImage(..)` comment.
Reviewed By: makovkastar
Differential Revision: D19878158
fbshipit-source-id: 7e338ce68f535f74c62b5eecd5a94af7e7396f8b
Summary:
Right now the code frame and stack trace for metro errors are useless. This diff improved these errors by showing the metro code frame for the source of the issue, and stripping the stack trace.
Ideally we could show the metro stack trace as well, but since stack traces are tightly coupled to symbolication (and metro source code does not need symbolicated, nor could it be), this is an acceptable incremental improvement.
Arguably, even showing the code frame is inappropriate and we should show a generic crash screen with reload and report buttons.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20057353
fbshipit-source-id: 5e999cea14c1cbd2f69737e3992a3e8d159fdf89
Summary:
Use codegen'd ViewCommands added in previous diff as a replacement for setNativeProps.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18619298
fbshipit-source-id: 08069e828e92ac3cca9813bbcdca99d99fb50883
Summary:
The migration from classy to functional component partially broke controlled TextInput selections. This fixes it.
The nuance is that even though we have "event counters" sent from native, "onChange" and "onChangeSelection" are separate events;
so even if you receive new text and a new native event counter, your selection may be out-of-date. Incrementing the event counter
when sending selection events breaks text updates; and adding another native event counter seems like overkill. Instead, in JS, we statefully
keep track of (1) the native event counter, (2) whether or not the selection has been updated for that event counter.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D18867152
fbshipit-source-id: c569ecd03ce0042d6feb5fa8af4c756588607a09
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
Removed an array.slice() call in the callImmediatesPass, which seems unnecessary to me, as the variable is immediately re-assigned on the next line.
Also fixed some flow issues, clarified a systrace marker and opensourced the relevant tests.
Changelog: [Internal] [Fixed] Improved JSTimer efficiency
Reviewed By: yungsters
Differential Revision: D20039181
fbshipit-source-id: 9b146980e8fa9f94b2f6153cc67cc7ced58104e5
Rick Hanlon
Ramanpreet Nara
Jesse Katsumata
Nick Gerleman
Hans Halverson
Luna Ruan
maschad
Héctor Ramos
Tim Yung
Tommy Nguyen
Samuel Susla
Joshua Gross
Miguel Bolivar
Luna Wei
Max Kareta
Spencer Ahrens
Logan Daniels
Daniel Sainati
Christoph Nakazawa
radex
Vojtech Novak
Riley Dulin
Tom Underhill
Janic Duplessis
Kevin Gozali
Pieter De Baets
Arjan Zuidema
Eli White
Nikita Kraev
Kacie Bawiec
Rachel Nabors
generatedunixname89002005287564
