Summary:
changelog: [internal]
Attempt at fixing a crash in `Scheduler::uiManagerDidCloneShadowNode` by setting delegate to nullptr explicitly.
I don't think this will make a difference because `scheduler_` is released at the end of `dealloc` but it is worth a shot. Maybe some complex interaction between Obj-C and C++ comes into play here.
In this diff I also removed `_animationDriver = nullptr` because dealloc will do that automatically.
Reviewed By: philIip
Differential Revision: D32720901
fbshipit-source-id: 227ced2331384c47e8d15a323ee8a621bbb3d179
Summary:
Adding the RCTLog binding to Facebook app. More context is in D30271863 (c317a709d5)
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31299188
fbshipit-source-id: 5234242e2f82262f9d2538e6c689f4a3738f37bb
Summary:
Changelog:
[iOS][Fixed] This is a quick speculative fix since we know `CFRunLoopPerformBlock` does not push/pop an autorelease pool.
Reviewed By: appden
Differential Revision: D32657298
fbshipit-source-id: 4641ad89baf7889ba4bf80e6e64e26de02818cb8
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
a lot of unused code here, cleaning it up
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32640185
fbshipit-source-id: 2917b4e3ea9c08ccb520250de509f0253d5dae61
Summary:
here's a way we can mock C apis - however i am not sure if the flag i'm using is correct
used in D31949237
Changelog:
[General][Added] - add macros to be able to stub C functions in tests
Reviewed By: RSNara
Differential Revision: D31949238
fbshipit-source-id: 0f18a65f810f1b855dbc844f11f5a304c1e5ecea
Summary:
after D32591685, no one is using this. delete
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D32591686
fbshipit-source-id: 11ffb8cbf0fef605b7aefa47347db3ccc6e7d7fe
Summary:
fixing oncall issue: https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
in this diff, we hook up the event emitter onScroll event to the native text input view
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32523146
fbshipit-source-id: d8035deacc8a511577a6fb892ac55c9e07b14392
Summary:
This diff actually adds the usage of ThirdPartyFabricComponentsProvider. We cannot land this until we start using generate-artifacts.js at pod install time.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128889
fbshipit-source-id: 9af39d73c8b5fe3ff9d70190fd83f679914bfd27
Summary:
This reverts commit fcead14b0e.
This should close https://github.com/facebook/react-native/issues/32509 . There was a bug where il8nManager.forceRTL() wouldn't work on app launch, and required an app restart. That was caused by an earlier change (https://github.com/facebook/react-native/pull/31032) which should not be necessary (the deadlock it was attempting to fix was actually caused by separate code).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fixed bug where forceRTL did not work on app launch
Pull Request resolved: https://github.com/facebook/react-native/pull/32574
Test Plan: Simple revert back to previously working code.
Reviewed By: RSNara
Differential Revision: D32315034
Pulled By: GijsWeterings
fbshipit-source-id: dae6c1f0a2481e53f2f1e80f1ac083947681ef99
Summary:
Fixes a build error relating to RCTAlertController import when embedding react-native into existing iOS app. This PR resolves the issue detailed in https://github.com/facebook/react-native/issues/32356
## Changelog
Adjusts the import syntax which was added in:
f319ff321c (diff-56beca6ee071cdd162c269ce765ab12d5af8c8c0ca840bca1e9d1f59e9fab790)
Existing:
#import "RCTAlertController.h"
New:
#import <React/RCTAlertController.h>
[iOS] [Fix] - Fix RCTAlertController import build error when embedded in existing iOS projects
Pull Request resolved: https://github.com/facebook/react-native/pull/32457
Test Plan:
Build this branch in existing iOS project using swift, and should not have the build error described in the issue above.
Would also like to have this fix cherry-pick'd to release 0.63 after merging.
Reviewed By: RSNara
Differential Revision: D31861814
Pulled By: charlesbdudley
fbshipit-source-id: e60f80c8ea982e400cbf6d9375037d4197bbb8a3
Summary:
FBReactNativeSpecs.podspec is currently only acting as a config for codegen. It should not include any sources. This would fix unintended build error related to FBReactNativeSpecs-generated file.
Changelog: [internal]
Reviewed By: philIip
Differential Revision: D32267102
fbshipit-source-id: 27b510198666dc26a890cd7a6f873a04a9df66ca
Summary:
This pull request aims to remove iOS 11 availability check which is no longer needed.
The minimum iOS deployment target for React Native is iOS 11 but we still have iOS 11 version check like below.
```
if (available(iOS 11.0, *)) {
```
This is a continuation pull request of https://github.com/facebook/react-native/pull/32151
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Remove iOS 11 availability check
Pull Request resolved: https://github.com/facebook/react-native/pull/32488
Reviewed By: yungsters
Differential Revision: D32006312
Pulled By: ryancat
fbshipit-source-id: 0ee6579e433a15d3d220a52d2ccd6931b0513971
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Fixes https://github.com/facebook/react-native/issues/32434: RCTLogBox window is orphaned, covering entire screen.
After this change, the logbox window once again is removed from the screen.
## Changelog
Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - 32434
Pull Request resolved: https://github.com/facebook/react-native/pull/32435
Test Plan:
1. Use console.warn to generate a yellow warning message in log box. Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2. click the log
3. tap "dismiss"
4. try to tap anywhere
5. Use Xcode view debugger to inspect the UI state
## Expected
The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen
Reviewed By: philIip
Differential Revision: D31794242
Pulled By: sshic
fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
Changelog: [Internal]
these are returning bools for some reason even though no one is using the returned value. changing them to return void
Reviewed By: RSNara
Differential Revision: D31594241
fbshipit-source-id: 04c115b573b74996eaf2fef631eedb12c6734ea8
Summary:
Changelog: [Internal]
`start` and `stop` are already part of `RCTSurfaceProtocol` which is a public protocol conformance, we don't need to add these to this header, it's just extra work for the compiler
Reviewed By: RSNara
Differential Revision: D31776005
fbshipit-source-id: d89ad4dbe35e1b67cfa750c6414c40f9b4fc7f24
Summary:
Changelog: [Internal]
making these imports a little more optimal & clean
Reviewed By: javache
Differential Revision: D31594240
fbshipit-source-id: 076610454a6f3c35ac58e97bd9f887b05b86f5bb
Summary:
This issue is found when investigating T101563978 with IOS platform. When animation is off, the x position measurement is off after `scrollToItem` is called.
The android fix is checked in at D31492685 (1a9e2d5d55). For IOS, the correct state data is updated only for animated cases, but not for instant scroll cases. This diff unified them.
Changelog
[IOS][Fixed] Fixed an edge case when scroll to item/index is called without animation, the offset position is not updated. This caused the measurement of the position to be wrong.
Reviewed By: sammy-SC
Differential Revision: D31564169
fbshipit-source-id: 89f47d8054afb03c2ace1d595163b160e5bb2036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32247
I don't think we need both libc++ and libstdc++.
allow-large-files
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30950943
fbshipit-source-id: d0669815ff59c3e9ac45954a4a11930d1bc3959f
Summary:
changelog: [internal]
calling `setEnabled(true)` needs to have a matching `setEnabled(false)` in order for `eventTarget_` to be deallocated correctly.
Also, retaining `eventTarget_` longer, does not mean instanceHandle will be available later on.
Reviewed By: p-sun
Differential Revision: D31503119
fbshipit-source-id: 324e16fe0f6ad937ab2c38be9a536bdf14851172
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
Changelog: [Internal]
https://fb.workplace.com/groups/rn.support/posts/6677051292343429
ax team is building a tool to extract information about the views for design reviewers, and RN has some AX information that is not working atm because of dependency on whether voiceover is on or not. so, this will give them the ability to programmatically set that field and hopefully be able to get accurate ax info
Reviewed By: ikenwoo
Differential Revision: D31010566
fbshipit-source-id: 4c8a33fce40266b270dd5994442c8472ca88f5dd
Summary:
Original commit changeset: 9ccfb4b6d477 / D30015799 (6e903b07fa)
The diff caused a redbox/error in some products. Reverting now and will try it again.
Changelog: Backing out PR: 31402
Differential Revision: D31238961
fbshipit-source-id: b2ccd3d3ab9d7e764e41fb54d8a7e60882d1405f
Summary:
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D30015799
Pulled By: sota000
fbshipit-source-id: 9ccfb4b6d477da192a96db4cfa07c31a2d2cefcb
Summary:
Original commit changeset: 2acd52ae5873
This original change was made in D26705430 (b08362ade5) and D26705429 (69feed518d). The intention was to change the timestamp definition to make touch telemetry easier, but this is (1) unnecessary and (2) causes other issues.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D31183734
fbshipit-source-id: 6af669bb5696896b43fa4508af1171446d62c6d6
Summary:
Changelog: [Internal]
in this diff, we add a function that allows us to retrieve screen scale. enforcing thread safety will be dependent on the consumer to make sure it's used on main thread.
i'd like for this to be a more temporary solution, i think we should have a more scalable screen solution for consumers to handle the gambit of uiscreen use cases.
Reviewed By: sammy-SC
Differential Revision: D31163909
fbshipit-source-id: 78104e9ef982b47c60697461141afb4b06eede72
Summary:
Changelog:
[iOS][changed] - fixed inaccurate comment
while looking around, i saw this comment for RCTScreenSize that says it's called on app start - i looked around and also put a breakpoint here, and this assumption doesn't seem accurate anymore. just updating the comment for clarity.
Reviewed By: sammy-SC
Differential Revision: D31136182
fbshipit-source-id: 5f02a1a9fd95e16495bb79b3645b5f4e3bc1d9c9
Summary:
nowadays, we could only specify metro server by either dev settings or building time ip.txt.
this pr adds a new way to specify metro server programmatically which makes rn launcher or testing more feasible.
## Changelog
[Internal] [iOS] [Added] - Propose to connect metro server programmatically
Pull Request resolved: https://github.com/facebook/react-native/pull/31828
Test Plan:
just exposing a public interface for RCTPackagerConnection without much code change.
test to call this interface success locally.
Reviewed By: sammy-SC
Differential Revision: D30878774
Pulled By: yungsters
fbshipit-source-id: 5f1d6a4835a983abde7e095d20153e4ba2146a61
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
`isPackagerRunning` check on iOS makes a http request to packager's /status endpoint to check if it's alive... The problem is if the packager can't be reached, but doesn't error out immediately. This can happen, for example, if running the app on device, and host computer's firewall doesn't allow a :8081 connection. In that case, the request will never succeed or fail until default timeout of 60s. It makes debugging the underlying issue quite unbearable. It's hard for me to imagine a legitimate packager connection that wouldn't respond in less than a second, so I propose a conservative timeout of 10s
## Changelog
[iOS] [Fixed] - Don't hang app for 60s if packager can't be reached
Pull Request resolved: https://github.com/facebook/react-native/pull/31367
Test Plan: Checked my app in dev mode to see if packager connects properly.
Reviewed By: sammy-SC
Differential Revision: D30912047
Pulled By: charlesbdudley
fbshipit-source-id: 110743dc45b9cc7d30e49f79ce3b0d5986f7aebd
Summary:
We observed that in certain production scenarios, `[UIFont fontNamesForFamilyName:familyName]` returns `nil`.
This is problematic because we cannot insert `nil` (which is not an object type) into `NSCache`. Currently, this is causing `NSInvalidArgumentException` to be thrown.
This fix works around the problem by guarding against `nil`.
Changelog:
[iOS][Fixed] - Fix NSInvalidArgumentException for invalid font family names.
Reviewed By: fkgozali
Differential Revision: D31011394
fbshipit-source-id: a9eb9ce69efd832acca65787c665fcbb7b42a795
Samuel Susla
Sota Ogo
Christoph Purrer
Phillip Pan
CodemodService FBSourceClangFormatLinterBot
Paige Sun
Saad Najmi
Nick Fujita
Liron Yahdav
Ken Tominaga
Andrew Rahn
Xin Chen
Neil Dhar
Lulu Wu
Brent Kelly
Marc Rousavy
Joshua Gross
Muhammad Numan
Kudo Chien
Pieter De Baets
Radek Pietruszewski
Ramanpreet Nara
Tim Yung
