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 https://github.com/facebook/react-native/commit/fb7b2d353356f67a3149c19ad733d46ec6842767#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
Summary:
This diff fixes whitespace trimming in codeframes by setting the whitespace size to 0 instead of infinity for lines that's don't have whitespace. This fixes a bug in frames where lines with 0 whitespace would not be considered.
So frames like this, where the common whitespace should be 0:
```
217 | function Hi(a?: String) {
> 218 | return Platform.OS === 'android' ? obj.die() : obj.die();
| ^
219 | }
220 |
221 | export default CrashReactApp;
```
Are instead trimmed at the second most common whitespace, which is 2. That's because line 217 has a whitespace length of 0, but we consider it as Infinity. When we get to line 218, we set the whitespace to 2. Then on line 19 we consider if 2 < Infinity and decide that the common whitespace is 2 resulting in:
```
217 | nction Hi(a?: String) {
> 218 | return Platform.OS === 'android' ? obj.die() : obj.die();
| ^
219 |
220 |
221 | port default CrashReactApp;
```
By setting the whitespace per line to 0 when there's no whitespace match, lines without whitespace can accurately report their size and move the pointer back to the 0 position.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20030301
fbshipit-source-id: f1dec8cc57479f37ffa8128f93f7c8b3c6baaf91
Summary:
This diff interpolates logs before passing them downstream so that we don't see a bunch of logs with "%s" everywhere.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20034903
fbshipit-source-id: 966917aa21ba07af3fb114e6a6931d4bbf860040
Summary:
*Pressable* is a component which is intended to replace the Touchable* components such as *TouchableWithoutFeedback* and *TouchableOpacity*. The motivation is to make it easier to create custom visual touch feedback so that React Native apps are not easily identified by the “signature opacity fade” touch feedback.
We see this component as eventually deprecating all of the existing Touchable components.
Changelog:
[Added][General] New <Pressable> Component to make it easier to create touchable elements
Reviewed By: yungsters
Differential Revision: D19674480
fbshipit-source-id: 765d657f023caea459f02da25376e4d5a2efff8b
Summary:
motivation: there are cases where one'd like to control the radius of the ripple effect that's present on TouchableNativeFeedback - in my case, I want to make sure that both icons and text have the same ripple appearance, but that's currently not possible as far as I can tell.
Currently (afaik) the only way to set (upper) ripple limits is by specifying width, height and border radius ( + `overflow: hidden`), and this works well for icons which can usually be bounded by a square, but not for text which can have rectangular shape.
This PR adds `rippleRadius` parameter to `SelectableBackground()`, `SelectableBackgroundBorderless()` and `Ripple()` static functions present on `TouchableNativeFeedback`. It can make the ripple smaller but also larger. The result looks like this:
added to RNTester:
difference from the other ripples:
I'm ofc open to changing the api if needed, but I'm not sure there's much space for manoeuvring. While I was at it, I did a slight refactor of the class into several smaller, more focused methods.
It's possible that in some cases, this might help to work around this issue https://github.com/facebook/react-native/issues/6480.
## Changelog
[Android] [Added] - allow setting custom ripple radius on TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/28009
Test Plan: I tested this locally using RNTester
Reviewed By: TheSavior
Differential Revision: D20004509
Pulled By: mdvacca
fbshipit-source-id: 10de1754d54c17878f36a3859705c1188f15c2a2
Summary:
As we don't link modules manually anymore it's better to point the user in another direction when they face this issue.
## Changelog
[Internal] [Changed] - tweak missing RCTAnimation warning message
Pull Request resolved: https://github.com/facebook/react-native/pull/28139
Reviewed By: cpojer
Differential Revision: D20009264
Pulled By: hramos
fbshipit-source-id: 114cae4fe908186eab3d8d9e79c2016015406821
Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components.
This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR.
## Changelog
[General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR
Pull Request resolved: https://github.com/facebook/react-native/pull/28040
Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android.
Differential Revision: D19860205
Pulled By: TheSavior
fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Héctor Ramos
Tim Yung
Tommy Nguyen
Samuel Susla
Joshua Gross
Miguel Bolivar
Luna Wei
Max Kareta
Spencer Ahrens
Jesse Katsumata
Rick Hanlon
Logan Daniels
Daniel Sainati
Christoph Nakazawa
radex
Vojtech Novak
Riley Dulin
Tom Underhill
Janic Duplessis
Kevin Gozali
Pieter De Baets
Arjan Zuidema
Eli White
Ramanpreet Nara
Hans Halverson
Nikita Kraev
Kacie Bawiec
Rachel Nabors
generatedunixname89002005287564
Radek Czemerys
Janette Cheng
