Summary:
Moves the LogBox images from base64 data to files since base64 is not supported everywhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D19879323
fbshipit-source-id: 2dc03eebfc712ed863ed76322e133fcad5b00bb4
Summary:
ChangeLog: [Both] Adds perf markers for `XMLHttpRequest`s
Makes it easier to see JS-based network operations in performance traces.
Reviewed By: zackargyle
Differential Revision: D19903143
fbshipit-source-id: c5ce60163569e003830d8079cb2b580469d5bd5d
Summary:
This class is no longer used by the core and thus can be removed.
It isn't exposed as part of our public API so this is technically not a breaking change, although it may still cause people trouble if they are reaching into internals. It is expected that people will use forwardRef instead of this class.
I will follow up this diff with a removal from the ReactNativeRenderer as well.
Changelog:
[Internal] Remove ReactNative.NativeComponent from React Native
Reviewed By: JoshuaGross
Differential Revision: D19888400
fbshipit-source-id: 78da51e6c0edf9d8706395d376c3bfe75dabda03
Summary:
Resolve React-RCTText warning: `'UIKeyboardTypeASCIICapableNumberPad' is only available on iOS 10.0 or newer`
## Changelog
[iOS] [Fixed] - Resolve React-RCTText Xcode warning
Pull Request resolved: https://github.com/facebook/react-native/pull/28054
Test Plan: Build template, React-RCTText should no longer throw a warning.
Differential Revision: D19887063
Pulled By: hramos
fbshipit-source-id: 3437ee993babd7cdaec259af24526e197acb64bb
Summary: changelog: [General] `console.error` calls, and uncaught exceptions are now displayed in the Metro logs as well
Reviewed By: passy
Differential Revision: D19743075
fbshipit-source-id: a665a06cfc7854ae785af177af8f2478bb1d76b0
Summary:
When `[RCTReconnectingWebSocket stop]` is called and `[RCTReconnectingWebSocket reconnect]` is scheduled afterwards (i.e. connection didn't happen before `[RCTReconnectingWebSocket stop]` being invoked), it will keep reconnecting forever.
Also fixes retain loop in block within `[RCTReconnectingWebSocket reconnect]`. When RCTReconnectingWebSocket is stopped and reference to it set to nil, block in reconnect will still keep self alive and reconnecting forever.
I found this edge case when I tried to stop RCTPackagerConnection after some time, so it doesn't spam with `[] nw_socket_handle_socket_event [C34585.1:1] Socket SO_ERROR [61: Connection refused]` when we don' have Metro running (we have brownfield app, so iOS devs don't need Metro running most of the time).
## Changelog
[iOS] [Fixed] - RCTReconnectingWebSocket is reconnecting infinitely when stopped before getting connected
Pull Request resolved: https://github.com/facebook/react-native/pull/26864
Test Plan:
- Put breakpoint into `[RCTReconnectingWebSocket reconnect]`
- Start sample RN app **without having Metro running**
- Into AppDelegate add something like
```objc
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[RCTPackagerConnection.sharedPackagerConnection stop]
});
```
- After the previous block is dispatched reconnect should not be invoked anymore
Reviewed By: motiz88
Differential Revision: D19767742
Pulled By: rickhanlonii
fbshipit-source-id: dabb2369b06217b961e9d2611257c106d350f70c
Summary:
Right now, people are calling `getInnerViewNode` and `getInnerViewRef` to get the ref of the `View` within `ScrollView`. Instead, this change adds a prop to `ScrollView` to give people direct access to that `View` if they need it.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getInnerViewRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView innerViewRef={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
```
Changelog:
[Changed][General] ScrollView: Deprecate getInnerViewNode and getInnerViewRef methods. Use innerViewRef={myRef} prop instead.
Reviewed By: TheSavior
Differential Revision: D19713191
fbshipit-source-id: 3304cb94a253dafb458ef49d6331e0e432693431
Summary:
Added description for rejectResponderTermination prop for the TextInput, which seemed to have been deleted.
Descriptions are taken from https://github.com/facebook/react-native/pull/16755/files
## Changelog
[Internal] [Added] - Add description for rejectResponderTermination prop for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/28001
Test Plan: This PR only changes comment, which has no effect on actual function.
Differential Revision: D19820886
Pulled By: TheSavior
fbshipit-source-id: 5cbaafcbae0bdbf6932ef9c7c0c1a75cd6d8794e
Summary:
**Resolve/Reject Promise**
* Add onFulfill and onReject to the `PushNotificationIOS.requestPermissions()` Promise
**Replace Apple-deprecated notification method**
* Old: In iOS 10, `UIApplication.registerUserNotificationSettings` was deprecated. Calling this would then call the AppDelegate's lifecycle function `didRegisterUserNotificationSettings`, and then in the AppDelegate, we'd call `RCTPushNotificationManager.didRegisterUserNotificationSettings` to return the user settings.
[registerusernotificationsettings Doc](https://developer.apple.com/documentation/uikit/uiapplication/1622932-registerusernotificationsettings?language=objc)
* New: Replace deprecated function with Apple's recommended `UNUserNotificationCenter.currentNotificationCenter getNotificationSettingsWithCompletionHandler`, which no longer needs the AppDelegate lifecycle method because it directly returns the user's settings in a completion hander.
[requestauthorizationwithoptions Doc](https://developer.apple.com/documentation/usernotifications/unusernotificationcenter/1649527-requestauthorizationwithoptions?language=objc)
**Add Tests**
* Add tests on `PushNotificationIOSExample.js` to test that the onFulfill and onReject are called
* On `PushNotificationIOSExample.js`, instead of asking permission upon page load, ask for permission when the user taps the button "Request Notifications (Should Display Alert)".
* Before, asking for permission multiple times before would result in the RN error "cannot call requestPermissions twice before the first has returned", now you can ask for permission as many times as you want because I've removed the now unused `RCTPromiseResolveBlock`.
**Future**
If this works on device (we have to land this to test push on device), we can delete `RTCPushNotificationManager.didRegisterUserNotificationSettings` which is being called from several apps.
Changelog:
[iOS] [Added] Resolve and reject promise for PushNotificationIOS.requestPermissions
Reviewed By: PeteTheHeat
Differential Revision: D19700061
fbshipit-source-id: 02ba815787efc9047f33ffcdfafe962b134afe6d
Summary:
This functionality was deprecated in [this commit](https://github.com/facebook/react-native/commit/e2bd7db732602b2c477fe040f2946bd8293df297) on Feb 12th, 2019, originall in 0.59.0
Changelog:
[Breaking][General] Alert: Remove deprecated support for Alert.prompt with type as Callback (deprecated in 0.59)
Reviewed By: cpojer
Differential Revision: D19762618
fbshipit-source-id: a8edb6045bbc57d56e75fd281e602f5370ba1810
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
List components aren't host components so checking if the direct component itself's internals isn't sufficient to know if we are in Fabric. For lists, we have to call through some helper functions to get to the host component.
Hopefully we will fix this in the future by making the lists use forwardRef, or by getting rid of the JS Driver altogether, but for now, this is fine (TM).
Changelog: Internal
Reviewed By: mdvacca
Differential Revision: D19731067
fbshipit-source-id: 0e73583c6bf7c10de30e668a390d29718d31b295
Summary:
Bridgeless mode requires all native modules to be turbomodules. The iOS animated module was converted to TM, but reverted due to perf issues. RSNara is looking into it, but it may be an involved fix. As a short term workaround, to unblock release mode testing of bridgeless mode, use `AnimatedMock`.
Changelog: [Internal] Disable animations in bridgeless mode
Reviewed By: RSNara
Differential Revision: D19729827
fbshipit-source-id: e6c4d89258ec23da252c047b4c67c171f7f21c25
Summary:
React is way better than it used to be...
Changelog: [Internal]
Reviewed By: zackargyle, lunaleaps
Differential Revision: D19421772
fbshipit-source-id: db82b68a0c2f31e9ef7e1875fd9e4bf27ef6295a
Summary:
## This diff
- Add a hybird scene tracker that support both native navigation and js navigation
- It also has a filter that bypass loading routes and unrelated routes like log box
- The tracker can provide exactly what surface user is looking at
Changelog: [Internal]
Differential Revision: D19667699
fbshipit-source-id: 600efd05e68bf2702c6c2b1d794e720059f75f81
Summary:
All of our other JS view configs are gated by the `RN$Bridgeless` flag. This one has been behind a DEV flag instead. We've been using it in DEV for a long time now, so it's probably ok to be in prod, but I figured it's better to just be consistent with the rest of the native components, since we only need this for bridgeless.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19669902
fbshipit-source-id: bd28cf84947bfe298efd95ae07e38c2bf4e45091
Summary:
This diff regenerates all Jest inline snapshots (`expect().toMatchInlineSnapshot()`) now that we use Jest 24.9.0 which fixes a longstanding [formatting instability bug](https://github.com/facebook/jest/issues/8424).
This is strictly a formatting change.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19684238
fbshipit-source-id: 77c1e5fe9d2dfef85dffdcc00056fb439d7d7f84
Summary:
When an asset is outside of the metro project root, it can lead to relative paths like `/assets/../../node_modules/coolpackage/image.png` as the `httpServerLocation`. This can happen for example when using yarn workspaces with hoisted node_modules.
This causes issues when bundling on iOS since we use this path in the filesystem. To avoid this we replace `../` with `_` to preserve the uniqueness of the path while avoiding these kind of problematic relative paths. The same logic is used when bundling assets in the rn-cli.
CLI part of this PR: https://github.com/react-native-community/cli/pull/939
## Changelog
[General] [Fixed] - Fix resolving assets outside of the project root
Pull Request resolved: https://github.com/facebook/react-native/pull/27932
Test Plan: Tested that an asset in a hoisted node_modules package doesn't show up before this patch and does after in a release build.
Differential Revision: D19690587
Pulled By: cpojer
fbshipit-source-id: 8a9c68af04594ce1503a810ecf2e97ef5bfb8004
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary: `requireNativeComponent` redboxes in bridgeless mode because there is no UIManager. This adds a handwritten view config to avoid using UIManager.
Reviewed By: ejanzer
Differential Revision: D19624044
fbshipit-source-id: 5ae68f63068a131a305754003154ee0cf0f1be46
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
This validate function uses the `UIManager.getViewManagerConfig` API to verify if props are supported. Bridgeless mode doesn't support UIManager APIs.
It seems like these `deprecatedPropType` will be removed eventually, so let's ignore it in bridgeless.
Changelog: [Internal] Ignore deprecatedPropType in bridgeless mode
Reviewed By: ejanzer
Differential Revision: D19603819
fbshipit-source-id: 2c744705be8821cc6a9d8daaac3e652987447e4d
Summary:
Adds build version and an onPress for the build info.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D19334440
fbshipit-source-id: b201b630086179faca31a08c62019a2019cedf4f
Summary:
Can be handy for general animation components, like `FancySuspense`.
ChangeLog:
[General][Added] Export LayoutAnimationConfig flow type
Reviewed By: zackargyle, TheSavior
Differential Revision: D19345668
fbshipit-source-id: 26178d1eb0b6f710f652bf82c8095dec5bf5afbd
Summary:
Introduces `Rect`, an (eventual) replacement for `EdgeInsetsProp`.
This new type is then used in `Pressability` to expand support such that `hitSlop` and `pressRectOffset` can be either a `Rect` or a numeric size.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18742616
fbshipit-source-id: 13dd360f68ab804839938fc950fa2f4b25d3ed8c
Summary:
This was all yungsters idea. I blame him. :)
Switching Pressable to be a functional component presents a new challenge. ReactNativeTestTools can no longer find its instance because there is no instance Pressable uses forwardRef.
We need a way to both find a pressable, and then call the onPress callback if the pressable isn't also disabled.
So in DEV (and thus test) we add the pressable config to a secret key on a function passed onto View. The TestTools look for this key on this function, and then can call onPress.
Super hacky, but so is all of ReactNativeTestTools. We aren't proud of this.
Changelog:
[General][Changed]: Added support for Pressable to ReactNativeTestTools.tap
Reviewed By: yungsters
Differential Revision: D18849358
fbshipit-source-id: ea8880ceedfc04cda217ee17ba140475d003172c
Summary:
When building as a framework these headers get automatically added to the framework umbrella header for React-Core. Instead of converting all the React sources to ObjC++ files and still forcing external users that build native source (and link against a framework build) to also compile as ObjC++, this makes the attribution related methods that were added in https://github.com/facebook/react-native/commit/fdcdca4 opt-in to ObjC++ builds.
This is also the reason for the current failure of the CI `test_ios_frameworks` run.
## Changelog
I’m unsure if this change really warrants an entry in the CHANGELOG, as it’s more of an amendment of the (afaik) unreleased [change](https://github.com/facebook/react-native/commit/fdcdca4).
[iOS] [Fixed] - Make framework builds work again by making `RCTImageLoader` C++ requirement opt-in
Pull Request resolved: https://github.com/facebook/react-native/pull/27730
Test Plan:
I tested static and dynamic (framework) builds and ran the test suite.
This change should make the `test_ios_frameworks` CI run _build_ again, ~~but it may still fail overall as in my local testing one of the tests leads to a segfault (which I will try to address separately)~~.
Reviewed By: PeteTheHeat
Differential Revision: D19348846
Pulled By: fkgozali
fbshipit-source-id: 8a74e6f7ad3ddce2cf10b080b9a5d7b399bd5fc0
Summary:
## Context
When a `VirtualizedList` contains a cell which itself contains more than one `VirtualizedList` of the same orientation as the parent list, we log an error if sibling lists in a cell don't have unique `listKey`s (e.g. when the `listKey` prop isn't explicitly set). In release builds, this error does not have a component stack - nor a useful call stack - so it can be hard to track down the true source of the error in complex applications.
## This diff
Here, in addition to the generic error message, we also print the `listKey`, `cellKey` and orientation of each `VirtualizedList` in the hierarchy, from the child list upwards. This is done without significant overhead, by reusing the already-in-place context that `VirtualizedList`s use to manage nesting.
The assumption is that common strategies for deriving `listKey`s and `cellKey`s will make it possible to identify at least some lists in the hierarchy in common cases, and therefore help narrow down the search space even when component stacks are not available.
## Example
(See code in unit test)
```
A VirtualizedList contains a cell which itself contains more than one VirtualizedList of the same orientation as the parent list. You must pass a unique listKey prop to each sibling list.
VirtualizedList trace:
Child (horizontal):
listKey: level2
cellKey: cell0
Parent (horizontal):
listKey: level1
cellKey: cell0
Parent (vertical):
listKey: level0
cellKey: rootList
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19600366
fbshipit-source-id: 73f29507ec58a6a3f9b3f6b174a32b21dcd237a1
Summary:
In `XMLHttpRequest`, if the responseType is `Blob`, but the response is an empty string, we return `null` from `XMLHttpRequest.prototype.response()`. Instead, we should return an empty Blob. This is the behaviour on the web. To demonstrate, run the following HTTP server with Node:
## server.js
```
const http = require('http');
const server = http.createServer();
server.on('request', (request, response) => {
if (request.url.includes('img.png')) {
console.log('sending image');
response.end('');
return;
}
response.end('Hello World!');
});
server.listen('9000');
```
Then, open up a web browser to `http://localhost:9000`, and type the following in the console:
```
var oReq = new XMLHttpRequest();
oReq.open('GET', 'http://localhost:9000/img.png', true);
oReq.responseType = 'blob';
oReq.onload = function(oEvent) {
var blob = oReq.response;
console.warn(blob);
};
oReq.onerror = function(error) {
console.warn('Error!');
};
oReq.send();
```
This warns:
```
Blob {size: 0, type: "text/xml"}
```
Changelog:
[Both][Fixed] - [RN][XMLHttpRequest] Transform empty responses into empty Blobs
Reviewed By: sahrens
Differential Revision: D19500607
fbshipit-source-id: ec35e534b32a507c8a94a29e955b7bc4c62902a0
Summary:
When I was testing React Native 0.62-rc.1, I noticed that console was showing a warning for Require Cycle as shown in image below
This is because ScrollResponder was importing `ScrollView` to get the `typeof ScrollView`.
I've made an export for ScrollView type in `ScrollView` so that Require cycle warning will not show up.
## Changelog
[General] [Fixed] - Remove Require cycle warning.
Pull Request resolved: https://github.com/facebook/react-native/pull/27851
Differential Revision: D19577644
Pulled By: cpojer
fbshipit-source-id: 257b9421a91244d69394375102cfbe683326bba2
Summary:
Fixes https://github.com/facebook/react-native/issues/27137
This PR fixes an issue on iOS where RCTTextView height is not calculated as it should for some fonts where font `leading` attributed is not equal to zero, which results in wrong baseline alignment behaviour.
The fix for this is by setting `usesFontLeading` property of `NSLayoutManager` to `NO`, which results is a layout behavior that is similar to `UILabel`
Probably the documentation for `usesFontLeading` describes why UILabel has a different (correct) layout behavior in that case
> // By default, a layout manager will use leading as specified by the font. However, this is not appropriate for most UI text, for which a fixed leading is usually specified by UI layout guidelines. These methods allow the use of the font's leading to be turned off.
## Changelog
[iOS] [Fixed] - Fix RCTTextView layout issue that happens on some font with `leading` attribute not equal to zero, which causes wrong base-alignment layout
Pull Request resolved: https://github.com/facebook/react-native/pull/27195
Test Plan:
Below are the test results before and after the change, and comparing that to native UILabel behavior.
The test is done with using system font and custom font (`GothamNarrow-Medium`) and font size 50
[GothamNarrow-Medium.otf.zip](https://github.com/facebook/react-native/files/3832143/GothamNarrow-Medium.otf.zip)
```js
const App: () => React$Node = () => {
return (
<View style={{flex: 1, margin: 40, flexDirection: 'row', justifyContent: 'center', alignItems: 'baseline'}}>
<View style={{width: 30, height: 30, backgroundColor: 'lightgray'}} />
<Text style={{fontSize: 50, backgroundColor: 'green', fontFamily: 'GothamNarrow-Medium'}}>{'Settings'}</Text>
</View>
);
};
```
-------
### Before the fix
<img width="962" alt="Screenshot 2019-11-11 at 16 53 26" src="https://user-images.githubusercontent.com/5355138/68601049-dd778780-04a3-11ea-879e-cc7b4eb2af95.png">
-----
### After the fix
<img width="944" alt="Screenshot 2019-11-11 at 16 55 11" src="https://user-images.githubusercontent.com/5355138/68601180-1d3e6f00-04a4-11ea-87bc-61c6fa2cdb18.png">
-----
### Using `UILabel`
<img width="805" alt="Screenshot 2019-11-11 at 16 59 28" src="https://user-images.githubusercontent.com/5355138/68601487-b2d9fe80-04a4-11ea-9a0f-c025c7753c24.png">
Differential Revision: D19576556
Pulled By: shergin
fbshipit-source-id: 4eaafdab963c3f53c461884c581e205e6426718a
Summary:
The reason for this change is that it is the primary root that we want people to be using and the naming should reflect that.
#nocancel
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Changelog: [Internal]
Oncall Short Name: fbobjc_sheriff
Differential Revision: D19431128
fbshipit-source-id: c7208e20ed0f5f5eb6c2849428c09a6d4af9b6f3
Summary:
Since migrating to Turbomodules (8fe04cf) the addMenuItem method crashes because the NativeEventListener methods are missing from the codegen flow type. Added the same methods based on what we do in AppState which is another native module that extends NativeEventListener.
## Changelog
[Internal] [Fixed] - Add missing NativeEventListener methods to NativeDevSettings
Pull Request resolved: https://github.com/facebook/react-native/pull/27838
Test Plan:
|Before|After|
|{F226978596}|{F226978628}
Differential Revision: D19518474
Pulled By: PeteTheHeat
fbshipit-source-id: acddba9f18dd558df1d6df78b539689fdfd0062f
