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:
When there are multiple sticky headers, ScrollViewStickyHeader should push up the header above it when it gets to the top.
This behavior was accidentally changed in D21948830 (https://github.com/facebook/react-native/commit/fa5d3fb6b8c561b749f3e86316d06543a52dcc1c) when this component was fixed to work in Fabric.
This diff added a new variable `_shouldRecreateTranslateY`, which determines whether the `translateY` value should be recreated on render. `_shouldRecreateTranslateY` was not being set to true during `setNextHeaderY`, so the next header's Y value was never accounted for at render.
Changelog:
[General][Fixed] Fix ScrollViewStickyHeader to push up header above it
Reviewed By: lunaleaps
Differential Revision: D27277829
fbshipit-source-id: 83c9aacd454be178649bf8d060d1a5c750f4060f
Summary:
This diff refactors the UIManagerHelper.getUIManager method to return null when there's no UIManager registered for the uiManagerType received as a parameter.
This is necessary to workaround: https://github.com/facebook/react-native/issues/31245
changelog: [changed] UIManagerHelper.getUIManager now returns null when there's no UIManager registered for the uiManagerType received as a parameter
Reviewed By: fkgozali
Differential Revision: D28242592
fbshipit-source-id: c3a4979bcf6e547d0f0060737e41bbf19860a984
Summary:
Hermes has a way to set up a callback that is invoked when a fatal error
such as Out of Memory occurs. It is a static API that should be called at
most once, so it uses `std::call_once` to achieve that.
The fatal error handler is simple, it just uses glog to log an error message
to logcat, then aborts (using `__android_log_assert`).
The reason is typically very helpful for understanding why `hermes_fatal` was called.
Changelog:
[Android][Internal] - Print a logcat message when Hermes has a fatal error
Reviewed By: mhorowitz
Differential Revision: D25792805
fbshipit-source-id: 45de70d71e9bd8eaa880526d8835b4e32aab8fe3
Summary:
Currently the dimensions are created once, and then cached. This change will reload the dimensions when the device orientation changes to insure that dimension update events follow orientation changed events.
this should help address the following issues, that I know of:
https://github.com/facebook/react-native/issues/29105https://github.com/facebook/react-native/issues/29451https://github.com/facebook/react-native/issues/29323
## 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
-->
[Android] [Fixed] - Dimension update events are now properly sent following orientation change
Pull Request resolved: https://github.com/facebook/react-native/pull/30324
Test Plan: Open up RNTester app. Select the Dimensions API list item. Rotate the device and verify that the dimensions are correct based on orientation.
Reviewed By: fkgozali
Differential Revision: D24874733
Pulled By: ejanzer
fbshipit-source-id: 867681ecb009d368a2ae7b67d94d6355e67dea7b
Summary:
This pr fixes: https://github.com/facebook/react-native/issues/30123 .
When secureTextEntry is true, setInputType will set the inputType of textInput to password type.
Password type default font-family will be monospace font, so we need to setTypeface after the setInputType.
## Changelog
[Android] [Fixed] - Font family is not apply when secureTextEntry is true.
Pull Request resolved: https://github.com/facebook/react-native/pull/30164
Test Plan:
Before this pr:
After this pr:
Please initiated a new project and replaced the App.js with the following code:
```
iimport React from 'react';
import {SafeAreaView, TextInput} from 'react-native';
const App = () => {
return (
<SafeAreaView>
<TextInput
id={'email'}
placeholder={'Email'}
secureTextEntry={false}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
<TextInput
id={'password'}
placeholder={'Password'}
secureTextEntry={true}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
</SafeAreaView>
);
};
export default App;
```
Thanks you so much for your code review!
Reviewed By: cpojer
Differential Revision: D24686222
Pulled By: hramos
fbshipit-source-id: 863ebe1dba36cac7d91b2735fe6e914ac839ed44
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.
Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293
Reviewed By: lunaleaps
Differential Revision: D25507604
fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
Since iOS 14 refresh control is sometimes visible when it shouldn't. It seems to happen when it is removed and added back to the window. This repros easily when using react-native-screens with react-navigation tabs. Inactive tabs are detached from the window to save resources.
Calling endRefreshing when refresh control is added to the window fixes the layout. It will also be called on first mount where it is not necessary, but should be a no-op and didn't cause any issues. I also decided to call it for all ios versions, although it is only needed on iOS 14+ to avoid forking behavior more.
## Changelog
[iOS] [Fixed] - Fix RefreshControl layout when removed from window
Pull Request resolved: https://github.com/facebook/react-native/pull/31024
Test Plan:
Before:
https://user-images.githubusercontent.com/2677334/108666197-93ea5a80-74a4-11eb-839b-8a4916967bf8.mov
After:
https://user-images.githubusercontent.com/2677334/108666223-9ea4ef80-74a4-11eb-8489-4e5d257299c8.mov
Reviewed By: shergin
Differential Revision: D26590759
Pulled By: PeteTheHeat
fbshipit-source-id: b8c06068a24446b261cbeb88ff166289724031f1
Summary:
allow-large-files
RN Tester is using an old version of Flipper. This will help testing regressions in the latest version (which is installed when starting a new project). This also fixes an issue where libevent is incompatible between the one in flipper and when using hermes on iOS. To fix it I changed to use the version published on cocoapods instead of using a local podspec (see https://github.com/facebook/flipper/issues/1916).
[General] [Changed] - Update flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/31010
Test Plan:
- Tested that RN tester builds and flipper works with hermes enabled / disabled and fabric on iOS
- Tested that RN tester builds and flipper works on Android
Reviewed By: fkgozali
Differential Revision: D26592317
Pulled By: PeteTheHeat
fbshipit-source-id: 2cd278c7a51b1859dab0465846b061221f07d3f6
Summary:
Currently, Codegen bash wrapper (`generate-specs.sh`) for Xcode invokes JS-based Codegen tooling via `yarn --silent node <...>`. This breaks both:
- when Yarn is not installed (if NPM is used), for obvious reasons
- when Yarn v2 ("Berry") is active
This PR changes the way `generate-specs.sh` locates `node` executable to the following algorithm:
- use the path provided in the `NODE_BINARY` env var
- if `NODE_BINARY` env var is not defined, find `node` with `command -v node`
## Changelog
[iOS] [Fixed] - Fix Codegen silently failing when Yarn is not installed, or when Yarn v2 is active.
Pull Request resolved: https://github.com/facebook/react-native/pull/30781
Test Plan:
### Case 1 (no Yarn installed)
1. Ensure `yarn` is not present in PATH
2. Run Xcode build
3. Check that Codegen artifacts are produced
### Case 2 (Yarn v2 is used)
1. Ensure `yarn` is running in the v2 ("Berry") mode
2. Run Xcode build
3. Check that Codegen artifacts are produced
Reviewed By: fkgozali
Differential Revision: D26187081
Pulled By: hramos
fbshipit-source-id: 77d3089f523b8c976d8223b77ff9553cb6cf68a5
Summary:
This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS.
1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly.
2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file.
3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups.
4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not.
[iOS] [Fixed] - Make codegen more reliable on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/30792
Test Plan:
Tested various project states to make sure the build always succeeds in RN tester:
- Simulate fresh clone, remove all ignored files, install pods, build
- Build, delete FBReactNativeSpec generated files, build again
- Build, build again, make sure FBReactNativeSpec is cached and not rebuilt
- Make the script fail and check that xcode shows the script error logs properly
Note: Did not test fabric
Reviewed By: fkgozali
Differential Revision: D26104213
Pulled By: hramos
fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
Summary:
The codegen helper script, `generate-specs.sh`, is being used to generate code for the FBReactNativeSpec and React-Fabric/rncore pods. The script now supports overriding several defaults by setting the following environment variables:
- SRCS_DIR: Path to JavaScript sources, defaults to $RN_DIR/Libraries/
- LIBRARY_NAME: Defaults to FBReactNativeSpec
- MODULES_OUTPUT_DIR: Defaults to Libraries/$LIBRARY_NAME/$LIBRARY_NAME
- COMPONENTS_LIBRARY_NAME: Defaults to rncore
- COMPONENTS_OUTPUT_DIR: Defaults to ReactCommon/react/renderer/components/$COMPONENTS_LIBRARY_NAME
The CocoaPods codegen integration has been updated to take advantage of these.
**Example CocoaPods usage:**
```
# packages/rn-tester/NativeModuleExample/RNTesterSpecs.podspec
Pod::Spec.new do |s|
s.name = "RNTesterSpec"
# ...
use_react_native_codegen!(s, { :srcs_dir => __dir__, :modules_output_dir => __dir__ })
end
```
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25738466
fbshipit-source-id: c68f5a3cd0996283a7af287e992e2f973024f44c
Summary:
Consolidate CocoaPods codegen scripts under a single `use_react_native_codegen!` method in `react_native_pods.rb`.
This is the first step towards making the codegen scripts library-agnostic. There are still a handful of hardcoded assumptions in place (e.g. the output directory structure, the use of a separate directory for components), but with some work one would be able to add codegen support to arbitrary CocoaPods podspecs.
The codegen script no longer takes a CODEGEN_PATH argument, and will instead attempt to use the local react-native-codegen package if available, and fallback to using the node_modules/react-native-codegen package if not.
## Usage
The `use_react_native_codegen!` method has two arguments:
- `spec`, a pod [Specification](https://www.rubydoc.info/github/CocoaPods/Core/Pod/Specification) object.
- `options`, an optional object. Supported keys:
- `:srcs_dir`, the path to your JavaScript sources. Your native module or component specs should be located somewhere in this directory.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25728053
fbshipit-source-id: feec587b656d5b220598ce6196ea6bb34a9580a9
Summary:
Original PR contents:
This pull request updates the Podspecs and associated build scripts, and some source files so they build on OSS. RNTester now compiles with `fabric_enabled` again.
The following changes have been made:
* Various spots that were pointing to the old `ReactCommon/fabric` location have now been updated to `ReactCommon/react/renderer`
* Files that were attempting to use internal FB header `FBRCTFabricComponentsPlugins.h` were changed to use `RCTFabricComponentsPlugins.h`
* `RCTFabricComponentsPlugins` in OSS was updated to include the `Image` fabric component (thanks tsapeta)
* Replaced old `generate-rncore.sh` build script with new `generate-rncore.js` script which does not require `flow-node` and uses the `react-native-codegen` API directly, so there is no longer any need for an interim `schema-rncore.json` file.
* Updated Yoga podspec which wasn't fully synced with changes from the main Yoga repo
* Updated Fabric podspec with additional needed subspecs
Additions to PR by hramos:
* Replaced use of generate-rncore scripts with the original generate-native-modules-specs.sh script, which is now generate-specs.sh and supports both codegen for Native Modules and Components now (TurboModules/Fabric).
* Codegen now runs at build time as part of the Xcode build pipeline instead of as part of `pod install`. The build script is injected by the FBReactNativeSpec pod, as the pod is part of both Fabric and non-Fabric builds.
[General] [Fixed] - RNTester compiles with `fabric_enabled` again
Pull Request resolved: https://github.com/facebook/react-native/pull/29810
Test Plan:
RNTester now compiles and runs in the simulator again when `fabric_enabled` is set to `true`.
```
cd xplat/js/react-native-github/packages/rn-tester
USE_FABRIC=1 pod install
open RNTesterPods.xcworkspace
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
This is an extension of https://github.com/facebook/react-native/issues/29798 which was reverted due to cases where the soft keyboard could not be dismissed.
## 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
-->
[General] [Fixed] - Avoid eating clicks/taps into ScrollView when using physical keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/30374
Test Plan: Validated with iOS simulator that taps on default ScrollView will dismiss soft keyboard and be eaten if open, but taps are not eaten when emulating a connected physical keyboard.
Reviewed By: kacieb
Differential Revision: D24935077
Pulled By: lyahdav
fbshipit-source-id: 19d9cf64547e40a35f9363896e3abbdccb95b546
Summary:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.
It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h added in https://github.com/microsoft/react-native-windows/pull/6804.
## Changelog
[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h
Pull Request resolved: https://github.com/facebook/react-native/pull/30672
Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.
I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```
Reviewed By: mdvacca
Differential Revision: D25758927
Pulled By: fkgozali
fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
Summary:
When building React Native application in Release mode for an iPhone Simulator _and_ targeting `armv7`, Xcode will build all architectures (due to `ONLY_ACTIVE_ARCH` set to `false`, unlike in Debug mode). As a result, Xcode will try building for `i386` (32-bit iPhone Simulator), which fails as we don’t build Hermes binaries for `i386`.
Fix is to disable `i386`, since it is not supported by `Hermes` and certain `Folly` features.
## Changelog
[IOS] [BREAKING] - `i386` architecture will be automatically disabled when Hermes is being used. This might be potentially breaking for your workflow if you target `armv7` devices, as you will no longer be able to test on the simulator.
[IOS] [FEATURE] - Replace `flipper_post_install` with `react_native_post_install` hook. Will automatically detect if Flipper is enabled.
Pull Request resolved: https://github.com/facebook/react-native/pull/30592
Test Plan: Run React Native application with Hermes enabled (or Flipper) in Release mode and it should work just fine.
Reviewed By: appden
Differential Revision: D25564738
Pulled By: TheSavior
fbshipit-source-id: e786ab73fb0a77de5869cf9e5999726c7d29f1d4
Summary:
Fixes https://github.com/facebook/react-native/issues/29984
Right now, running a React Native application with Xcode 12 in Release mode on an iPhone Simulator will fail with something like below:
> [some file path], building for iOS Simulator, but linking in object file built for iOS, file '[some file path]' for architecture arm64
The best explanation of this issue has been provided by alloy in https://github.com/facebook/react-native/issues/29984:
> This issue has started coming up with Xcode 12 and support for the new ARM based Macs, as `arm64` now no longer can be assumed to _only_ be for iOS devices. This means Xcode 12 will now also build for `arm64` simulator SDKs and it has become ambiguous if an arch slice in a prebuilt binary is meant for a simulator or device.
>
> In any case, for now this means that you can configure your Xcode project to exclude `arm64` when building for any iOS simulator SDK.
This PR implements aforementioned workaround.
## Changelog
[FIX] [IOS] - Fix running React Native project with Xcode 12 in Release on iPhone Simulator
Pull Request resolved: https://github.com/facebook/react-native/pull/30543
Test Plan: Switch your scheme to Release and run the app on simulator. Will complete w/o issues.
Reviewed By: appden
Differential Revision: D25537295
Pulled By: TheSavior
fbshipit-source-id: 2dc05cb80e59f1d95d2a84ab55ed6a5b5446411c
Summary:
Recently introduced steps to run Hermes accidentally removed `!` from the `use_react_native`, causing `pod install` to fail with an error.
## Changelog
[INTERNAL] [iOS] - Fix Podfle in default template
Pull Request resolved: https://github.com/facebook/react-native/pull/30571
Test Plan: Run `pod install` with this file and it should work.
Reviewed By: appden
Differential Revision: D25537263
Pulled By: TheSavior
fbshipit-source-id: da7f21775cbe641e34aded87a92c696539f4d5c3
Nicola Corti
Lorenzo Sciandra
Bartosz Kaszubowski
Luna Wei
Brent Kelly
Lorenzo Sciandra
Dulmandakh
Kacie Bawiec
David Vacca
Riley Dulin
ajpaulingalls
Hank Chen
Neal Poole
Mike Grabowski
Janic Duplessis
Ivan Moskalev
Héctor Ramos
empyrical
Nick Gerleman
Vladimir Morozov
Jayme Deffenbaugh
Samuel Susla
