Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: scottrice
Differential Revision: D20495655
fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5
Summary:
## Problems
Repro steps:
1. Disable Fabric (because CMD + R doesn't work with Fabric right now).
2. Open up Marketplace and hit `CMD + OPT + R`
3. **Observe:** The progress bar doesn't show up right away. It also doesn't actually show progress.
https://pxl.cl/140g1
RN Support post: https://fb.workplace.com/groups/rn.support/permalink/3437652016283389/
## Fixes
The first problem is that progress bar doesn't actually show progress.
**Fix:** Bundle load progress is updated in `RCTCxxBridge`, where we first require `RCTDevLoadingView`, and then call its `updateProgress` method. Previously, we wouldn't lazily load `RCTDevLoadingView`, it already didn't exist. Lazily loading `RCTDevLoadingView` causes the progress view to show up. Here: https://pxl.cl/140gt
If you look at the above video, you'll notice there are two stages to the progress bar: stage 1 displays the actual progress. Stage 2 prompts that we're downloading the JS bundle. As you can see, stage 1 and stage 2 have different background colors, even though both of them are green.
**Fix:** I adjusted the JS to match the Native color. Here: https://pxl.cl/140gT
We're almost there, but the progress bar is dismissed twice?
**Fix:** I dug into the code, and the reason why was because when we hit `CMD + R`, we invalidate the bridge, and immediately re-initialize it. This means that we asynchronously invalidate the old TurboModuleManager, and immediately create a brand new one. Therefore, two `RCTDevLoadingView` modules can (and do) exist at once. So, I moved `RCTDevLoadingView` to be an instance member of `FBReactModule`, to ensure that it doesn't get cleaned up and re-created when TurboModuleManager is deleted and re-created. This finally fixed the progress bar jank:
https://pxl.cl/140hn
Changelog:
[iOS][Fixed] - Remove RCTDevLoadingView jank
Reviewed By: rickhanlonii
Differential Revision: D20607815
fbshipit-source-id: 05825c67adaf3cfda70be0fa2dc92d413dc8921b
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
When passing an object to contentOffset that doesn't have `y` prop set it causes the following error:
```
Error: AnimatedValue: Attempting to set value to undefined
This error is located at:
in ScrollView (at src/index.js:638)
...
```
This happens since a runtime check was added to the `AnimatedValue` constructor. (a3aaa471ec)
According to flow types the object passed to contentOffset should always contain both x and y props but since it worked before when y is undefined I think its fine to patch the runtime behaviour defensively, especially since the code change is simple.
## Changelog
[General] [Fixed] - Fix Animated Value initialized with undefined in ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/28349
Test Plan: Tested that the crash no longer reproduces when passing an empty object to contentOffset.
Reviewed By: cpojer
Differential Revision: D20601664
Pulled By: hramos
fbshipit-source-id: b098a2dd1e702f995a9a92fa6e4e9a204187dac4
Summary:
Handles the case when a value in an object parameter of a turbo module spec is null (even if the type is nullable).
For example, given:
```
export interface Spec extends TurboModule {
+myFunc: ({|
foo: ?string,
|}) => void;
}
```
and calling `NativeModule.myFunc({foo: null})`, we see an error like:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
```
Guarding against this by converting NSNull's to nils
## Changelog:
[iOS] [Fixed] - Fix crash when passing null value in object parameter of bridged method
Reviewed By: fkgozali
Differential Revision: D20591590
fbshipit-source-id: fdb90f34131427a235f2e3c99147bf1e6a9c6732
Summary:
add support to the android implementation of the Picker component for setting the background color.
Changelog: [Android] [Added] - Support item background color in Dialog Picker
Differential Revision: D20566131
fbshipit-source-id: d693b40803fa1051ec955c5728994c820fecd9e9
Summary:
See https://github.com/facebook/react/pull/18366
This contains a fork of the upstream Flow types. We shouldn't be syncing this since these leads to conflicting types.
As a result, these uses have already been codemodded away. Only the imports remained.
Changelog:
[React Core] - Remove ReactTypes from sync.
Reviewed By: gaearon
Differential Revision: D20583740
fbshipit-source-id: fc86a934cbdca8ff90fe90282b86ecc945a85e5f
Summary:
Changelog: [Internal]
# Fabric
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
2. In view commands, do not validate `eventCount`. It is passed in as undefined from JS because Fabric's text input doesn't use `eventCount`.
# Paper
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
Reviewed By: shergin
Differential Revision: D20538290
fbshipit-source-id: c7aeddc25f58697254474058ce901df958321f7c
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 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
Kevin Gozali
Spencer Ahrens
Ramanpreet Nara
Michael Bolin
Janic Duplessis
Alexander Kawrykow
Eddie Dugan
Sebastian Markbage
Samuel Susla
Rick Hanlon
Jesse Katsumata
Nick Gerleman
Hans Halverson
Luna Ruan
maschad
Héctor Ramos
Tim Yung
Tommy Nguyen
Joshua Gross
Miguel Bolivar
Luna Wei
Max Kareta
Logan Daniels
Daniel Sainati
Christoph Nakazawa
radex
Vojtech Novak
Riley Dulin
Tom Underhill
Pieter De Baets
Arjan Zuidema
Eli White
