Summary:
I guess it's the same since we're working on a `bool` but... this causes some compilation error.
Changelog:
[General][iOS] - Fix compilation warning in yoga
Reviewed By: Andrey-Mishanin
Differential Revision: D35438992
fbshipit-source-id: 22bb848dfee435ede66af0a740605d4618585e18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36577
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change allows us to strip CustomStyleSpan. We already set all but `fontVariant` on the underlying EditText, so we just need to route that through as well.
Note that because this span is non-parcelable, it is seemingly not subject to the buggy behavior on Samsung devices of infinitely cloning the spans, but non-parcelable spans have different issues on the devices (they disappear), so moving `fontVariant` to the top-level makes sense here.
Changelog:
[Android][Fixed] - Minimize EditText Spans 8/N: CustomStyleSpan
Reviewed By: javache
Differential Revision: D44297384
fbshipit-source-id: ed4c000e961dd456a2a8f4397e27c23a87defb6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36576
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change addresses some minor CR feedback and removes the temporary list of spans in favor of applying them directly.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D44295190
fbshipit-source-id: bd784e2c514301d45d0bacd8ee6de5c512fc565c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36548
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change lets us set `letterSpacing` on the EditText instead of using our custom span.
Changelog:
[Android][Fixed] - Minimize EditText Spans 6/N: letterSpacing
Reviewed By: rshest
Differential Revision: D44240777
fbshipit-source-id: 9bd10c3261257037d8cacf37971011aaa94d1a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36544
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change makes us apply strikethrough and underline as paint flags to the underlying EditText, instead of just the spans. We then opt ReactUnderlineSpan and ReactStrikethroughSpan into being strippable.
This does actually create visual behavior changes, where child text will inherit any underline or strikethrough of the root EditText (including if the child specifies `textDecorationLine: "none"`. The new behavior is consistent with both iOS and web though, so it seems like more of a bugfix than a regression.
Changelog:
[Android][Fixed] - Minimize Spans 5/N: Strikethrough and Underline
Reviewed By: rshest
Differential Revision: D44240778
fbshipit-source-id: d564dfc0121057a5e3b09bb71b8f5662e28be17e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36545
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds ReactForegroundColorSpan to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 4/N: ReactForegroundColorSpan
Reviewed By: javache
Differential Revision: D44240780
fbshipit-source-id: d86939cc2d7ed9116a4167026c7d48928fc51757
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36547
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds `ReactBackgroundColorSpan` to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 3/N: ReactBackgroundColorSpan
Reviewed By: javache
Differential Revision: D44240782
fbshipit-source-id: 2ded1a1687a41cf6d5f83e89ffadd2d932089969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36546
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change generalizes `stripAttributeEquivalentSpans()` to allow plugging in different spans.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D44240781
fbshipit-source-id: 89005266020f216368e9ad9ce382699bd8db85a8
# Conflicts:
# ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36543
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
We cache the backing EditText span on text change to later measure. To measure outside of a TextInput we need to restore any spans we removed. Spans may overlap, so base attributes should be behind everything else.
The logic here for dealing with precedence is incorrect, and we should instead accomplish this by twiddling with the `SPAN_PRIORITY` bits.
Changelog:
[Android][Fixed] - Minimize Spans 1/N: Fix precedence
Reviewed By: javache
Differential Revision: D44240779
fbshipit-source-id: f731b353587888faad946b8cf1e868095cdeced3
Summary:
D42721684 (https://github.com/facebook/react-native/commit/be69c8b5a77ae60cced1b2af64e48b90d9955be5) left a pretty bad bug when using Fabric for Android. I missed that in Fabric specifically, on edit we will cache the Spannable backing the EditText for use in future measurement.
Because we've stripped the sizing spans, Spannable measurement has incorrect font size, and the TextInput size will change (collapsing) after the first edit. This effectively breaks any uncontrolled TextInput which does not have explicit dimensions set.
Changelog:
[Android][Fixed] - Fix measurement of uncontrolled TextInput after edit
Reviewed By: sammy-SC
Differential Revision: D43158407
fbshipit-source-id: 51602eab06c9a50e2b60ef0ed87bdb4df025e51e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
`JNIEnv`'s `FindClass(..)` function takes the classes in the standard
`foo/bar/Baz` class specification (unless they're special, like arrays).
Specifying them with `Lfoo/bar/Baz;` results in a
`ClassNotFoundException` being raised -- which is especially unhelpful
when intending to re-throw an exception.
The docs for `JNIEnv#FindClass(..)` can be found [here][jnienv].
[jnienv]:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#:~:text=The%20name%20argument,java/lang/String%22
## Changelog
[Android] [Fixed] - Correctly resolve classes with FindClass(..)
Pull Request resolved: https://github.com/facebook/react-native/pull/34533
Test Plan:
No exact test plan. However, if an exception is thrown during the
rendering process, a fatal `ClassNotFoundException` is raised, rather
than having the error be passed up to the `ReactNativeManager`.
Fixes: facebook/yoga#1120
Reviewed By: amir-shalem
Differential Revision: D39133326
Pulled By: jacdebug
fbshipit-source-id: 86283b7d21aed49ed0e9027b2aef85f0108cdf9a
Summary:
With react-native 0.70-rc.3 and new arch, codegen may fail if it encounters `.d.ts` files because specs may appear to be unused.
## Changelog
[General] [Fixed] - Codegen should ignore `.d.ts` files
Pull Request resolved: https://github.com/facebook/react-native/pull/34439
Test Plan:
See repro in https://github.com/microsoft/react-native-test-app/pull/1052. The build will fail without manually patching this in.
If you prefer to use your own test app, try adding [react-native-safe-area-context](https://github.com/th3rdwave/react-native-safe-area-context) as a dependency.
Reviewed By: cipolleschi
Differential Revision: D38826388
Pulled By: cortinico
fbshipit-source-id: eb7c9be2d49286bae86b2428862fbf20f6f32ca5
Summary:
This fix solves a problem very well evaluated [here](https://github.com/Expensify/App/issues/2727) as well as this [one](https://github.com/facebook/react-native/issues/29290).
The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app.
I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening:
1. iPad is in landscape.
2. We move the app to inactive state.
3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1).
4. We restore the app to active state.
5. The app receives two queued orientation change events, one after another.
6. The quick transition between portrait and landscape happens even though it never went back to portrait.
Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro
Video presenting the issue (recorded while working on: https://github.com/Expensify/App/issues/2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4
<!-- 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] - Fix the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive
Pull Request resolved: https://github.com/facebook/react-native/pull/34014
Test Plan:
1. Make sure you have a working version of E/App.
2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line:
`this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);`
to
`this.onDimensionChange = this.onDimensionChange.bind(this);`
3. Open the NewExpensify.xcodeproj in xCode.
4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR.
5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode.
6. From this point you can move to the test scenarios described below.
Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo
Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g
**Test 1:**
1. Launch app in portrait, open chat - no sidebar visible.
7. Switch to landscape - sidebar shows.
8. Put app to background.
9. Put app back to foreground - make sure the side menu doesn't flicker.
**Test 2:**
1. Launch app in portrait, open chat - no sidebar visible.
2. Switch to landscape - sidebar shows.
3. Put app to background. Switch orientation back to portrait.
4. Put app back to foreground - make sure the side menu hides again as it should be in portrait.
Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg
iPad mini test 1 applies.
Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always.
**Test 3:**
1. launch the app.
2. Make sure you're in landscape mode.
3. See split screen with some other app. Make sure the side bar is visible.
4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it.
10. Move the app to background and back to foreground, please observe there are no flickers.
**Test 4:**
1. Launch the app.
2. Make sure you're in landscape mode.
3. Make the multitasking view and make Expensify app a slide over app.
4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly
5. Move the app to background and back to foreground, please observe there are no flickers.
Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk
Please perform standard smoke tests on transformation changes.
Reviewed By: cipolleschi
Differential Revision: D37239891
Pulled By: jacdebug
fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf
Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.
The code snippet in **ReactInstanceManager** for adding a new setter method:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
The code snippet for the new logic in **ReactInstanceManagerBuilder**:
1) Setting up the new logic:
Adding a new enum class :
```
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
.setApplication(this)
.setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
.setBundleAssetName("index.android.bundle")
.setJSMainModulePath("index")
```
where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:
`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then
```
defaultConfig{
if(enableHermes) {
buildConfigField("boolean", "HERMES_ENABLED", "true")
}
else{
buildConfigField("boolean", "HERMES_ENABLED", "false")
}
}
```
Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.
This change can possibly solve many of the issues listed in the list as it solved ours.
## Changelog
[GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package:
```
/**
* An enum that specifies the JS Engine to be used in the app
* Old Logic uses the legacy code
* JSC/HERMES loads the respective engine using the revamped logic
*/
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:
```
private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC;
```
[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33952
Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO
Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
if (enableHermes) {
exclude "**/libjsc*.so"
}
}
```
Reviewed By: lunaleaps
Differential Revision: D37191981
Pulled By: cortinico
fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
As per commit: https://github.com/facebook/react-native/commit/4f3b17412018a10f9293247c802598d2b94a844b which states that "React Native requires that the RootView id be managed entirely by React Native, and will crash in addRootView/startSurface if the native View id isn't set to NO_ID."
This behaviour can not be guaranteed in **hybrid** apps that have a native android layer over which ReactRootViews are added and the native views need to have ids on them in order to work. **The control of views can jump back and forth between native android and react-native (fabric). As the ReactRootView is added to ViewGroups (or layouts) in Android Fragments and Activities, they contain ids on their views which might get passed down to the reactRootView by features like DataBinding**
Hence this can cause unnecessary crashes at runtime for hybrid apps even when they are not changing the id of the reactRootView object they are adding to their ViewGroups.
Our app is a hybrid app that uses both native android and react-native on different screens and on one such screen that has a Fragment adding a ReactRootView to its FrameLayout to render native android views to render in ReactNative, this crash occurs on pressing the back button as well as on unlocking the screen while staying on the same screen.
The app was running fine on more than a 100 million devices on React Native 0.63.4 but after updating to 0.67.2, that features this commit, it crashes on the very first device it was tested on.
Refer to the issue: https://github.com/facebook/react-native/issues/33121 for more information on the crash
The fragment in which this issues arises is like this:
```binding.frameLayout.addView(getReactRootView())```
where getReactRootView() is like this:
```
private var mReactRootView: ReactRootView? = null
private var mReactInstanceManager: ReactInstanceManager? = null
mReactRootView = ReactRootView(context)
if (activity != null) {
val application = activity?.application
if (application is MainApplication) {
mReactInstanceManager = application.reactInstanceManager
}
}
fun getReactRootView():View?{
return mReactRootView
}
```
So converting this to a soft exception such that pure react-native devs can still see the error while hybrid apps continue to run without crashes.
### Snippet of the change:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
## Changelog
[GENERAL] [ADDED] - A ReactSoftException log instead of a direct exception being thrown:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
[GENERAL] [REMOVED]- Directly throwing an exception even when the code is not responsible for this issue:
```
if (getId() != View.NO_ID) {
throw new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID.");
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33133
Test Plan:
This crash is hard to reproduce but when it occurs, this is the only way to fix it.
If any app used to crash with this exact error, it will no longer crash but show an error log in Logcat for developers to be informed about the issue.
Reviewed By: ShikaSD
Differential Revision: D34304212
Pulled By: cortinico
fbshipit-source-id: f0eaeef2e905a6e0587df088b43cc49cabda397a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33611
Bumping the NDK to 23 to prevent build failures due to the NDK
using longer paths.
Changelog:
[Android] [Fixed] - Use NDK 23 only for Windows users.
Reviewed By: motiz88
Differential Revision: D35547459
fbshipit-source-id: 4e44c0b5fd8d1c559b04fb43eb4eeadc13943394
Summary:
This adds an unnecessary dependency between two NPM package which can be avoided. See https://github.com/reactwg/react-native-releases/discussions/17#discussioncomment-2452813
for context.
Changelog:
[Internal] [Changed] - react-native-gradle-plugin should not depend on react-native-codegen NPM package
Reviewed By: dmitryrykun
Differential Revision: D35279729
fbshipit-source-id: f18f79809f115f28203ac0a843fafead63528904
Summary:
It is not necessary to call node via yarn. Instead with this commit node is called directly (windows aware). This enables builds on systems that don't have yarn installed.
Fixes https://github.com/facebook/react-native/issues/33525
## Changelog
[Android] [Fixed] - Don't require yarn for codegen tasks
Pull Request resolved: https://github.com/facebook/react-native/pull/33530
Test Plan:
1. react-native init test
2. cd test
3. enable newArchEnabled=true (gradle.properties)
4. enable enableHermes: true (build.gradle)
5. react-native run-android (when the yarn is not installed on the system)
(I have not tested or verified if this works on windows build machines)
Reviewed By: sshic
Differential Revision: D35279376
Pulled By: cortinico
fbshipit-source-id: 430e4a7bcdec7d5377efac747f6b935d634451cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33581
We currently have some code on the RN Gradle Plugin that we need to ship.
There are both bugfixes needed for RN 0.68.1 and for the current nightly
(therefore needed for RN 0.69).
I've verified that this works on a fresh RN 0.68.0 install with `npm pack`
and triggering a build on a fresh setup from app template, with newArchEnabled set to true.
Changelog:
[Android] [Changed] - Bump React Native Gradle plugin to 0.0.6
Reviewed By: rubennorte
Differential Revision: D35439444
fbshipit-source-id: 662b2211c44b261e3e3c9cddc946107cfb495c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588
Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.
This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468252
fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
Summary:
As users can toggle `enableSeparateBuildPerCPUArchitecture` to create a split APK, once that is off, the `-PreactNativeArchitecture` is not correctly considered when building the local module.
This will make sure that, if users have `enableSeparateBuildPerCPUArchitecture` set to `false`, their
app is building the local `app_modules` only for the requested architectures.
Practically, users invoking with `--active-arch-only` might experience a build failure if they have a fully clean environment (would be forced to do a full build before using `--active-arch-only`). This addresses this scenario.
Changelog:
[Android] [Fixed] - Template: Specify abiFilters if enableSeparateBuildPerCPUArchitecture is not set.
Reviewed By: ShikaSD
Differential Revision: D35250700
fbshipit-source-id: 4e555888636cf182495fab2b4a562d93a70b9e66
Summary:
This PR fixes RTTI (run-time type information) for ShadowNodeWrapper and ShadowNodeListWrapper classes, i.e., calls to dynamic_cast and dynamic_pointer_cast that are called via JSI's getHostObject calls.
The fix is simply to add a so-called "key function" in a form of virtual destructor. Key functions needs to be a virtual non-pure and non-inlined functions that points the compiler as to which library contains the vtable/type information for a given class (see https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable and https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries)
Without the "key function", calls to dynamic_cast for ShadowNodeWrapper instances won't work across library boundaries because the class will have separate definitions in each separate library, therefore objects created in one of those libraries won't be recognized as the same type by the other library. This has been a problem in reanimated and gesture-handler libraries where we call `object.getHostObject<ShadowNodeWrapper>(rt)` (this is a method from JSI) in order to access ShadowNode instance from a handle we have in JS. I think, this issue is going to be relevant to more libraries that cope with view instances. In this scenario, we have a separate library, say "libreanimated.so" that calls to `getHostObject` which is an inline function that calls `dynamic_cast` for the `ShadowNodeWrapper` class. On the other hand, the instances of `ShadowNodeWrapper` are created by the code from `libreact_render_uimanager.so`. Because of that `dynamic_cast` fails even though it is called on instance of `ShadowNodeWrapper` because the class has separate vtable/type info: one in `libreanimated.so` and one in `libreact_render_uimanager.so` (by "fails" I mean that it actually returns `nullptr`).
This problem has been documented here: https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries where the solution is for the class to have a so-called "key function". The key function makes it so that compiler sees that one of the implementation for a given class is missing and therefore can safely assume that a vtable/type info for a given class is embedded into some library we link to.
This change adds a virtual destructor that is declared in the header file but defined in file that gets compiled as a part of `libreact_render_uimanager`. As a result, the compiler only creates one vtable/type info and calls to dynamic_cast works as expected in all libraries for `ShadowNodeWrapper` and `ShadowNodeListWrapper` classes.
This issue would only surface on Android, because on iOS all libraries by default are bundled together via Pods, whereas on Android each library is loaded separately using dynamic loading.
## Changelog
[Fabric][Android specific] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper and similar classes when accessed by third-party libraries.
Pull Request resolved: https://github.com/facebook/react-native/pull/33500
Test Plan:
1. In order to test this you need to add a library that'd include `<react/renderer/uimanager/primitives.h>` (i.e. use this branch of reanimated library: https://github.com/software-mansion/react-native-reanimated/tree/fabric)
2. After compiling the app inspect libreact_render_uimanager.so and libreanimated.so artifacts with `nm` tool
3. Notice that symbols like `vtable for facebook::react::ShadowNodeWrapper` and `typeinfo for facebook::react::ShadowNodeWrapper` are only present in the former and not in the latter library (before this change you'd see them both)
Reviewed By: ShikaSD
Differential Revision: D35143600
Pulled By: javache
fbshipit-source-id: 5fb25a02365b99a515edc81e5485a77017c56eb8
On Windows there are limits on number of character in file paths and in command lines
Ref: https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#Path-Length-Limits
NDK allows circumventing command line limits using response(RSP) files as inputs using NDK_APP_SHORT_COMMANDS flag.
Windows can support long file paths if configured through registry or by prefixing all file paths with a special character sequence
The latter requires changes in NDK. And there are tools in NDK (AR) which is not able to handle long paths (>256) even after setting the registry key.
The new architecutre source tree is too deep, and the object file naming conventions in NDK makes the matters worse, by producing incredibly long file paths.
Other solutions such as symlinking source code etc. didn't work as expected, and makes the build scripts complicated and hard to manage.
This change temporarily works around the issue by placing the temporary build outputs as short a path as possible within the project path.
Changelog:
[Android] [Fixed] - Fix for building new architecture sources on Windows
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
<!-- 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] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
This re-applies Consider relative to pwd installation root when looking for files in rn module via cocoapods by danilobuerger
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33427
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: cortinico
Differential Revision: D34890926
Pulled By: dmitryrykun
fbshipit-source-id: f7adc6196874822d5ff38f275414f529d385f2ea
Summary:
Avoid breaking tools relying on absolute path for `cliPath`
## Changelog
[Android] [Fixed] - Enable cliPath to have an absolute path value
Pull Request resolved: https://github.com/facebook/react-native/pull/32983
Test Plan:
declare `cliPath` from `expo`:
```groovy
cliPath: new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsolutePath() + "/cli.js",
```
and run an android build
Reviewed By: ShikaSD
Differential Revision: D33843275
Pulled By: cortinico
fbshipit-source-id: 65f55a5e07a4ec0a6205d5f06f150377708c30cc
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
When starting the surface, _propagateStageChange is called. This checks the delegate to call surface:didChangeStage: on it.
When initWithSurface:sizeMeasureMode: is called after start, then the delegate will be nil and thus not be called.
This turns it around so a delegate is present for the surface to propagate its state to.
This fixes RCTContentDidAppearNotification not getting posted otherwise.
## Changelog
[iOS] [Fixed] - Post RCTContentDidAppearNotification with new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33402
Test Plan:
I found it best to set a breakpoint in XCode to where RCTContentDidAppearNotification is being posted.
Prior to the patch that breakpoint will not be called. After applying the patch, it will be called.
Reviewed By: philIip
Differential Revision: D34753329
Pulled By: ShikaSD
fbshipit-source-id: cc44a4c3a787d49e22e9d0c3a82c0f11ed281a0a
Summary:
See the main spec preserve_paths, they are all also included as source_files. Without this, the folly fabric header files won't be available for other pods.
## Changelog
[iOS] [Fixed] - Include folly fabric headers in source files
Pull Request resolved: https://github.com/facebook/react-native/pull/33188
Test Plan:
Include react-native-safe-area-context 4.0.1 with new architecture active. It will result in a xcode build error:
<img width="466" alt="Screenshot 2022-02-26 at 19 33 35" src="https://user-images.githubusercontent.com/996231/155855017-8ea5f473-42a0-4e56-8108-472e6224ae7e.png">
Reviewed By: cortinico
Differential Revision: D34518841
Pulled By: motiz88
fbshipit-source-id: 1053fe204331a314427c793f28b2458e7b78e6c5
Summary:
Added a null check to native.value in Switch to fix regression from RN 66 -> stuck operation in mViewCommandOperations list in Android Release on initial layout of a screen with Switch component. If approved, please incorporate this fix into an RN 66 release.
## Changelog
[Android][Fixed] - Added a null check to native.value in Switch to fix https://github.com/facebook/react-native/issues/32594
Pull Request resolved: https://github.com/facebook/react-native/pull/32602
Test Plan: To reproduce, put a log in UIViewOperationQueue in dispatchViewUpdates you can see that the RetryableMountingException is no longer thrown for a screen with the Switch component on Android Release. As a result, mViewCommandOperations no longer has a stuck operation on initial layout.
Reviewed By: charlesbdudley
Differential Revision: D34397788
Pulled By: lunaleaps
fbshipit-source-id: 1cee3516fb987942dfa50ad1f2d11c965a947f05
Summary:
Due to a bug with AGP, the configureNdkBuild* tasks are not depending on
preBuild tasks. We need to manually fix this otherwise the build will fail the
first time the NDK is invoked.
More on this here: https://issuetracker.google.com/issues/207403732
Changelog:
[Android] [Fixed] - Make sure configureNdkBuild* tasks are depending on
preBuild in the Android template.
Reviewed By: passy
Differential Revision: D34578860
fbshipit-source-id: 5d4caa7d2b7a976b1c9caa6dce8e186c1486cafa
Summary:
Doing this patch level bump to ensure that all packages consuming `react-native` will get `7.0.3` and not lower 7.x versions.
This is because this new patch contains this fix: https://github.com/react-native-community/cli/pull/1560
(thanks NickGerleman & thymikee for your work!)
We'll have to cherry-pick this into the 0.68 branch.
While at it, I've also done a cheeky `npx yarn-deduplicate` to clean up the `yarn.lock` a bit.
<!-- 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] [Changed] - Bump RN CLI to v7.0.3 to address web debugging issue
Pull Request resolved: https://github.com/facebook/react-native/pull/33156
Test Plan:
CI + some local testing via `test-manual-e2e`:
<img width="1779" alt="Screenshot 2022-02-21 at 11 40 54" src="https://user-images.githubusercontent.com/16104054/154948695-8c40bb56-87eb-4326-a740-49930994c08b.png">
Reviewed By: cortinico
Differential Revision: D34385503
Pulled By: motiz88
fbshipit-source-id: f0d8c4e0e92f83c0d819eeaa0fbec27820145968
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33108
The codegen config is optional and can be removed from the default package.json configuration in the template to simplify 0.68 upgrade for people who are not opted-in to the new arch.
Changelog: [Internal] - Remove optional codegenConfig field from template
Reviewed By: cortinico
Differential Revision: D34216988
fbshipit-source-id: 5c448472eed99bc112aef204c4025454171a83c5
Summary:
Time to release a new version of the Gradle plugin and bump it to 0.0.5
This version includes a deprecation of `reactRoot` and a warning message
to migrate to `root`/`reactNativeDir`.
Changelog:
[Android] [Changed] - Release react-native-gradle-plugin 0.0.5
Reviewed By: ShikaSD
Differential Revision: D34339272
fbshipit-source-id: c03495bda7c4185d674761e58a94fde8612f2941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33142
The `reactRoot` property was confusing as we were using it for both the root of the project
and the react-native NPM Package root. I'm deprecating it and splitting it in two.
I've added several warning in the codebase to tell the people how to migrate away from it.
Moreover this is specifying default values that are more user-friendly. Users won't have to
configure anything unless they are in a monorepo.
Changelog:
[Android] [Changed] - Gradle: Deprecate `reactRoot` in favor of `root` and `reactNativeDir`
Reviewed By: ShikaSD
Differential Revision: D34277050
fbshipit-source-id: fc7f45017452b086726516a9586cacd9a661c287
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33134
When a user is enabling New Architecture, we should make sure they don't accidentally mix
imports of React Native from source vs prebuilts.
With this resolution strategy, we'll make sure all the import of `com.facebook.react:react-native:+`
will be resolved to the correct dependency.
Changelog:
[Android] [Fixed] - Set a resolution strategy for com.facebook.react:react-native when on New Architecture
Reviewed By: ShikaSD
Differential Revision: D34303267
fbshipit-source-id: 492fec59175c5887571e1b09ca8e233584b45dd1
Summary:
This is necessary otherwise when building from source on JVM < 11, the `compileJava`
task of the Gradle Plugin will fail with `invalid source: 11`.
Essentially the Gradle build will not even start because of this. Instead we delegate
to a better formatted warning from either AGP or from our plugin.
Changelog:
[Internal] [Changed] - Set Java source/target compatibility for react-native-gradle-plugin to 8
Reviewed By: ShikaSD
Differential Revision: D34111799
fbshipit-source-id: 57ab11fe6c4532576776b586f75e8fcb5c71adcd
Summary:
you can see discussion here: https://github.com/reactwg/react-native-releases/discussions/13#discussioncomment-2069527
we were getting this error message when we build Gradle with other than 11 JVM
```
> Task :react-native-gradle-plugin:compileJava FAILED
2 actionable tasks: 2 executed
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':react-native-gradle-plugin:compileJava'.
> invalid source release: 11
```
this solution is suggested by mikehardy
after this PR, now the error is like this
```
**************************************************************************************************************
ERROR: requires JDK11 or higher.
Incompatible major version detected: '8'
**************************************************************************************************************
```
## 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] - jvm 11 error message
Pull Request resolved: https://github.com/facebook/react-native/pull/33048
Test Plan: install other than 11 java version and just run `./scripts/test-manual-e2e.sh` this command at the root of RN repo than this error will appair `invalid source release: 11`
Reviewed By: ShikaSD
Differential Revision: D34110990
Pulled By: cortinico
fbshipit-source-id: c142a363c7cec0db65d5ab9da858fd25866c7c49
Summary:
We should now be able to remove the explicit `react-native-gradle-plugin` dependency
from the `template/package.json` file.
Changelog:
[Android] [Changed] - Remove `react-native-gradle-plugin` as a dependency from template's package.json
Reviewed By: motiz88
Differential Revision: D34050589
fbshipit-source-id: c8d4e4fba481af6b56723906b71411132d60aded
Summary:
Similarly to what we did for react-native-codegen, I'm introducing
a dependency between RN and the Gradle plugin, to be processed upon OSS bumps.
Changelog:
[General] [Added] - Make react-native depend on react-native-gradle-plugin
Reviewed By: motiz88
Differential Revision: D31334773
fbshipit-source-id: 978da4946b7864d891553e6a7dcb67783399e76f
Summary:
I'm updating the `test_android_template` CI step to use the result of `build_npm_package` instead of sed-ing the RN version to `file:..`.
This should be more robust and will allow to install transitive deps automatically, without having to deal with separate installation steps.
This also fixes the broken CI for Android
Changelog:
[Internal] [Changed] - Update `test_android_template` to use `build_npm_package`
Pull Request resolved: https://github.com/facebook/react-native/pull/33068
Reviewed By: ShikaSD
Differential Revision: D34083047
Pulled By: cortinico
fbshipit-source-id: de34472d5737db445cfc0d4b1c6feaf1e746bb61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33038
While rolling out RN 0.68.x we noticed that `libhermes.so` and `libjsc.so` were included
inside the final .aar we publish to NPM. This forced users (on both old or new arch) to
specify a `pickFirst` directive inside their packaging option (which is unpractical and
risky as the two .so might not be compatible each other if they're coming from
different Hermes/JSC versions).
Changelog:
[Android] [Fixed] - Do not bundle libhermes.so or libjsc.so inside the React Native Android AAR
Reviewed By: ShikaSD
Differential Revision: D33979107
fbshipit-source-id: 0b71d59f210b8bc9903cd0f30ed6e2120aab99e0
Summary:
Fixes a potential crash was introduced by https://github.com/facebook/react-native/issues/30919 that aimed to get the keyboard height on devices with a Notch. The problem is that it considers that any ReactRootView will have an insets available.
When using [react-native-navigation](https://github.com/wix/react-native-navigation) and assigning a Navigation button to the TopBar as a component, the component gets registered as a RootView but won't have any insets attach to the view.
[getRootWindowInsets()](https://developer.android.com/reference/android/view/View#getRootWindowInsets()) in fact return a `WindowInset` only available if the view is attached, so when executing `checkForKeyboardEvents` method from ReactRootView, is trying to access the `DisplayCutout` of a null object, leading to a crash.
## Changelog
[Android] [Fixed] - Fix potential crash if ReactRootView does not have insets attached.
Pull Request resolved: https://github.com/facebook/react-native/pull/32989
Test Plan:
Without the code change: Notice how the second screen being push contains a React Component on the top right of the navigation bar, and when component is unmounted (going back) the app crashes.
https://user-images.githubusercontent.com/6757047/151558235-39b9a8b5-be73-4c31-8053-02ce188637b8.mp4
crash log
```
2022-01-28 10:27:52.902 15600-15600/com.mattermost.rnbeta E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.mattermost.rnbeta, PID: 15600
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayCutout android.view.WindowInsets.getDisplayCutout()' on a null object reference
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:778)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:769)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3214)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2143)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8665)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
After applying the patch which is only a null check validation and does not change any previous behavior
https://user-images.githubusercontent.com/6757047/151558429-9ff1a608-abb6-4168-8db9-df0c3c71d79e.mp4
Reviewed By: cortinico
Differential Revision: D33844955
Pulled By: ShikaSD
fbshipit-source-id: ed5579ad3afeed009c61cc1851eee45c70087cf5
Summary:
Updates maximum heap size for the gradle build to account for building RN from source when new architecture is enabled.
Changelog: [Changed][Android] - Use 2g as a default heap size for gradle builds
Reviewed By: cortinico
Differential Revision: D33947090
fbshipit-source-id: 2f551e688f2d92c3092e053086f6933779cd6f63
Summary:
The fix in this diff seems simple, but it took some time to understand why this change fixed the issue that views animated use native driver out from their parent's layout are not getting touch events.
We introduced `overflowInset` to RN Android a while back to give each shadow node extra information to cover all its children's layout. These values (left, top, right, bottom extensions from the view's own layout) help us improve hit-testing algorithm used in touch events. We could ignore all subtrees that the touch point not in their parent's overflowInset box.
However, this was not working for native animation. When `userNativeDriver` is on, all animation happens without Fabric knows anything about them. The overflowInset is out of date with the final animated layout, which caused the issue that we ignored the animated view as we thought it's not under the pointer.
Here is a playground demo (P476407654) for the issue:
https://pxl.cl/1XfPL
We've tried to fix this by passing the final animated values via `passthroughAnimatedPropExplicitValues` added in D32539976. This is a prop that will get merged into `style` prop for [animation component](https://fburl.com/code/jybzfgu5). The transform values were already applied when measuring layout in [Pressability](https://fburl.com/code/5mect2k3), which uses [LayoutableShadowNode](https://fburl.com/code/qh8fufrw). However, this is not the case for overflowInset calculation. Hence, the fix here is to apply the transform matrix in Yoga before calculating the overflowInset.
Changelog:
[Android][Fixed] - Fix overflowInset calculation by using transform values
Reviewed By: ShikaSD
Differential Revision: D33806030
fbshipit-source-id: e438618e3d6e5b0333cff9ff9919b841d73b2e9d
Summary:
This was a bug, we are fixing it.
Move pointerEvents from formsStacking -> formsView and we are also removing "onLayout" from formsStackingContext
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33846660
fbshipit-source-id: 6b65a9a7815972e34dafbc48b3d732d9b02d5e9f
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.67.0](https://github.com/facebook/metro/releases/tag/v0.67.0).
Changelog:
[General] Update direct Metro dependencies to 0.67.0
Reviewed By: GijsWeterings
Differential Revision: D33828217
fbshipit-source-id: e4e9ba4cf43a8588f8db43885f67d4dc606198f5
Summary:
Creates a new package called `fb-tools-support/yarn` and moves the `getWorkspacesFromYarn` function (currently duplicated almost verbatim in two places) into that shared location.
Also, gets `yarn postinstall` to work again and runs it in `xplat/js` - this materialises some new BUCK files that weren't added when their respective Yarn workspaces were created.
Reviewed By: rh389
Differential Revision: D33826945
fbshipit-source-id: 02e2db8b210303ed4f6d24a777a2e0094022bd5d
Summary:
Before https://github.com/facebook/react-native/commit/f951da912dd8b4dc2b0d674f8f37f9d982a03c48 finding a system font used to return early. In order to allow variants, the referenced patch removed the early return so that variants could be applied later. However, there is no need to find the closest font as we already selected the proper system font. This also fixes a bug with setting a custom font handler via RCTSetDefaultFontHandler whos return could get overwritten by the closest font search.
## 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] - Respect RCTSetDefaultFontHandler chosen font
Pull Request resolved: https://github.com/facebook/react-native/pull/32482
Reviewed By: ShikaSD
Differential Revision: D33844138
Pulled By: cortinico
fbshipit-source-id: 05c01fc358cd19f8be342218cdba944b303073ed
Summary:
when migrated to `maven-publish` in https://github.com/facebook/react-native/issues/31611, the sources jar is not included by default from `maven-publish`. so react-native 0.66 / 0.67 doesn't include sources jar in npm published artifacts. it's not ideal for debug or tracing code.
this pr added the sources jar into the published artifact.
## Changelog
[Android] [Fixed] - Add missing sources jar into published android artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/32982
Test Plan:
make sure sources jar is included in artifact.
```
$ ./gradlew :ReactAndroid:installArchives
$ find android -name '*sources.jar*'
```
Reviewed By: ShikaSD
Differential Revision: D33842979
Pulled By: cortinico
fbshipit-source-id: f99ad46ce0cca0cfc2ab1d5c5a4fcb40a02683e7
Summary:
This PR bumps the `actions-apply-version-label` version to 0.0.3 in order to fix an issue where we were throwing an error when the identified label does not exist, instead we should just report a warning. This also updates `apply-version-label-issue.yml` to use `actions-apply-version-label` from `react-native-community` as it has been recently transferred to the community
## Changelog
[Internal] [Fixed] - Fix `actions-apply-version-label` error when version label is missing
Pull Request resolved: https://github.com/facebook/react-native/pull/32979
Test Plan:
Open an issue with a missing version label and ran the new action version
https://github.com/gabrieldonadel/actions-apply-version-label/actions/runs/1756805059
Reviewed By: ShikaSD
Differential Revision: D33819052
Pulled By: cortinico
fbshipit-source-id: 49c719e729e3085e78b1c43143c2d41a03e797e4
Summary:
The current JSLoader implementation (on Android) will copy the buffer into a JSBigBufferString during startup. This duplicates work Android is already doing (it allocates creates a copy of the bundle in memory while decompressing the asset from the APK) or worse, if the APK is mmap'ed this will unnecessarily create dirty memory.
The risk with this approach is that the bundle loaded from disk is no longer \0 terminated, but that's also the case for the bundles we load with `JSBigFileString` and is not an issue as far as I can tell.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D33792735
fbshipit-source-id: 61fc089a223f3602d3575340d79a8de2ec92d8a0
Summary:
In addition to rgba values, allow creating Animated.Color with a string color.
Followup changes will include support for platform colors and native driver.
Changelog:
[General][Added] - Support string color values in Animated.Color
Reviewed By: javache
Differential Revision: D33810717
fbshipit-source-id: 208bc2675b6153a515fbf2122da15a065c473e73
Summary:
This diff deletes the flag ReactFeatureFlags.enableReactContextCleanupFix, the flag was disabled for many months, I just disable it.
changelog: [internal] internal
Reviewed By: genkikondo, makovkastar
Differential Revision: D33781628
fbshipit-source-id: 4b5e22adf9d30da5b85bbbde8bdc98d98f5e8891
Summary:
This diff deletes the ReactFeatureFlag enableFabricInLogBox, from now on Logbox will be rendered in Fabric when Fabric is enabled
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33781626
fbshipit-source-id: 3187a22fec80125afd27860995637564640dab8d
Summary:
Creates Animated.Color for animating color props.
Implement AnimatedColor, which basically consists of 4 AnimatedValues (along the same vein as ValueXY) which allows us to just use AnimatedValue's interpolation. Provides a string color value of shape 'rgba(r, g, b, a)'
AnimationNode DAG looks like:
{F696076974}
Followup changes will include support for string color values, platform colors, and native driver.
Changelog:
[General][Added] - New Animated.Color node
Reviewed By: mdvacca
Differential Revision: D33778456
fbshipit-source-id: 83ddbc955156bf589c864f229a5f83fe6875fd0e
Summary:
Adding string annotations support to markEvent API in ReactNative
Changelog:
[Internal][Change] - markEvent API now supports string annotations
Differential Revision: D33795346
fbshipit-source-id: 414cbd08ce5ff6045e2f35ae77059be5add3d834
Summary:
QPL in ReactNative were missing markEvent API - adding it in this diff. In the next diff I will add support for annotations.
Customer request: https://fb.workplace.com/groups/QPL.QandA/posts/1228789167531266/
Changelog:
[Internal][Change] - Adding markEvent API to QuickPerformanceLogger
Differential Revision: D33789590
fbshipit-source-id: 3e9dfde9d413943281d6aa7e85b9feeafc3bef7a
Summary:
Fixes https://github.com/facebook/react-native/issues/32939
It appears there is circular dependencies on the Modal component that causes the modalMock function to be an empty object. Removing the import fixes the issue.
I don't know yet why this is not happening when executing the test suite inside `Modal-test.js` but I will investigate this later.
## 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] - Fix error "mockModal is not a function"
Pull Request resolved: https://github.com/facebook/react-native/pull/32964
Test Plan:
On a newly initiated project using react-native 0.67.1 I created a ModalComponent:
```
import React from 'react';
import {Modal, Text} from 'react-native';
export const ModalComponent = () => {
return (
<Modal visible>
<Text>Test</Text>
</Modal>
);
};
```
and a ModalComponent.test.tsx:
```
import 'react-native';
import React from 'react';
import {ModalComponent} from '../ModalComponent';
// Note: test renderer must be required after react-native.
import renderer from 'react-test-renderer';
it('renders correctly', () => {
renderer.create(<ModalComponent />);
});
```
Running the test throws the error "TypeError: mockModal is not a function".
After modifying the mockModal inside node_modules/react-native/jest/mockModal.js it works correctly.
Reviewed By: christophpurrer
Differential Revision: D33771136
Pulled By: lunaleaps
fbshipit-source-id: c09ada8d2f864f5568b3379616a6cace9fb9921e
Summary:
In Animated, when a toValue of AnimatedValue (as opposed to a number) is passed in, the [AnimatedValue starts tracking via AnimatedTracking](https://www.internalfb.com/code/fbsource/[b688f3747a706236fce300636978ed1ca5e4081a]/xplat/js/react-native-github/Libraries/Animated/AnimatedImplementation.js?lines=142) but it doesn't actually start animating even if start() is called on the animation.
This behavior is inconsistent with a toValue of a number, which executes immediately on start(). This diff adds a call to AnimatedTracking.update within AnimatedValue.track, which starts the tracking animation.
Changelog:
[General][Fixed] - Fixes execution of animation when a toValue of AnimatedValue is used.
Reviewed By: JoshuaGross
Differential Revision: D33800373
fbshipit-source-id: 85ee6f51bc2bb2e078b586b076a8d1dfe92c1155
Summary:
The overflowInset uses negative values to indicate extending from parent view. This diff fixes the math so that it's correctly check if the point is within overflowInset.
Changelog
[Android][Fixed] - Fix math for detecting if children views are in parent's overflowInset area.
Reviewed By: genkikondo
Differential Revision: D33750129
fbshipit-source-id: 1a5a33a227280c687b158b4a81a56017b6f4f3e0
Summary:
As stated in [https://github.com/facebook/react-native/issues/28043](https://github.com/facebook/react-native/issues/28043) the requests with the `Octokit` lib is not optimal since tracking issues were raised. Since the issue could not be reproduced (see comments in the mentioned issue) I'm proposing to update the `Octokit` package to the newest version and add the required fields as stated [in the documentation](https://octokit.github.io/rest.js/v18#authentication).
## Changelog
[Internal] [Changed] - Changed requests of the internal code analysis
Pull Request resolved: https://github.com/facebook/react-native/pull/32891
Test Plan:
Ran the code analysis bot manually
```
cat <(echo eslint; npm run lint --silent -- --format=json; echo flow; npm run flow-check-ios --silent --json; echo flow; npm run flow-check-android --silent --json; echo google-java-format; node scripts/lint-java.js --diff) | GITHUB_PR_NUMBER="$CIRCLE_PR_NUMBER" node bots/code-analysis-bot.js
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
```
Reviewed By: christophpurrer
Differential Revision: D33793194
Pulled By: cortinico
fbshipit-source-id: 21b5f9f3911dd82e3254ab009637ab63aa36d30c
Summary:
Changelog: [internal]
Add comments and avoid using shared_ptr unnecessarily.
Why note shared_ptr? Using shared_ptr suggests we are transferring ownership of object, which we are not.
Reviewed By: javache
Differential Revision: D33741836
fbshipit-source-id: 56ebb098e6185793f05e2bb587005bb0f093c0c9
Summary:
changelog: [internal]
Yielding in RuntimeScheduler is shipped. This diff removes the gating around it.
Reviewed By: sshic
Differential Revision: D33740360
fbshipit-source-id: 267372e81e66dda96e451435954a7c3546cc6fbe
Summary:
Since 0.64, local code in `Bundle React Native code and images` step for iOS is not enough anymore.
This add support for [fnm](https://github.com/Schniz/fnm) that is widely used this days.
## 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] [Added] - Support fnm when detecting node binary
Pull Request resolved: https://github.com/facebook/react-native/pull/32890
Test Plan: I use fnm & it's working. Tested this code via patch-package.
Reviewed By: christophpurrer
Differential Revision: D33766842
Pulled By: cortinico
fbshipit-source-id: 77bbda2c7742de9ec64e6faa9a3526d3997bb4aa
Summary:
Dynamic nested components can cause tricky performance issues in React, as the reconciler will not be able to reuse the previously mounted component tree.
Changelog: [General] [Added] Added linter warning config for unstable nested components
Reviewed By: motiz88
Differential Revision: D33767283
fbshipit-source-id: 869ece99dc63cc3a150bae882d26df8541e8db59
Summary:
Current syntax options for RN version values break Windows. Following change to nightly build format to be 0.0.0-X-X-X, prerelease value is now a string (X-X-X).
https://github.com/microsoft/react-native-windows/issues/9223
## Changelog
[General] [Fixed] - Fix RN version syntax to match new nightly build structure.
Pull Request resolved: https://github.com/facebook/react-native/pull/32892
Reviewed By: cortinico
Differential Revision: D33712950
Pulled By: lunaleaps
fbshipit-source-id: 9e47cae34930ee624a863c832430962354ebb5be
Summary:
Enable eager intialization of FabricUIManager during intiialization of React Native.
This feature highly improved TTRC in Markeptlace Home
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33585099
fbshipit-source-id: 0ffbc720bcb1edd1b04180189a52c82e9e2fa800
Summary:
flow 0.146 became more conservative about refinement invalidation, no longer accepting that `this.props.onViewableItemsChanged` is truthy. this was suppressed at the time.
instead, we can assign to a const to restore typechecking.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33743126
fbshipit-source-id: 0b1f0b83c2fe812e88b027c3b1d3d8aca7b09277
Summary:
`Easing` only has static properties and is never constructed or subclassed, so there doesn't seem to be any reason for it to be a class instead of an object.
as a class, Flow errors about `method-unbinding` on every single use of it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33774944
fbshipit-source-id: c0bd2e3d7a78e538f95b88b2b1b12d301c8f590c
Summary:
The path to `Time.h` is currently hard-coded and does not take into
consideration the `--project-directory` flag when running `pod install`.
## Changelog
[iOS] [Fixed] - Fix `Time.h` patch not being applied when running `pod install --project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32961
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
../scripts/xcodebuild.sh ios/Example.xcworkspace build
```
Reviewed By: christophpurrer
Differential Revision: D33748789
Pulled By: lunaleaps
fbshipit-source-id: b125734eba30e552ae139e7ecd4e634c8fa1bcd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32946
Changelog: [Internal]
This fixes a bug where config file dir was incorrectly and breaks the codegen which runs when building an app.
Reviewed By: dmitryrykun
Differential Revision: D33724558
fbshipit-source-id: 0c04c1d41f2fb9b958da64fa414746695cea60cb
Summary:
…ansforms
On iOS, if a View is rotated with the a transform (e.g. <View style={{transform: {rotationZ: 5}}} />), the view has aliasing (see screenshot). Same for a skew transformation. We don't have the issue on Android
This behavior had originally being fixed by this PR https://github.com/facebook/react-native/pull/1999
However a new PR was merge ( https://github.com/facebook/react-native/pull/19360 ) that broke this. I think it was made to add antialiasing during perspective transforms but seems to have broken the antialiasing when rotationZ transforms
This PR adds back the antialising during rotation transform , while keeping it during perspective transform.
## Changelog
I changed the allowsEdgeAntialiasing condition, making it "true" when the m12 or m21 is not 0. From this article https://medium.com/swlh/understanding-3d-matrix-transforms-with-pixijs-c76da3f8bd8 , I've understood that in all rotation or skew transformations, m12 or m21 is different than 0 . In the other transformation (e.g. scale or translate) it stays at 0.
Although, I'm not a matrix transformation expert so I may be mistaken
Pull Request resolved: https://github.com/facebook/react-native/pull/32920
Test Plan:
I've written several views with all rotateX/Y/Z , skewX,Y and perpective transformation. Before the PR some transformation was showing aliasing on iOS (e.g. top-left view in the screenshot, don't hesitate to zoom in the image if you don't see it) and with this PR it does not have anymore
Before
After
Code I used to test
```
const commonStyle = {
width: 150,
height: 100,
backgroundColor: "red",
margin: 10,
}
const Test = () => (
<View style={{ flexDirection: "row" }}>
<View>
<View
style={[
commonStyle,
{
transform: [{ rotateZ: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateY: "30deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ rotateX: "30deg" }, { rotateY: "30deg" }, { rotateZ: "3deg" }],
},
]}
/>
</View>
<View>
<View
style={[
commonStyle,
{
transform: [{ skewX: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ skewY: "4deg" }, { rotateZ: "3deg" }],
},
]}
/>
<View
style={[
commonStyle,
{
transform: [{ perspective: 1000 }],
},
]}
/>
</View>
</View>
)
```
Reviewed By: lunaleaps
Differential Revision: D33665910
Pulled By: sshic
fbshipit-source-id: 91163ec2a0897a73ddf0310d86afacea04b89bc7
Summary:
Per discussion in the previous diff D33672110, it's ok to add the `pointerEvents` prop to scrollview. This will help prevent scrolling on the ScrollView if pointerEvents is set to `box-none`, or `none`.
Corresponding doc changes are in https://github.com/facebook/react-native-website/pull/2936
Changelog:
[Android][Added] - Add new API in ScrollView and HorizontalScrollView to process pointerEvents prop.
Reviewed By: javache
Differential Revision: D33699223
fbshipit-source-id: 1cae5113e9e7d988fc4c4765c41d817a321804c4
Summary:
Bump Kotlin version to 1.6.10 with changes:
https://kotlinlang.org/docs/whatsnew16.html
Primarily:
- stabilization to several language features
- various type inference improvements
- support for annotations on class type parameters
## Changelog
[Android] [Changed] - Bump Kotlin version to 1.6.10
Pull Request resolved: https://github.com/facebook/react-native/pull/32936
Reviewed By: ShikaSD
Differential Revision: D33708397
Pulled By: cortinico
fbshipit-source-id: a09b4504c194676d18a749c5e297b7598e5f32b4
Summary:
Bump react-native-codegen version to include new fixes and improvements.
Changelog: [internal] Updated react-native-codegen version
Reviewed By: cortinico
Differential Revision: D33684175
fbshipit-source-id: bfc6cb627659c7cdfca2676894bece5f02aff767
Summary:
Adds changelog for new patch and removes an entry that was rolled back.
## 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
-->
[Internal] [Changed] - add changelog entry for 0.67.1 & fix 0.67
Pull Request resolved: https://github.com/facebook/react-native/pull/32938
Test Plan: N/A
Reviewed By: ShikaSD
Differential Revision: D33709914
Pulled By: cortinico
fbshipit-source-id: 0829be764e7aeae6191aa2138eb8bc74d9c2a880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32923
As our Flipper version is quite old, let's bump it to one of the latest stable: 0.125.0
This required to update also the following:
- Flipper-Folly to 2.6.10 - This was needed as I aligned the versions to https://github.com/facebook/flipper/blob/v0.125.0/react-native/ReactNativeFlipperExample/ios/Podfile
- OpenSSL-Universal to 1.1.1100 - This was required with the `pod update` command
I've picked 0.125.0 as 0.127.x and following are crashing on Android
and will potentially require a bump of the NDK to r23:
See: https://github.com/facebook/flipper/issues/3245
Changelog:
[General] [Changed] - Bump Flipper to 0.125.0
allow-large-files
Reviewed By: mdvacca
Differential Revision: D33583090
fbshipit-source-id: 2a2020c3213273087ec4a152076f846e35e275c5
Summary:
Removes all of the `DeprecatedPropTypes` modules from React Native.
Any call sites that were deep-linking to these modules and still requires them can instead import them from the `deprecated-react-native-prop-types` package.
Since this also removes the last reference to `prop-types`, this diff also removes the `prop-types` dependency from `react-native`. 🥳
Changelog:
[General][Removed] DeprecatedPropTypes (deep-link) modules removed from React Native.
Reviewed By: kacieb
Differential Revision: D33671645
fbshipit-source-id: 91829a556b272bbd17ee94806fc548af753593db
Summary:
Changelog: [Internal] Update the documentation to disable fabric in RN Tester.
RNTester build would fail if you previously built with fabric_enabled. This documentation adds the instruction to clean up before runing pod install.
In the future, we'd want to detect and do the clean up so that it doesn't fail in an obscure way.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D33173173
fbshipit-source-id: a396eb71edc7bf174d0eb392799f45ae74274b76
Summary:
The iOS WebSocket implementation has a race condition that causes WebSocket frame payloads to be processed incorrectly.
This can cause errors on RFC6455 compliant WebSocket servers:
- the server sends a ping frame with no payload
- the server sends a text frame with a payload longer than 125 bytes
- the client answers the ping with a pong frame echoing back the contents of the text frame
This is caused by concurrent modification of the current frame contents, that is passed by reference to the handlers. The concurrent modification happens [here](https://github.com/facebook/react-native/blob/main/Libraries/WebSocket/RCTSRWebSocket.m#L1162).
The bug was detected and fixed in the original SocketRocket repository in [this PR](https://github.com/facebookincubator/SocketRocket/pull/371). The relevant part of the fix is applied in this PR.
Resolves https://github.com/facebook/react-native/issues/30020.
## 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] - Fix WebSocket control frames having payloads longer than 125 bytes
Pull Request resolved: https://github.com/facebook/react-native/pull/32847
Test Plan:
The bug is not easily and consistently reproduced, being a race condition.
We were able to reproduce it by connecting a react native app to a websocket server that sent ~100 pings per second and ~100 text frames per second. After a couple of seconds, the server receives an invalid pong message, with a payload equal to the payload of the text frame. The following is a node server that can replicate the problem on a react-native app running on iOS.
<details>
```
const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', function connection(ws) {
const pingInterval = setInterval(() => {
ws.ping();
}, 10);
const sendInterval = setInterval(() => {
const arr = new Array(100);
for (let i = 0; i < arr.length; i++) {
arr[i] = Math.random();
}
ws.send('message with payload longer than 125 bytes: ' + arr.join(','));
}, 10);
ws.on('close', () => {
clearInterval(pingInterval);
clearInterval(sendInterval);
});
ws.on('error', (err) => {
console.error(err);
process.exit(1);
});
});
```
</details>
Reviewed By: hramos
Differential Revision: D33486828
Pulled By: sota000
fbshipit-source-id: ba52958a584d633813e0d623d29b19999d0c617b
Summary:
Making the native ViewConfig for RCTModalHostView match its static ViewConfig.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33303419
fbshipit-source-id: 6fac237d670ee221ad867f79e54d5a3576c156da
Summary:
Refactors MapBuffer-related `primitives.h` to be namespaced with `MapBuffer` class, to avoid name collisions and confusion later on.
Most of the size constants are moved to relevant .cpp files or updated to use `sizeof`.
Additionally, adds a little bit of documentation about `MapBuffer` serialization format.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33662487
fbshipit-source-id: 5a7a2b1c7f2bb13ee1edfc5fae51ba88c34f0d3c
Summary:
Serializes type information along with key/value in MapBuffer, asserting the data type on Java side during read. At the moment, accessing value with incorrect will result in a crash.
Other changes:
Adds a `getType` method to verify types before accessing them.
Removes `null` as a type, as just not inserting value and checking for its existence with `hasKey` is more optimal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33656841
fbshipit-source-id: 23a78daa0d84704aab141088b5dfe881e9609472
Summary:
Removes the need to store keys in incremental order by sorting them after before inserting into MapBuffer.
Updates MapBuffer to support random access on C++ side, actually retrieving values by keys and not bucket index.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33611758
fbshipit-source-id: c81e970613c8ecc688bfacb29ba038bf081a0c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32925
Changelog: [internal] I was testing with some sample proect without the codegen discovery, and I found a code path that doesn't work due to the escape charactors left.
Reviewed By: christophpurrer
Differential Revision: D33670881
fbshipit-source-id: 94bd4f0eea28ebf86001381f08e6ddbff7213793
Summary:
I realized while checking for a few other things that Detox's presence in the repo is actually not really motivated - since Jul 2020 the few tests that were using it were disabled https://github.com/facebook/react-native/commit/120ff7ccdebebdf814e478259ba1e4a8ef6f513e never to be reactivated since.
I noticed this while attempting to updating the Detox version to latest... which made me notice that the repo is still on a 16.x version while latest is 19.x (there are like 10 pages of releases between them: https://github.com/wix/Detox/releases) and I came to the conclusion that it's probably easier to just remove the old dusty code and eventually reintroduce it in the future if we ever consider it necessary.
## 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] [Removed] - Removing Detox from CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/32907
Test Plan: CI - nothing breaks.
Reviewed By: lunaleaps
Differential Revision: D33623199
Pulled By: cortinico
fbshipit-source-id: 7d8d133629b62b66959b309f2ca21852d396c9fc
Summary:
Fix an issue in the AccessibilityExample on RNTester where the `Screen Reader` item would listen for the `reduceMotionChanged` event instead of the `screenReaderChanged` event
## Changelog
[General] [Fixed] - Fix screen reader event name on RNTester AccessibilityExample
Pull Request resolved: https://github.com/facebook/react-native/pull/32926
Test Plan:
1. Build iOS app
2. Navigate to the Accessibility page
3. Switch over to settings and change VoiceOver at `Settings>Accessibility>VoiceOver>VoiceOver`
4. Switch back to the app and see the results
https://user-images.githubusercontent.com/11707729/150266745-6a9eb547-00a7-4b94-bf19-b8d6e6f76122.mp4
Reviewed By: kacieb
Differential Revision: D33681780
Pulled By: cortinico
fbshipit-source-id: fbd4f3d9ef63997f2b4a40afc8a5adfe6172e525
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32932
As the title says, we dont' want to remove `libjscexecutor.so` when
baking release builds and having JSC enable as this leads to instacrashes.
Fixes#32928Fixes#32927
Changelog:
[Android] [Fixed] - Do not remove libjscexecutor.so from release builds
Reviewed By: ShikaSD
Differential Revision: D33681932
fbshipit-source-id: 5b59fd1fb76c80c191198d65c916bbbd9232c75b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32736
The ability to pass an additional property bag to further configure NativeAnimated is useful for a few reasons, e.g., experimentation with multiple implementations of the NativeAnimated module.
The specific use case this solves is on react-native-windows, where there are two underlying animation graph options, one "optimized" animation graph that uses UI.Composition, and another similar to the approach to iOS and Android that uses a frame rendering callback.
The platform configuration can be supplied to the animation node when `useNativeDriver` is set to `true`, and we pass the platform configuration object to the connected AnimatedValue and all it's children.
Changelog:
[General][Added] - Option to supply `platformConfig` to NativeAnimated
Reviewed By: yungsters
Differential Revision: D32988285
fbshipit-source-id: ab8a7bbf197573fc9e9a4737c255f124321295ac
Summary:
Changelog: [General][Fix] Fix SnapshotExample in rn-tester
Before this diff, the <Image> has no height. You can tell because the backgroundColor of <Image> is black but it doesn't show up on this surface.
Reviewed By: RSNara
Differential Revision: D33649085
fbshipit-source-id: 1b0fa0a82bce29923afee000d0828cbd90845abf
Summary:
Flow currently allows duplicate members on classes. At runtime the "last" member wins out and all previous values for the member are discarded.
This diff manually removes duplicate members, and fixes resulting flow errors by converting methods to arrow function properties.
Reviewed By: pieterv
Differential Revision: D33664966
fbshipit-source-id: 0f712ac96af4df593c0918fcbadd70624ddde4a6
Summary:
Changelog: [JS] Migrate ScreenshotManager from NativeModule to TurboModule. Fix SnapshotExample in rn-tester.
`const ScreenshotManager = NativeModules.ScreenshotManager;` makes all of RNTesterAppRoute render blank in Bridgeless, because we throw a jsi::JSError when JS calls `NativeModule.get` while in Bridgeless.
Reviewed By: RSNara
Differential Revision: D33640935
fbshipit-source-id: 124a3b43e1440a7ca0071c95c4388350d2e4affa
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
Summary:
This fixes https://github.com/facebook/react-native/issues/32898 by reseting ReactInstanceManager state when `createReactContext` throws. By resetting the state, we allow future attempts at creating the React context.
## Changelog
[Android] [Fixed] - Fixed empty screen after retrying a BundleDownloader failure in dev mode
Pull Request resolved: https://github.com/facebook/react-native/pull/32901
Test Plan: Go through the steps to reproduce listed in https://github.com/facebook/react-native/issues/32898 and see that the React Native application starts.
Reviewed By: cortinico
Differential Revision: D33634178
Pulled By: ShikaSD
fbshipit-source-id: e54d12d5f33c9c7c0ca213113871b88c2f1dc261
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## 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] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary:
`const {CrashyCrash} = NativeModules` makes all of RNTesterAppRoute render blank in Bridgeless.
Remove this test example because the CrashyCrash has not existed since 2019, and no similar module exists in open source. [[github]](https://github.com/facebook/react-native/commit/8ec7e0966cf83ed29a39aab47c686bc60a124983)
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D33644122
fbshipit-source-id: ed10e8bf8ea9af9d5904afc2a7d9c2b3b3606978
Summary:
Rename `_header` to `header_` to align with the C++ naming scheme we use.
Rename `readKey` to `readUnsignedShort` as purpose of the method have changed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33637127
fbshipit-source-id: a82f4d6c1b753b21e0567fbe919af98e4c78105d
Summary:
In the case of T110060790, there is a JavaScript crash that causes RN teardown to race with a ScrollView event being emitted, which ends up being reported as the "real" cause of the crash.
This is not correct, and it's better to just ignore this case. If there's no EventDispatcher, it means something has gone wrong (usually teardown) before, RN is in an inconsistent state, and we should
not crash here or report here.
Changelog: [Android][Fixed] Fix crash from ScrollView that occurs while reporting an error from JS
Reviewed By: mdvacca
Differential Revision: D33644692
fbshipit-source-id: 41c3defde795b804239cc8401c8aff71d017d59d
Summary:
Minor optimization, but spotted this while reviewing the implementation for D33622997
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33622996
fbshipit-source-id: 8712753803fc46e6a046d50f77454a813e4a641a
Summary:
`onPointerMove` events get dispatched with an `offset: [x, y]` attribute (API is not yet available in OSS, so subject to change), but `EventAnimationDriver` in RN Android is not able to extract values with such keys (even though the equivalent JS implementation does allow it).
(TODO: verify iOS behaviour)
Changelog:
[General][Added] - Animated.event can be used to extract values with numeric keys from native events
Reviewed By: mdvacca
Differential Revision: D32531117
fbshipit-source-id: 918a5443c5d8f5f8200d86bb67f84e8bc175c1d3
Summary:
The struct is copied directly to the buffer, so it is safe to read it back.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33624036
fbshipit-source-id: 7ee2b28b815690ab471832c0c622a075b5dd7d78
Summary:
Replaces dynamic manually managed array with a vector of bytes, removing the need for managing memory manually.
This approach is a little bit slower than before, as vector is allocating memory more conservatively. This can be improved in the future by providing an estimate for the data size.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33611759
fbshipit-source-id: a0e5e57c4e413206a9f891cd5630ecc9088a9bf7
Summary:
Instead of copying integer values into key/value data array, this implementation keeps a structured vector of `Bucket` structs (which is sized to be serialized later).
This approach provides multiple benefits to modify and access buckets (e.g. sort them based on the key, allowing for out of order inserts (D33611758))
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33601231
fbshipit-source-id: 62ace1374936cb504836d6eae672e909ea404e3f
Summary:
While working on a fix for https://github.com/facebook/react-native/issues/29974 I notice that the `_updateBottomIfNecessary` function inside `KeyboardAvoidingView` was misspelled, so I decided to open a PR fixing it.
## Changelog
[General] [Fixed] - Fix typo in _updateBottomIfNecessary function on KeyboardAvoidingView component
Pull Request resolved: https://github.com/facebook/react-native/pull/32894
Test Plan: Shouldn't require much testing as this is just renaming a private function of `KeyboardAvoidingView`
Reviewed By: philIip
Differential Revision: D33620554
Pulled By: cortinico
fbshipit-source-id: 69b8969bef09cf58b9b1c8a9154dc52686187f8a
Summary:
MapBuffer uses unsigned short in C++, but Java doesn't really have a type that represents that. That means that MapBuffer would be limited to max 32768 values instead of 65536, which doesn't make much sense as a limitation.
Considering weird (and usually not performant) handling of short values in Java in general, this change replaces them with ints, converting keys from short when needed with `key & 0xFFFF`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33595308
fbshipit-source-id: a7adde8a207bb4aa1d81d367ab5d7b41ace2e291
Summary:
Adds a check to verify that we are not trying to insert a new view id into a non-existent set.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33621031
fbshipit-source-id: 8468af69bea250a70d656789ea819c39b55a9de6
Summary:
Benchmarks performance/correctness of mapbuffer with several different types of data
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33608299
fbshipit-source-id: 81b1e195aecac60ad1cc3ca416d1cf7b09feab32
Summary:
This method can produce unnecessary copy of the string, replacing it with reference to optimize.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33607765
fbshipit-source-id: e04eddffec063c0c8e173bfdf690e7b8e1050525
Summary:
As the title says, probot/stale is really unpredictable and happens to spam
a lot of issues, making hard for us to follow up on those that are really
relevant.
We're now using actions/stale and this file is no longer necessary.
Changelog:
[Internal] [Changed] - Removed .github/stale.yml as we're now using the Github Action
Reviewed By: mdvacca
Differential Revision: D33585581
fbshipit-source-id: 02a645ca98985edcee22d24c1ad4c0b7056fc15d
Summary:
instead of `errors: ?Array<Error>` and setting it back to `null` to clear errors, which Flow is not very happy with, we can make it always an array and truncate it with `errors.length = 0`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33584184
fbshipit-source-id: 81b424e69e60203c645bafbac12177ffcdc0c6ef
Summary:
Gradle Plugin Portal proxies jcenter which is quite unstable these days. This change updates plugin repositories to look into maven central and google first and use gradle plugin repo only as a fallback.
Changelog: [Internal] - Prioritize maven central for Gradle plugins
Reviewed By: cortinico
Differential Revision: D33550827
fbshipit-source-id: b436b05b0fd07865b56dd3e442d8399678dfff85
Summary:
I'm bumping the Gradle Plugin to the latest stable. That's needed as the newest
plugin now specifies a Maven `group` and can leverage implicit dependency substitution.
Changelog:
[Internal] [Changed] - Bump gradle-plugin to 0.0.4
Reviewed By: ShikaSD
Differential Revision: D33530286
fbshipit-source-id: 904f0a6585b468322f611ed82c57cee7025305d7
Summary:
Cleans up `ReadableMapBuffer` APIs and migrates to use `std::vector` instead of raw pointer array.
Also uses `fbjni` utility to allocate the bytes instead of making manual JNI calls.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33513027
fbshipit-source-id: afe7d320d12830503de4c9994117d849f0b25245
Summary:
Replaces raw array pointer inside `MapBuffer` with `std::vector`, which is more conventional "safer" way of storing dynamically sized arrays.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33512115
fbshipit-source-id: d875a2240f7938fd35c4c3ae0e7e91dc7456ff32
Summary:
React Native includes a `ReactNativeTestTools` file that imports `react-shallow-renderer`. This file is used by Jest tests. Since this file might be consumed by tests outside of the RN repo, the dependency should be promoted to `dependencies` to ensure it is actually present when RN is installed from npm.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D33475662
fbshipit-source-id: 8068294a8b6cade17754699c49a2dfe6d45d86de
Summary:
Draft PR that adds the changelog for 0.67. Generated via the changelog-generator script from 0.66.1 to 0.67-rc0, then updated up to 0.67-rc2, then to latest current (0.67.0-rc.6)
This is the new version of https://github.com/react-native-community/releases/pull/255. To make sure to not lose the feedback on the script on that PR, it has been [recorded here](https://github.com/react-native-community/releases/issues/257).
This PR should be fairly cleaned up compared to its counterpart, but please give it a read 👀 to make sure the entries are correct. The empty sections are currently still in place just in case some new entries should have to be added there.
This will only be published & merged once 0.67.0 is ready/almost ready to go.
## 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
-->
[Internal] [Changed] - Add changelog for 0.67
Pull Request resolved: https://github.com/facebook/react-native/pull/32529
Test Plan: N/A
Reviewed By: lunaleaps, cortinico
Differential Revision: D33532931
Pulled By: GijsWeterings
fbshipit-source-id: b8cbbbea5cf6489a04009f047ce500df62a66767
Summary:
TurboModules: use weakSelf for block sent to main thread.
Changelog:
[iOS][Fixed] - Use weakSelf in objc block instead of self.
Reviewed By: RSNara
Differential Revision: D33488938
fbshipit-source-id: d03c98fb59fbd1fc4b67686251ebec541e5d3e6c
Summary:
## Context
Inside native ViewConfigs, events are declared using these bubbling/direct EventType maps:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
topFoo: {
registrationName: "onFoo"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**Pattern:** Note that the top name (i.e: topFoo) is just the registration name (i.e: onFoo) but with "on" replaced with "top".
On Android, registration names and top names don't have to follow this pattern. The top name can be **anything.** See ReactionsDockView:
https://www.internalfb.com/code/fbsource/[c430d46ed69a03a9d9f40cefa335a6d8bb92f8ec]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionsDockViewManager.java?lines=26-28%2C32-34%2C38
Here, ReactionDismissedEvent.EVENT_NAME is "topDismiss"
https://www.internalfb.com/code/fbsource/[c9f92314a5c46e561a831100dab82164808b05d0]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionDismissedEvent.java?lines=10-11%2C26
And so to provide you the flexibility to specify a custom topName, the codegen supports a customTopName in the direct/bubbling event types:
```
onDismissWithFeedbackReaction: DirectEventHandler<Event, 'topDismiss'>,
```
This generates the two bubbling event type entries in ReactionsDockView:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
// custom top name
topDismiss: {
registrationName: "onDismissWithFeedbackReaction"
},
// what the top name should actually be
topDismissWithFeedbackReaction: {
registrationName: "onDismissWithFeedbackReaction"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**The Problem:** The entry created for "topDismissWithFeedbackReaction" is not necessary. This additional entry creates a discrepancy between ReactionsDockView's static ViewConfig and native ViewConfig. Therefore, this diff removes the second unnecessary entry.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33418730
fbshipit-source-id: 3988ff6906ad1b2e1ef988a19c64d1e042381ab1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32848
If we leverage the side-by-side configuration of the NDK
(see https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41)
we will not have to specify the NDK Path or Version at all.
We will automatically pick the best NDK version selected by AGP.
Changelog:
[Android] [Changed] - Use side-by-side NDK for Android
Reviewed By: ShikaSD
Differential Revision: D33475818
fbshipit-source-id: 16aa4acfc44b94e2f92df89d71e104bf46d7f162
Summary:
Previously we asked users to specify a dependency substitution
rule to properly use the React Native Gradle Plugin.
Here I'm updating the Gradle Plugins setup to allow to use implicit
dependency substitution. This requires to specify a Maven Group and Artifact
Name (through the project name).
This is backward compatible as users will still be allowed to specify a
dependency substitution rule if they wish.
Changelog:
[Android] [Changed] - Leverage Gradle implicit dependency substitution for Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D33404948
fbshipit-source-id: 3323f8e0738fd579ce8ae344cbdc0e4356e7dbd8
Summary:
Fixes https://github.com/facebook/react-native/issues/32835
## Changelog
[Internal] - Make `test_android_template` work regardless of the version
Pull Request resolved: https://github.com/facebook/react-native/pull/32841
Test Plan: Tested locally. Will wait for `test_android_template` to be green.
Reviewed By: hramos
Differential Revision: D33476511
Pulled By: cortinico
fbshipit-source-id: 29a96683afae64cadc9ae4332410cd4d5d9d3e6d
Summary:
Putting the static view config into its own file creates the uncertainty that n > 1 files import the static view config. This isn't true for AndroidTextViewConfig. So, let's just inline this static view config in the NativeComponent that uses it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33341776
fbshipit-source-id: 6fb710b8776d7b9276022c5226acefd7cf8395fb
Summary:
Allow JS to detect if a native UI component is registered to `RCTComponentViewFactory.mm` with JS `UIManager.hasViewManagerConfig(componentName)`.
Fyi, `UIManager.js` is
- `DummyUIManager.js` for Bridgeless,
- `LazyUIManager.js` for Fabric with SVC enabled,
- and `PaperUIManager.js`. for Fabric with SVC disabled.
# How it works in Bridgeless
- `DummyUIManager.hasViewManagerConfig()` checks whether a component exists in the binary. It is hooked up to `unstable_hasComponent()`,
- which is hooked up to the native function `RCTInstallNativeComponentRegistryBinding()`,
- which returns whether a component has been registered to `RCTComponentViewFactory`
- (and also registers the native component if hasn't been registered yet).
Changelog: [Bridgeless][JS] Hook up Venice's UIManager.hasViewManagerConfig with Fabric's native component registry
Reviewed By: RSNara
Differential Revision: D33511659
fbshipit-source-id: 14519378ce3e4247516fcf5a6f83a82aa87c7919
Summary:
Without moving this, we would get this warning about a require cycle on the next diff, because DummyUIManager and LazyUIManager both need unstable_hasComponent.
```
(NOBRIDGE) WARN Require cycle: react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js -> react-native-github/Libraries/ReactNative/UIManager.js -> react-native-github/Libraries/ReactNative/DummyUIManager.js -> react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
```
Changelog: [Internal]
Reviewed By: philIip, RSNara
Differential Revision: D33511566
fbshipit-source-id: fd8c9732408d08ab17335273f86168bf30747929
Summary:
With SVC enabled for codegenNativeComponent, use `UIManager.hasViewManagerConfig(viewManagerName)` instead of `UIManager.getViewManagerConfig(viewManagerName)` to check for whether the native component is in the app BUCK binary.
This is safe because `global.__fbStaticViewConfig` is gated with MC, and the purpose of SVCs is to stop using `getViewManagerConfig` to get view configs from the Paper view managers. Currently no QEs have SVCs enabled.
Changelog:
[Fabric][JS] For codegenNativeComponent, with SVC enabled, use UIManager hasViewManagerConfig instead of getViewManagerConfig
Reviewed By: RSNara
Differential Revision: D33511365
fbshipit-source-id: 58c7020903137e2b5c80ef34a956be04de51628b
Summary: Changelog: [JS] For Fabric with StaticViewConfigs, fix UIManager to use LazyUImanager, not PaperUIManager
Reviewed By: fkgozali
Differential Revision: D33459937
fbshipit-source-id: 4298be7e1e455856cbcf3162b100099cd8c9ce09
Summary:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary:
The CI is currently failing with:
```
Error extracting tarball /tmp/cache1419328940 : tar: root/.cache/yarn: Cannot mkdir: Permission denied tar: root/.cache/yarn/v6
```
The problem is that we're sharing the Yarn cache between two jobs (`test_js` and `test_ios_unit_jsc`) which are executed on two difference executors (a Machine vs a Docker container).
I've update the cache key to be `v5-yarn-cache-{{ .Environment.CIRCLE_JOB }}-{{ arch }}-{{ checksum "yarn.lock" }}` so the job name is accounted when computing the Cache Key.
Moreover the `test_js` test was also failing on `flow check` as one of the library we depend on (`resolve`) added a test with a malformed JSON. I'm fixing this failure as well so the CI is back green.
## Changelog
[Internal] - Updating Yarn Cache path to fix broken CI
Pull Request resolved: https://github.com/facebook/react-native/pull/32834
Test Plan: Verified that the external CI is green: https://github.com/facebook/react-native/pull/32834
Reviewed By: lunaleaps
Differential Revision: D33453702
Pulled By: cortinico
fbshipit-source-id: 52bf42db583eaf6aa913f1bb164566f8c3563d36
Summary:
Let's keep our Gradle infra deps up to date.
I'm bumping Gradle to 7.3.3 which fixes several Log4j CVEs,
AGP to 7.0.4 and the Download Task plugin to 4.1.2
Changelog:
[Android] [Changed] - Bump Gradle to 7.3.3 and AGP to 7.0.4
Reviewed By: mdvacca
Differential Revision: D33430789
fbshipit-source-id: b8f260beb4a9cc962ea3743610bfb4ead004d6cb
Summary:
`WritableNativeMap` has two constructors:
```c++
WritableNativeMap();
WritableNativeMap(folly::dynamic &&val);
```
but `WritableNativeMap` has only one constructor:
```c++
WritableNativeMap();
```
Without a second constructor, I am not able to create `WritableNativeMap` from the existing array. I added this second constructor because I need it for `react-native-reanimated`.
## Changelog
[Android] [Added] - Added missing constructor to WritableNativeArray
Pull Request resolved: https://github.com/facebook/react-native/pull/32796
Test Plan:
```c++
std::shared_ptr<jsi::Runtime> rt = facebook::hermes::makeHermesRuntime();
jsi::Value value;
WritableNativeMap::newObjectCxxArgs(jsi::dynamicFromValue(*rt.get(), value));
```
Reviewed By: cortinico
Differential Revision: D33285316
Pulled By: lunaleaps
fbshipit-source-id: 1bbd816892f34ae6fef747066893fe3b803c088d
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
Adds an experimental replacement for preallocation revision checks on Android mounting layer. Instead of checking revisions of props, we remember tags of preallocated/previously allocated views and use this as a filter to avoid issuing extra create and preallocate commands on copy.
This method is a bit more expensive on memory, but is more precise than relying on revisions.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D33038768
fbshipit-source-id: fc98c2a7912e162a3845ca80488635bffaf8cc7f
Summary:
changelog: [internal]
You can read more about this rule on https://clang.llvm.org/extra/clang-tidy/checks/modernize-pass-by-value.html
# Isn't it wasteful to copy? Isn't reference more efficient?
This rule of thumb is no longer true since C++11 with move semantics. Let's look at some examples.
# Option one
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
private:
std::string text_;
};
```
By using reference here, we prevent the caller from using rvalue to and avoiding copy. Regardless of what the caller passes in, copy always happens.
# Option two
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
TextBox(std::string &&text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, we provide two constructors, one for const reference and one for rvalue reference. This gives the caller option to avoid copy. But now we have two constructors, which is not ideal.
# Option three (what we do in this diff)
```
class TextHolder
{
public:
TextBox(std::string text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, the caller has option to avoid copy and we only have single constructor.
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D33276841
fbshipit-source-id: 619d5123d2e28937b22874650366629f24f20a63
Summary:
changelog: [internal]
For some reason, using `TextLayoutManager::Shared` in `TextInputShadowNode` trips up clang tidy linter. We have a plan to move away from `*::Shared` anyway, so let's remove it from `TextInputShadowNode` now.
Why do we want to move away from `*::Shared`?
Using `TextLayoutManager::Shared` is confusing for people unfamiliar with Fabric's codebase. It expresses a concept of immutability but uses term `shared`. Term shared is already used in C++ `std::shared_ptr`.
Reviewed By: fkgozali
Differential Revision: D33186422
fbshipit-source-id: 10ee588735997f5fedc372a1d1e3d9cd9684178a
Summary:
This diff is a prototype to enable ConcurrentRoot in RN VR apps
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33200238
fbshipit-source-id: 45f700808cdc3a970bcddef858944e764a7260bd
Summary:
Quick refactor of ReactRootView where I extract 'Fabric' check into a method
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D33269025
fbshipit-source-id: 2647d5870f3b5fcc5a940a5924a39ca43b5bebac
Summary:
This diff gates the useage of overflowinset to hit test algorithm to fabric renderer only.
Changelog:
[Internal][Android] - Use overflowInset for fabric only
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D33237281
fbshipit-source-id: e5cd78ee97f62f100d42d016241d1544fb0953ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32790
As the name says, I've added a `newArchEnabled` property that can be used to toggle the
New Architecture in the new app template. Users can use this to try the New Architecture in their
project by either:
* Set `newArchEnabled` to true inside the `gradle.properties` file
* Invoke gradle with `-PnewArchEnabled=true`
* Set an environment variable `ORG_GRADLE_PROJECT_newArchEnabled=true`
The Project property will also control if:
* ReactNative dependency should be built from source or not.
* The NDK should be enabled or not.
Please note that this requires RN 0.68.x to run properly (it won't work with 0.67 RCs) or a Nightly version of React Native.
Changelog:
[Android] [Added] - Setup a `newArchEnabled` property to Opt-in the New Architecture in the template
Reviewed By: ShikaSD
Differential Revision: D33065373
fbshipit-source-id: 32085f5b071d6243936bafd91425b5b43e5b5101
Summary:
Just clarifying the purpose of this library.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D33245053
fbshipit-source-id: b4325415774ca33b34b5ba53d222a19f88e2175f
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
The previous diff shows how `overflowInset` could improve hit test algorithm performance. This diff adds experiment to it in order to:
1. Understand the perf improvement in production
2. Provide quick way to rollback in production -- the changes are used by FB4A as well as VR
3. The changes will pass more instructions over JNI, which may have impact on perf.
To share the MC param values in both Java and C++ side, the value is hosted by `ReactFeatureFlags` and fetched in `FbReactInstanceHolder`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33179310
fbshipit-source-id: 327100d41f7b5a668ff0d2afabcdd1fc16cb5a18
Summary:
This diff adds `overflowInset` values in RN Android. These values are used to give an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR:
{F687030994}
In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`.
This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode.
This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)"
To fix this issue, I added the support to `overflowInset` to RN Android by
1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction
2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java`
3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages
4. Adding implementation of getter and setter for `overflowInset` in various views
5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children
Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code.
Changelog:
[Internal][Android]
Reviewed By: JoshuaGross
Differential Revision: D33133977
fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
Summary:
Tests for Native Modules. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081127
fbshipit-source-id: 3d7270dddd568090ec93d475a08a6a6011dad63c
Summary:
Tests for Native Components. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080789
fbshipit-source-id: ae71d384f6d93da6b89eeb179c4ba7ebcd6ae03d
Summary:
These files are directly copied from the flow parser to aid in reviewing the next two Diffs: D33080789 and D33081127.
The only things that were changed during the copy are the import/require paths to ensure this diff could ship independently. (For this diff, these tests will still test the flow parser instead of importing the typescript parser).
Changelog:
[Internal][Add] - Copy Flow parser tests to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33136296
fbshipit-source-id: 007e18618c9eba13728d19e4e342fbe9642adacc
Summary:
This adds the main entry point for the TypeScript parser as well as adds the logic to use the new parser if the spec file's extension is `.ts`
`js/react-native-github/packages/react-native-codegen/src/parsers/typescript/index.js` is mostly a direct copy from the flow parser.
Changelog:
[General][Add] - Choose Flow or WIP TypeScript Codegen parser based on spec's file extension
Reviewed By: RSNara
Differential Revision: D33081296
fbshipit-source-id: 267823685e6723e3c1f19752bbbe692e895c075b
Summary:
Similar to D33080623, this is the logic for parsing Native Modules and the files were copied from the flow parser and updated for TypeScript. The logic and code path is almost identical to the flow parser.
Also, like D33080623, while there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081035
fbshipit-source-id: 5a196e4693df73c0fb88abafe2b4e6be032ea7ed
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33081035
Changelog:
[Internal][Add] - Copy Flow parser module logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33134982
fbshipit-source-id: 9afea2ce15404338fd2c920a8b7eafe980f18688
Summary:
This is the logic for parsing Native Components. The files were copied from the flow parser and updated for TypeScript specific types and differences in the shape of the AST. The logic and code path is almost identical to the flow parser.
While there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080623
fbshipit-source-id: a68c8d4c4570e65a88a97dcea3cd18a6976c53c7
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33080623
Changelog:
[Internal][Add] - Copy Flow parser component logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33130222
fbshipit-source-id: ba7233b17d698793559da8b81bb7e1a78654e614
Summary:
These are utility functions that the TypeScript parser uses and are copied from and follows the same logic as the flow parser with some TypeScript specific changes. Also added dependency of `babel/parser` as the parsing engine we're using for TypeScript.
Changelog:
[General][Add] - Add foundation for WIP TypeScript parser for Codegen
Reviewed By: RSNara
Differential Revision: D33080527
fbshipit-source-id: d4bd515af549a41f07a2e3ee1a16b5ed678180b2
Summary:
This is a direct copy of the following files from the flow parser:
```
react-native-codegen/src/parsers/flow/errors.js
react-native-codegen/src/parsers/flow/utils.js
```
Changelog:
[Internal][Added] - Copy flow parser foundation files to aid in diff review
Reviewed By: RSNara
Differential Revision: D33137685
fbshipit-source-id: 1345c8bb0785c90b2bd64d4e6e2447f3fdb0ae6b
Summary:
Currently the codegen does not include component with field `interfaceOnly` set to `true` in the `ThirdPartyFabricComponentsProvider`.
These components need to be added to this file, so that non-core components can be used in fabric.
## Changelog
[General [Fixed] - Fixes GenerateThirdPartyFabricComponentsProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/32779
Test Plan:
Run codegen with component outside of core on iOS.
Check if components with and without `interfaceOnly` are added to `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D33235363
Pulled By: ShikaSD
fbshipit-source-id: e7224d2123e4da0da912fe677dae32d3aaea2ec8
Summary:
changelog: [internal]
In an effort to make our codebase more approachable, I'm enabling more clang-tidy rules.
Read more about modernize-avoid-c-arrays in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-c-arrays.html
Reviewed By: ShikaSD
Differential Revision: D33187162
fbshipit-source-id: c6b3888f67d095274bb492a01132985ae506c0d5
Summary:
the docs mostly use npx to run react native (https://reactnative.dev/docs/environment-setup) and I do not have react native installed globally, so I think npx should be used here as well
<!-- 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] [changed] - improved bug template
Pull Request resolved: https://github.com/facebook/react-native/pull/32788
Test Plan: not needed
Reviewed By: lunaleaps
Differential Revision: D33235384
Pulled By: cortinico
fbshipit-source-id: e8d50bb6172066da8d656d3efd0cb6cd17ab1487
Summary:
Binding.cpp shares many responsibilities, including surface management and mount. This change refactors mount (and mount items) into separate files, while retaining the same functionality and interface.
Changelog:
[Internal][Android] - Refactor mount into FabricMountingManager
Reviewed By: mdvacca
Differential Revision: D32977902
fbshipit-source-id: 07cdf5a19033fccaa81901e5b9a4d44192ec7853
Summary:
changelog: [internal]
I will be enabling more clang tidy rules in Fabric to make it easier for new contributors and standardise the codebase. \
You can read more about the rule in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-bind.html
Reviewed By: ShikaSD
Differential Revision: D33162192
fbshipit-source-id: b4bb332f3134c42c49559a8baf10aeb7a7fdd87f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32769
Changelog: [Internal] Re-purpose bump-oss-version to guide releaser to correctly tag the release and trigger relevant CircleCI jobs
Reviewed By: sota000
Differential Revision: D33121691
fbshipit-source-id: 739f920cd9a04dfb436aff1abe9a05a51df4c32c
Summary:
Changelog: [Internal] Update the comments in publish-npm script to changes in release workflow and leverage `isTaggedLatest` utility.
A lot of this information will be moved to the Release wiki on Github
Reviewed By: ShikaSD
Differential Revision: D33110407
fbshipit-source-id: b01a555a3eed6e505a3b0ad220a0c2c54459ab03
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32757
Changelog: [Internal] - Update release automation to still be manually triggered as from discussion: https://github.com/reactwg/react-native-releases/discussions/7
A releaser needs to do the following on a release branch like `0.99-stable`:
* For an initial release branch cut:
* Tag the head of the branch `git tag publish-v0.99.0-rc.0`
* `git push origin 0.99-stable --follow-tags`
* For cherry-picks on the pre-release:
* Make the picks on `0.99-stable`
* Tag the head of the branch `git tag publish-v0.99.0-rc.1`
* `git push origin 0.99-stable --follow-tags`
* For promoting pre-release to stable with intention of making this the `latest` npm version:
* Tag the head of the branch `git tag publish-v0.99.0`
* Tag the head of the branch `git tag latest`
* `git push origin 0.99-stable --follow-tags`
Follow-up diff to make this codified via a script
Reviewed By: sota000
Differential Revision: D33101594
fbshipit-source-id: 74b065229a3705fccbe1a25ed7ece4a28d9aa76d
Summary:
Changelog: [Internal] Remove un-necessary package installs which was using `npm install flow-bin --save-dev` which was wiping out our `node_modules` from the circleCI yarn install.
It was un-necessary as we already have `flow-bin` as a dependency in our current set-up.
In addtion, we were running `npm pack` without properly copying over our package.json dependencies (which occurs in `prepare-package-for-release`) for a consumable react-native package.
This may not have caused issue but technically we were creating an "incomplete" package to do our e2e testing on.
Reviewed By: charlesbdudley
Differential Revision: D33197965
fbshipit-source-id: 6583ef1f8e17333c0f27ecc37635c36ae5a0bb62
Summary:
Inits RootView to display size for the early surface start experiment.
Before that experiment, we always had the view measured before the surface was initialized, but here layout can sometimes happen before measure. Surface defaults use [0; Inf) for size constraints, potentially causing a crash in Yoga. This change avoids that by making a guess on default layout size with `displayMetrics`
Changelog: [Internal]
Reviewed By: feedthejim
Differential Revision: D33190397
fbshipit-source-id: 3b1b84135a4980ef2fde4024ec84a448199e00b8
Summary:
changelog: [internal]
Only execute tasks that are expired when in synchronous mode.
Reviewed By: philIip
Differential Revision: D33062746
fbshipit-source-id: 1825cb572202d1f5dc18eb2b481dd3c20e8e91ba
Summary:
This diff adds extra logging to track how long does it take to exeucte different stages of the fabric commit
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D33183070
fbshipit-source-id: 69e31bef69c9d9ec57dc7e00e4c36e278eb30cb6
Summary:
Just released a new version that supports Android App Bundle correctly
https://github.com/facebook/SoLoader/releases/tag/v0.10.3
Reviewed By: passy
Differential Revision: D33167010
fbshipit-source-id: 69c54b1674b06b05a01a468d9f324475e5c232cf
Summary:
changelog: [internal]
Just getting rid of some implicit type conversions and using std::max and std::min instead of macros.
Reviewed By: philIip
Differential Revision: D33161766
fbshipit-source-id: c72011c54f35a145afa236f1dc3d185b19e46cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32777
Changelog: [iOS][Added] Added the new architecture support to the new app template. To apply this change to your project, you will need to update your Podfile. You can try it by using "RCT_NEW_ARCH_ENABLE=1 pod instal" command which updates necessary C++ flags and enable the new codegen discovery required for the new architecture. As context, We've modified the iOS template to have code required to enable the new architecture (aka Turbo modules and fabric / renderer) which requires updating AppDelegate. We also added the support in RNTester as well. We will be sharing more documentation about the new architecture.
Reviewed By: dmitryrykun
Differential Revision: D33154825
fbshipit-source-id: a46b98308e9d29780b6a5245e8faa8be1e257802
Summary:
Similar to the previous diff, we should not allow view group that has clipChildren set to true to respond events that are out of bounds.
Changelog:
[Internal][Android]
Reviewed By: ShikaSD
Differential Revision: D33102331
fbshipit-source-id: de3a5ffdd5293ada1d2c211659e79edc697b5d15
Summary:
In D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), we added fix to the issue where touches on the child view that is outside of its parent view's boundary are not registered. The only exception to that is if the parent view has overflow style `overflow: hidden`. In that case, touches happen outside of the parent view should be ignored.
{F686521911}
That fix works, but it increases the complexity for the DFS algorithm used to find the touch target in two ways:
1. Before we only traverse views that contain the touch event point. If the touch event point is outside of the view, we won't step in and traverse that part of the tree. This is actually what caused the initial problem. The fix removed that boundary check (where `isTransformedTouchPointInView` used to do) and push it later. This increases the number of tree traversal a lot.
2. The check for `overflow: hidden` is happened after we find a potential target view, which means we've spent time to find the target view before we decide if the target view is even a candidate.
This diff aims to update for the #2 item above. Since we are checking the style of the parent view, not the target view, it's not necessary to check that after we find the target view. We could check the parent view and if it has `overflow: hidden` on it, any pointer event that are not in the boundary can be ignored already.
Changelog:
[Internal][Android]
Reviewed By: mdvacca, ShikaSD
Differential Revision: D33079157
fbshipit-source-id: c79c2b38b8affb9ea0fd25b5e880b22466ab7ed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32775
Changelog: [Internal] Fix build issues for the new app template with the new architecture enabled
Reviewed By: philIip
Differential Revision: D33157325
fbshipit-source-id: ee63f38fbfc088ca193dfa1b48f4b6611257b787
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32770
Fest is EOL and is replaced by assertj, originally a fork of Fest. This change replaces the usages in internal tests and removes the dependency.
Changelog:
[Internal][Android] Replace fest with assertj
Reviewed By: genkikondo
Differential Revision: D33143454
fbshipit-source-id: c1cbe5b064d007018f73858b2913806c11aa08af
Summary:
Changelog: [internal] Refactor RCTAppSetupUtils to c functions.
Since RCTAppSetupUtils doesn't retain any states, we don't need it to be a class.
Reviewed By: philIip
Differential Revision: D33084352
fbshipit-source-id: 1372a2737eafffa46ee6e5164a970dd12699c71c
Summary: Changelog: [internal] Changed teh new architecture flag in the new app template to RCT_NEW_ARCH_ENABLED
Reviewed By: philIip
Differential Revision: D33083694
fbshipit-source-id: f2cc6c564c724b4ebed7b465a533464b6717ac27
Summary:
Changelog: [internal] Added fabric option to the default app template.
Use RCT_TM_FABRIC_ENABLED C++ flag to enable fabric.
Reviewed By: sammy-SC
Differential Revision: D33052956
fbshipit-source-id: 28313829c80abcf02baa521bdb0b70213c94a97f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32752
Changelog: [internal] Add an optional support for Turbomodule. Define RCT_TM_FABRIC_ENABLED to enable the new architecture.
Reviewed By: philIip
Differential Revision: D33052777
fbshipit-source-id: 6d32790586bb51f9c9244344522c95245c912114
Summary: Changelog: [internal] removed babel-plugin-codegen from the dependency. The dependency will exist in the app template.
Reviewed By: lunaleaps
Differential Revision: D33138950
fbshipit-source-id: f71fa4ca55d13715ccd1ade1424bc3cddbb10d1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32764
Changelog: [Internal] This diff refactors react_native_pods.rb so that it's a bit more readable/maintainable.
With the intorduction of the codegen discovery script, we have two script phases that shares some code. I've factored it out of the main file and wrote a snapshot test so that it's easier to see the output script file.
Reviewed By: cortinico
Differential Revision: D33045541
fbshipit-source-id: 9c80b5d7e11862cc44275e36882487a7d63e8125
Summary:
This diff stack enables codegen to parse TypeScript spec files and generate an identical schema to our current Flow parser.
This first diff is a small cleanup of our current flow parser.
Changelog:
[General][Fixed] - Fix typo in error string and improve consistency in Codegen's flow parser tests
Reviewed By: sota000
Differential Revision: D33080423
fbshipit-source-id: 7bf817761a7704d807a0b809c9f2270354b5c6fa
Summary:
Modernize our null annotations
From the swift blog:
This feature was first released in Xcode 6.3 with the keywords nullable and nonnull. Due to potential conflicts with third-party libraries, we’ve changed them in Xcode 7 to the _Nullable and _Nonnull you see here.
drop-conflicts
Reviewed By: cuva
Differential Revision: D33121042
fbshipit-source-id: 821f5ec858d9afd5bfb1d6081c669f4ca18a36ed
Summary:
Scheduler and JavaUIManager mutexes share the lifetime (between install-uninstall), so we can use singular shared lock to ensure that both sections are locked exclusively for install/uninstall and in shared mode for access.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33130686
fbshipit-source-id: bf283fd5410e386d2635645e17680a9f4cb7f288
Summary:
Allows `CxxModule` objects to set their `instance_` member before `getMethods()` is invoked, allowing for the `Method` callbacks to capture a weak reference to `getInstance()` if needed.
## 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] - Set CxxModules' Instance before retrieving their Method vector.
Pull Request resolved: https://github.com/facebook/react-native/pull/32719
Test Plan: Ensure this statement swap does not break any scenarios with existing CI validation.
Reviewed By: JoshuaGross
Differential Revision: D32955616
Pulled By: genkikondo
fbshipit-source-id: fd7a23ca2c12c01882ff1600f5aef86b1fe4a984
Summary:
Adds a return value to `MessageQueueThread#runOnQueue`, it's implementors and one caller.
It is currently possible for a callback to not be called (because the HandlerThread has been shutdown). If the callback is mission-critical (frees resources, releases a lock, etc) the callee has no indication that it needs to do something.
This surfaces that information to the callee.
Changelog:
[Android][Changed] - Made `MessageQueueThread#runOnQueue` return a boolean. Made `MessageQueueThreadImpl#runOnQueue` return false when the runnable is not submitted.
Reviewed By: RSNara
Differential Revision: D33075516
fbshipit-source-id: bd214a39ae066c0e7d413f2eaaaa05bd072ead2a
Summary:
When using the nightly builds, metro fails with an error because of missing scripts/packager-reporter.js. The file is not included in the published files so this is why.
## 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
-->
[Internal] [Fixed] - Add missing scripts/packager-reporter.js file in npm published files
Pull Request resolved: https://github.com/facebook/react-native/pull/32763
Test Plan: Test that nightly builds work when adding the missing file.
Reviewed By: motiz88
Differential Revision: D33128315
Pulled By: ShikaSD
fbshipit-source-id: 617d124205edf63dbca8da50336ca895f5ce866a
Summary:
changelog: [internal]
Just moving code that doesn't belong to UIManagerBinding out of the class.
Reviewed By: philIip
Differential Revision: D33060412
fbshipit-source-id: 2d54929072cef14fd1fa6b70bde382ae21ecff45
Summary: Changelog: [internal] Adding snapshots for script_phases. These snapshots are taken from working scripts.
Reviewed By: cortinico
Differential Revision: D33045627
fbshipit-source-id: fbc1e005954cd185fb5f9b48c55a073ad9d5523a
Summary: Changelog: [internal] Move script_phases script out of react_native_pods.rb so that it's easier to review/debug.
Reviewed By: cortinico
Differential Revision: D33054423
fbshipit-source-id: 460de83a38959a1e45e37f8eda7fe364026fb571
Summary:
Fabric uses a cache where it stores the result of the text measurement in C++ (to avoid unnecessary text measurement that are very costly). This cache has a "max size" of 256 and this size is not enough to store all the texts we have in the screen
In my tests, the amount of texts being measured are ~290 and after scrolling many times they increase to 611.
This diff increases the size of the TextMeasure to 1024 for users in the experiment. As a result this improves performance of HoverEvents by +5x times (see test plan)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33112788
fbshipit-source-id: e15feecf0f54da62b252892d37a64fb4ead29e22
Summary: Changelog: [internal] Fixing a couple of bugs when running with USE_CODEGEN_DISCOVERY.
Reviewed By: mdvacca
Differential Revision: D33115937
fbshipit-source-id: bb770b406b6dbebfefccac488a7c40caaafa6ca6
Summary:
The generated fabric components provider includes fabric headers that won't be included when building without fabric.
This checks the fabric enabled param and skip generating the provider in that case.
## Changelog
[iOS] [Fixed] - Don't generate fabric component provider if fabric is not enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/32761
Test Plan: Test that an app with codegen discovery enabled now builds properly with fabric disabled.
Reviewed By: ShikaSD
Differential Revision: D33111968
Pulled By: sota000
fbshipit-source-id: 3704e11b1e614369f1c652e8cb1acba51cf7ffad
Summary: Changelog: [Internal] Remove this workflow for now as there are some errors and we want to revisit this action and move it under react-native-community
Reviewed By: sota000
Differential Revision: D33103444
fbshipit-source-id: c64bb79df8700af110ddbfbfa3d60ac9a849c964
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32755
Changelog: [Internal] Make the Reat-Codegen script_pahses only triggered when the in-app libaries are modified. When other libraries like ones inside node_modules are modified, you'll need to run `USE_CODEGEN_DISCOVERY=1 pod install` to update the source.
Reviewed By: cortinico
Differential Revision: D33007986
fbshipit-source-id: 0546bbd1d57cd54a482d71b43b296484de60a92c
Summary:
With the updates to touch processing rolled out, we can remove the feature flag and clean up the old code. The old path is now used exclusively by legacy renderer and Fabric uses new `EventEmitter#receiveTouches` method to process touches.
Changelog:
[Changed][Android] - Update touch processing internals
Reviewed By: mdvacca
Differential Revision: D32953664
fbshipit-source-id: 517a4ce6ce9bc15528c2db94d7d11bdff8b78743
Summary:
Applies suggestions from default preset that make sense in our codebase
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33010231
fbshipit-source-id: 6bc9edf01fd9bd9938d211e3494dd1a127b24eaa
Summary:
Applies suggestions from clang-tidy. The automatic linter seems to be broken atm, so I used default config from Android Studio, filtering out meaningless suggestions.
Changelog: [Internal]
Reviewed By: cortinico, sammy-SC
Differential Revision: D32994138
fbshipit-source-id: e8edf53f0cb8b0eda4ff8bb8bf8f5196827efd68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32731
Changelog: [internal] Trigger codegen discovery script when building React-Codegen so that users won't have to run pod install every time modifying fabric / turbomodule library.
Reviewed By: cortinico
Differential Revision: D32979871
fbshipit-source-id: 18550b6b010a9a2b8b7513aaa3b6a7322ea83eff
Summary:
changelog: [internal]
[CALayer opacity] is of type `float`, not `CGFloat`.
Reviewed By: philIip
Differential Revision: D33058967
fbshipit-source-id: 98b214e32f6d35e904a7abb0e01c2d01da50a285
Summary:
Changelog: [internal] Move initital setups in AppDelegate to util classes.
This will make it easy to apply the new architecture changes in the future.
Reviewed By: cortinico
Differential Revision: D33051517
fbshipit-source-id: 16e326b7816fae83df65450c545e7dce1a93b9d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32749
Changelog: [Internal] Move the use_react_native_codegen_discovery call to use_react_native.
Found out that pre_install doesn't get invoked until all podspecs are read. This wouldn't work because I want use_react_native_codegen_discovery to generate React-Codgen podspecs.
I also think it's better to have less logic in Podfiles as it's hard to update once users set it up.
Reviewed By: cortinico
Differential Revision: D33054318
fbshipit-source-id: 6d62be454610c8a1d55988fe376ee3f187510a36
Summary:
Changelog: [Internal] changing the extention from AppDelegate.m to AppDelegate.mm in the app template to support the new architecture.
Most changes were generated when opening the xcworkspace.
Reviewed By: cortinico
Differential Revision: D33051442
fbshipit-source-id: f472a9df26db11a02fc9f7d0544f0207e7c3e7ca
Summary: Changelog: [internal] Add /template/ios/build to gitignore. The folder is auto generated for ios.
Reviewed By: cortinico
Differential Revision: D33051582
fbshipit-source-id: ccf84fa0594d1fbbf224d92004dd05987c9deae7
Summary:
Follow up to https://github.com/facebook/react-native/issues/32683 to also link hermes-inspector statically.
## Changelog
[Android] [Fix] - Static link for hermes-inspector
Pull Request resolved: https://github.com/facebook/react-native/pull/32694
Test Plan: Tested a clean build and made sure hermes-inspector.so doesn't exist anymore.
Reviewed By: cortinico
Differential Revision: D32791208
Pulled By: ShikaSD
fbshipit-source-id: 6076b263469b9e2c6176d488d13292d4f1731dcc
Summary:
changelog: [internal]
Provide `UIManager` to `UIManagerBinding` in constructor to make the API safer.
Reviewed By: philIip
Differential Revision: D32668892
fbshipit-source-id: a15cd295196a60c3f46997e59c05c4f90503e18d
Summary:
## iOS
On iOS:
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, it's safe to have all HostComponent Static View Configs extend <View/> Static View Config.
## Android
On Android, the model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, it's not safe to have all Android HostComponent Static View Configs to extend <View/>'s Static View Config:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32187832
fbshipit-source-id: 9a057abb3f58801615891c21e42ad4cfa5c69f21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32737
Changelog: [Internal] Adding packages/babel-plugin-codegen to react-native. This will add a missing piece to enable the new architecture in nightly build.
Reviewed By: ShikaSD
Differential Revision: D33034294
fbshipit-source-id: 766b97ddaddeaf0813ed9cf9b08a81eac93052ac
Summary:
## Changelog:
[General] [Changed] Export Flow type for deceleration rate for use in other files to keep deceleration rate prop values consistently typed
Reviewed By: lunaleaps
Differential Revision: D32989199
fbshipit-source-id: 2e2fef0721de0d0eb60aaefdbb635788bfc8c1f1
Summary:
lunaleaps did [0.66.4](https://github.com/facebook/react-native/releases/tag/v0.66.4) yesterday - this PR adds the entries for it in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entry for 0.66.4
Pull Request resolved: https://github.com/facebook/react-native/pull/32733
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D33017547
Pulled By: cortinico
fbshipit-source-id: 2ffad5d65c7b308686f29395fb6fc54b85804bf0
Summary:
So I was adding a new HTTPCookie prop to our WebView native component and found that my build was [failing](https://www.internalfb.com/diff/D32602297?dst_version_fbid=338931330931416) due to "redefinition of `value`". Looks like we use the name of the prop as a variable name during codegen, and this can conflict with some other hardcoded variable names. Rather than try and come up with a better prop name, I figured we can just append some string to our codegen name to reduce the chance for conflicts.
Changelog:
[Internal][Changed] - Change codegen variable naming to prevent conflicts to prop names
Reviewed By: JoshuaGross
Differential Revision: D32967807
fbshipit-source-id: 1b3631ec783b229eddfd3c801ffbb397910fc882
Summary:
AnimatedValue fires a callback with the current value (raw value + offset) after calling it's `stopAnimation` method. The `_value` field on the `AnimatedValue` node is not necessarily kept in sync with the NativeAnimated value node, so the value provided to the callback may be out of sync.
This change checks if the `AnimatedValue` is a native node and passes the callback to the `NativeAnimatedAPI.getValue` callback, defaulting to the previous current JS node state if the node is not native.
Changelog:
[General][Fixed] - AnimatedValue.stopAnimation callback with correct value for NativeAnimated
Reviewed By: yungsters
Differential Revision: D32968572
fbshipit-source-id: b83f86eabe5456f762a15bc29cacb43f84513f6c
Summary:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
feels like this should be shared across oss
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D32940936
fbshipit-source-id: 76fa8fdac5a768586f7f3e916af2c57685a70e12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32724
Changelog: [internal] Fix analyze_pr which was getting stuck at apt-get install openssl ca-certificates
Added -y so that it will install openssl without asking Y/n question.
```
The following packages will be upgraded:
openssl
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 620 kB of archives.
After this operation, 1024 B disk space will be freed.
Do you want to continue? [Y/n]
```
Reviewed By: TheSavior
Differential Revision: D32977991
fbshipit-source-id: 6a2e88f7fe61061fd5c18fc8cb28a3b9bfeedaf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32723
D32128979 (https://github.com/facebook/react-native/commit/baded0f9e3e2be43da0c046bd35f4a69362cbb45) added a fabric example to RNTester, and that broke the circle CI test because of a build issue introduced by an build ordering issue (codegen for the example component didn't happen in time). Using codegen discovery the issue wouldn't happen, so I made it only install when use_codegen_discovery == 1.
Caveat is that this would make opening the New Architecture Example throw an error since the native module doesn't exist when running pod install without USE_CODEGEN_DISCOVERY flag. Therefore, I added a message that codegen discovery needs to be enabled in order to try out the example.
Changelog: [internal] Fix rn-tester build
Reviewed By: mdvacca
Differential Revision: D32974821
fbshipit-source-id: b0318ebf122ba00c0121c17a819a730133ab67be
Summary:
I added some functionalities to react-native-codegen to support the new architecture. Publishing the new version so that those are available to use.
Changelog: [internal] Updated react-native-codegen version
Reviewed By: cortinico
Differential Revision: D32941951
fbshipit-source-id: f1ab3d72c76ac153939c634655a4725b4f49d48d
Summary:
#Changelog: [Internal] - This is an attempt to fix public publishing of eslint-plugin-specs. Currently, internal consumption of this package assumes access to `react-native-codegen/src` but for external usage, we leverage the published `react-native-codegen` which transforms files out to the `lib` folder vs. `src`.
For a similar-ish suit, this change is adding a prepublish step that will very basically update the references.
Reviewed By: mdvacca
Differential Revision: D32910080
fbshipit-source-id: f5e508090cbbf5097a848ddef3b721002a6c6277
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
Originally introduced in D2022018
Tried to make the processor optional when no rounding is required, but found even that was not strictly necessary.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D32675492
fbshipit-source-id: 8dfdbf0e4347155045f77b1fba00a59086fe7a33
Summary:
This diff adds a new architecture example to RN Tester for the iOS App
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128979
fbshipit-source-id: b008671553065f4965ba332ac06e01f54d70b331
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
Summary:
changelog: [internal]
Event `onChangeText` does not exist in TextInput. Let's remove this method to avoid confusion.
Reviewed By: philIip
Differential Revision: D32882056
fbshipit-source-id: 37eb260b84dd7d6cce412ce1bc39c0cbf9cab112
Summary:
Changelog: [Internal] babel-plugin-codegen.js to fallback to use lib instead of src.
The bubel plugin uses react-native-codegen/src but it's not compatible when react-native-codegen is installed as a separate dependency (which is the case for OSS).
Reviewed By: cortinico
Differential Revision: D32908846
fbshipit-source-id: 1d3e3a3485e94e2f051e220d76dd2dbcdd8070a8
Summary:
changelog: [internal]
Exposes a new flag on RuntimeScheduler: `unstable_getIsSynchronous`. Flag indicates if the current code is run synchronously and therefore commit phase should be synchronous.
Unit tests will be added later, to keep this diff short. This code path is not executed yet.
Reviewed By: mdvacca, ShikaSD
Differential Revision: D32677814
fbshipit-source-id: e01d4fff7e716d627ff99fe104965851138c3aef
Summary:
This class is not used and can be safely deleted
Changelog: [Internal] Delete unused Android event emitter
Reviewed By: mdvacca
Differential Revision: D32916706
fbshipit-source-id: 6dceb6b6ed9d201d96454bf0d646853c5c893d59
Summary:
Changelog: [internal] Fixes the output path for the fabric provider.
The old path wouldn't work when the pod installation path is not the same as the app dir.
Reviewed By: cortinico
Differential Revision: D32911493
fbshipit-source-id: 74a8481a2e8397024645d7daff2897e4b0b5454e
Summary: Changelog: [internal] We added generate-artifacts.js and generate-provider.js for codegen, and this diff adds that to the package.json so that it gets included.
Reviewed By: cortinico
Differential Revision: D32910033
fbshipit-source-id: 4982704fd3dac12b9cb64c4b3facb496abef4343
Summary:
This diff add custom prediction for fling distance support. This is needed for customize fling animator to calculate predicted fling distance, instead of using the overscroller that may not be used by the animator.
More context on this -- when fling happens, our code will first predict the final fling position `p`, apply the snapping logic to decide the expected snapping position `pSnapping` given `p`, scroll velocity and children layout, then trigger the overscroller (existing) or custom fling animator to finish the fling.
Currently, the prediction logic is done with overscroller, and custom fling animator has no control over how the predicted fling distance should be. Changes in this diff allow the animator to override `getExtrapolatedDistance` method and provide that information.
Changelog:
[Android][Added] - Add new API for custom fling animator to provide predicted travel distance for its fling animation.
Reviewed By: mdvacca
Differential Revision: D32571734
fbshipit-source-id: d34b969206f8b6cb5c68d2f50a18749bfebbc97e
Summary:
React-native Xcode build steps (such as "Build JS Bundle") rely on `find.node-sh` to find the correct node binary, using nvm if present. We do this because Xcode may run build steps in a fresh shell environment, presumably for repeatable builds.
This PR fixes `find-node.sh`, to respect any `.nvmrc` file that may be present in the build environment.
Today: `find-node.sh` will set the shell environment to the system node version, and ignores any `.nvmrc` the project may provide to pin node for repeatable builds. By ignoring `.nvmrc`, node versions may differ depending on system environment — between developer laptops, or between developer and CI environments. 😞
This problem has been been noticed before in https://github.com/facebook/react-native/issues/8887
### Should this fix happen upstream?
Unfortunately this nvm behavior [is intended](https://github.com/nvm-sh/nvm/issues/2053), for backwards compatibility
## 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] - find-node.sh now respects .nvmrc
Pull Request resolved: https://github.com/facebook/react-native/pull/32712
Test Plan:
Before:
```bash
# nvm isn't loaded
$ which nvm
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v17.0.1
```
After:
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v16.13.0
```
After (no .nvmrc, should preserve previous behavior):
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ source ./scripts/find-node.sh
$ nvm ls|grep default
default -> v14.17.1
# Expected: v14.17.1
$ node --version
v14.17.1
```
Reviewed By: sota000
Differential Revision: D32889629
Pulled By: ShikaSD
fbshipit-source-id: 527384055e303a87bad43413fb66a7fd117d1a63
Summary:
Retrying D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original 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: D32578661
Pulled By: sota000
fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
Summary:
Changelog: [Internal] Adding an option to change the component name for react native codegen.
This will help some use cases where the target name and the actual component names are different.
Reviewed By: fkgozali
Differential Revision: D32852437
fbshipit-source-id: 054a62214cf8bcfea5662b8fba6582d9d7209f90
Summary:
This diff refactors method `predictFinalScrollPosition` in `ReactScrollView` and `ReactHorizontalScrollView` to the helper class. This will make future changes to the prediction logic easier.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32571735
fbshipit-source-id: 7e7e21ac51f929a017cd43de094ed39478fe4032
Summary:
This diff fixes an edge case where scroll to the end of the list may trigger a bounce back effect.
This issue is a regression from D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea) (See [this comment](https://www.internalfb.com/diff/D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea)?dst_version_fbid=263960175698224&transaction_fbid=566201141113715)) that zero velocity fling at the end of the scroll view makes the next fling animator use previous post animation position. This is due to cached `postAnimationValue` is applied mistakenly.
- Pass velocity instead of velocity sign to the helper class
- Update helper class logic to decide if we need to use post animated value from last fling animation
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32566010
fbshipit-source-id: 1c61659030151f8f2c7648ca901b8b4158835538
Summary:
This diff fixes an edge case where fling and snap failed to find the correct target position when children views not fill up all the scrollable space. In this case, the target position would be calculated as the end of the scrollable space, which case the snap logic to go to the end of the scrollable area, instead of stop at the expected snapping position.
Changelog:
[Android][Fixed] - Fix fling and snap with recycler viewgroup where fling to the end of scrollable distance when it goes over current rendered children views.
Reviewed By: mdvacca
Differential Revision: D32565459
fbshipit-source-id: 319ef6e2d4e1c4deb9e45ed02c1bff7d807575c3
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary:
Bump deprecated-react-native-prop-types dependency to ^2.3.0. This version contains a .windows.js fork of some deprecated props. Current version has missing information for Windows, breaking CI for react-native-windows repository.
## Changelog
[General] [Changed] - Upgrade deprecated-react-native-prop-types dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/32700
Reviewed By: lyahdav, rozele
Differential Revision: D32816801
Pulled By: yungsters
fbshipit-source-id: f6a8507637075b1a936d91c264bbd8a462505f48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32698
Changelog: [Internal] - Renaming the eslint-plugin-codegen to eslint-plugin-specs as a better descriptor for this package. Part of the plan is to publish as a public npm package
Reviewed By: RSNara
Differential Revision: D32777702
fbshipit-source-id: 7776c481871031dba1280d87fb76b777ecc23339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32693
Changelog: [Internal] this diff adds dependecies to the buck files so that an internal app that referes RNtester will work as intended.
Reviewed By: cortinico
Differential Revision: D32778338
fbshipit-source-id: d4703903c2227283fe9c70f02bb7da420d936fbb
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary: Changelog: [Internal] Adding an option in RN Tester to enable the new codegen discovery option where it uses generate-artifacts.js to codegen native files. It also updates generate-artifacts.js to support the case where react-native is not within node_modules. It also updates the option name for rn-demo-app.
Reviewed By: cortinico
Differential Revision: D32777912
fbshipit-source-id: f2b76fa61573e3d4507a9f16f8243ac7ca006900
Summary:
I've noticed that the `performance.now()` implementations differ on iOS and Android.
iOS:
```objc
PerformanceNow iosPerformanceNowBinder = []() {
// CACurrentMediaTime() returns the current absolute time, in seconds
return CACurrentMediaTime() * 1000;
};
```
Android:
```c++
double reactAndroidNativePerformanceNowHook() {
auto time = std::chrono::steady_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(
time.time_since_epoch())
.count();
constexpr double NANOSECONDS_IN_MILLISECOND = 1000000.0;
return duration / NANOSECONDS_IN_MILLISECOND;
}
```
For consistency, I thought why not just use the same implementation on both iOS and Android.
It also seems more logical to use Chrono on iOS, since it has nanosecond precision and we just multiply it to milliseconds, whereas `CACurrentMediaTime` multiplies to seconds, and we divide it down to milliseconds again.
## Changelog
(internal change only)
Pull Request resolved: https://github.com/facebook/react-native/pull/32695
Test Plan:
Run on iOS and Android:
```ts
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: feedthejim
Differential Revision: D32793838
Pulled By: ShikaSD
fbshipit-source-id: e7967780be95956a75a3a3757311af0077976d23
Summary:
Changelog: [Internal] Remove warning about creating a pull request to a release branch
We want to support this use case as we want pick requesters to land the cherry-picks themselves and rely on CircleCI automation to test
Reviewed By: cortinico
Differential Revision: D32780819
fbshipit-source-id: 882625a016653dbf480da33fd499d3718b2b5524
Summary:
changelog: [internal]
UIManager::animationTick is thread safe. Let's make it obvious by marking the method const.
Reviewed By: javache
Differential Revision: D32669102
fbshipit-source-id: 49e35d0f0a5c5d1b03baa1cbf9cdece082909e85
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here https://github.com/facebook/react-native/blob/b8f415eb6cdc0e0e7a7413b6f9defdcee304d9e8/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk#L20. There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
Changelog: [Internal] Revert --sourcemap-output argument
Reverting on main from discussion from the 67 release:
https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1705266
Original commit changeset: 0c2d98746b36
Reviewed By: GijsWeterings
Differential Revision: D32734743
fbshipit-source-id: cc3130581d01bdcdc9f5d483161ae9506fdbf7b8
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:
react-native-windows currently needs to maintain a fork of TextNativeComponent to wire through a native-only prop for `isPressable`.
The reason we do this on Windows is that we implement an optimization so we only attempt to hit test a virtual Text node if it is actually pressable, leading to significant perf improvement for pointer events (e.g., onMouseEnter / onMouseLeave) on Text.
Changelog:
[General][Added] - Native-only prop to optimize text hit testing on some RN platforms
Reviewed By: JoshuaGross
Differential Revision: D32564637
fbshipit-source-id: bf47c68d94a930d2c620cb3b1584355c5e412bd4
Summary:
Changelog: [Internal] Update CircleCI to auto-deploy release branch on push
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff updates the relevant CircleCI workflows
Reviewed By: sota000
Differential Revision: D32702420
fbshipit-source-id: e20cdeb53eb4a8ce7e54e083e3e14bd89e11b789
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] Copy over universal (across dry-run, nightly, release) work in `bump-oss-version` script
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `set-rn-version` script referenced by extracting it out of `bump-oss-version`
Reviewed By: sota000
Differential Revision: D32556608
fbshipit-source-id: 6c2868c01ddd930375279a5105bcd0d447f65734
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
The helper class for ScrollView should not need to detect the scroll direction. If it has to do so, that means the corresponding logic should live in the `ReactScrollView` or `ReactHorizontalScrollView` respectively.
This diff is to remove the scroll direction detection logic from the scroll view helper. Long term we should keep it this way as the shared code got moved to the helper class from the scroll view classes.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32514429
fbshipit-source-id: 2165f2eba90cc25d14834c39148fe8ce8805bea6
Summary:
This diff fixes two edge case (similar to a race condition) that caused unexpected behaviors.
**Problem one**
{F680816408}
The previous fling animation is not canceled when user starts to scroll or drag. This is causing both the animation and scroll are setting the scroll position. Depends on the animation path and scroll speed, there may be cases where the [velocity calculation](https://fburl.com/code/010lsu72) ends up getting reversed values. See P467905091 as an example where you can see `mXFlingVelocity` goes back and forth from positive to negative.
It's hard to see if the wrong values are in the middle, but if that happens in the end of user gesture, the velocity for the next fling would be wrong. It shows a "bounce back" effect, and can be triggered when user makes small quick joystick scrolls in one direction.
**Problem two**
{F680821494}
There is a gap between animator's `onAnimationEnd` lifecycle method [finished](https://fburl.com/code/6baq04ne) and the `Animator#isRunning` API to return false. This is causing issues for `getPostAnimationScrollX` where we [decide to return](https://fburl.com/code/hzzugvch) the animated final value or the scroll value. User may see the `-1` value got used for the next fling start value, and the whole scroll view goes back to the beginning of scroll view and starts to fling.
This happens when the previous fling animation finishes and the animated final value is set to -1, but at the same time the next fling starts before `isRunning` returns false for the previous animation.
**Solution**
The problems are fixed by
- Do not reset animated final value to -1 in `onAnimationEnd` method
- Add `mIsFinished` states and use it to track animation finish signal, instead of using `isRunning` API
- Update logic where we decide to return the correct value for the next animation starts point. We will return previous animated final value when the animation got canceled, and user is going towards that value from the current scroll value.
Changelog:
[Android][Fixed] - Fixed edge case for quick small scrolls causing unexpected scrolling behaviors.
Reviewed By: javache
Differential Revision: D32487846
fbshipit-source-id: f1b0647656e021390e3a05de5846251a4a2647ff
Summary:
If `value` is of type `float`, it will still fall through to the `react_native_assert` below, exploding. The `map` type is handled correctly.
Changelog: [Internal][Fixed] Fix fromRawValue(EdgeInsets) from single float case falling through to float array and exploding
Reviewed By: javache
Differential Revision: D32648848
fbshipit-source-id: e70cddd291a8f52d6ee3de5fef11b0bb7aee92cd
Summary:
The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`.
I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`.
See also: this discussion post by mikehardy https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523
## 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] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Pull Request resolved: https://github.com/facebook/react-native/pull/32633
Test Plan:
### Test (failing before this patch, passing after this patch)
1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package
2. `npx react-native init myrnapp`
3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`))
4. Compile the app.
Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds
Reviewed By: fkgozali
Differential Revision: D32638171
Pulled By: philIip
fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
Summary:
The `add-version-label-issue` CI is failing if the version label is not found.
That is happening for previous versions of RN where the Labels are missing.
Changelog:
[Internal] [Changed] - Do not report a CI failure if add-version-label-issue is red
Reviewed By: sammy-SC
Differential Revision: D32723953
fbshipit-source-id: 878d2632b3a78311a01363b8f8a9181ae543a253
Summary:
As the title says. It's now safe to enable Fabric by default inside RNTester.
Changelog:
[Internal] [Changed] - Enable Fabric by default inside RN-Tester
Reviewed By: fkgozali
Differential Revision: D32723540
fbshipit-source-id: dab786694ba9ceb238570608713b5243a730aada
Summary:
Preallocation can take 10-20% of time when creating new nodes. (according to systrace measurements). At the moment, we are executing all preallocation calls in JS thread, potentially slowing down the progress there. Moving them to bg thread is a simple micro-optimization that ensures we return the node to JS as soon as possible.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32677843
fbshipit-source-id: 3df47ae9aa365a8db720d71e2423c87659e9128c
Summary:
Removes extra .so files by merging built-in components into libfabricjni.so
These components shouldn't be referenced in outside modules, so merging them is trivial atm.
Changelog:
[Internal][Android] - Compile native components into static libraries
Reviewed By: cortinico
Differential Revision: D32677572
fbshipit-source-id: fc1a6c5a2832ee49e438c30856562f85677514ea
Summary:
Noticed we explicitly dropped the `allow_jni_merging` while not actually using it anywhere, and that we didn't have `fbandroid_allow_jni_merging` on some other libs.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D32355868
fbshipit-source-id: 6bd3fcc395e3dcacf4a8fc1033d471b2ffb0e8af
Summary:
Changelog: [internal]
Nothing was using `stop` parameter, let's get rid of it.
Reviewed By: philIip
Differential Revision: D32669018
fbshipit-source-id: dc2d52048a2f7dd3785dd959270087001c778962
Summary:
This task is supposed to really clean all the files that are generated
as part of a build and bring you to a clean state.
Changelog:
[Internal] [Changed] - Create a `cleanAll` Top Level Gradle task.
Reviewed By: ShikaSD
Differential Revision: D32649942
fbshipit-source-id: 20b72ad4e1c0ef046aaaba94e2331176dca49abf
Summary:
This diff makes the fling animator cuztomizable, so that the subclasses can have their own animation for fling behavior.
Before the diff, we rely on the `OverScroller` to `fling`, which has some issues with Spline interpolation being messed up due to the clamped fling distance (See more details in T105464095). This may not be a big issue for mobile when user touches screen, but in VR environment this shows up very clearly with joystick events. To fix that properly without affecting mobile behavior, I added a new interface `HasFlingAnimator` from the helper, and implemented with default fling animator in the OSS ScrollView.
We should consider adopt a suitable animator for mobile platform, as the non-smooth fling effect is also happening in mobile.
- Add interface `HasFlingAnimator` to `ReactScrollView` and `ReactHorizontalScrollView`
- Add default fling animator
- Depend on if the default animator is used, customize the flingAndSnap behavior
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D32382806
fbshipit-source-id: 08f03350f6a9b9fc03414b4dcb9977b9f33603ba
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
Seems like the Gradle plugin was left behind when bumping AGP.
This bump is quite significant as AGP removed several dependencies from their
exported one so I had to reimport them again (ideally we should move to kotlinx-serialization).
I've also addressed a couple of Kotlin compiler warnings that were not related to
the AGP Api (those will be addressed at a later time).
Plus I've also fixed the target Java version to 11 as the compiler was complaining
that Java target was at 11 while Kotlin Jvm target was defaulted at 8
Changelog:
[Internal] [Changed] - Bump AGP to 7.x inside the react-native-gradle-plugin
Reviewed By: ShikaSD
Differential Revision: D32667745
fbshipit-source-id: 044930bf6cc49065eff4af1c9be79de76d5b368b
Summary:
Custom metro port not working without exporting variables from `.packager.env`
## Changelog
[General] [Fixed] - Fix support for custom port
Pull Request resolved: https://github.com/facebook/react-native/pull/32666
Test Plan: run `react-native run-android --port=8082` and `react-native run-ios --port=8082`
Reviewed By: yungsters
Differential Revision: D32694233
Pulled By: cortinico
fbshipit-source-id: 42e803d56b83608024b901d2a3024733ed7099b7
Summary:
This Diff fixes a crash happening as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The crash happens as `mFabricViewStateManager` is accessed during
the ctor of the superclass, and is not yet initialized.
Fixes#31572
Changelog:
[Android] [Fixed] - Fix crash on ReactEditText with AppCompat 1.4.0
Reviewed By: ShikaSD
Differential Revision: D32674975
fbshipit-source-id: efa413f5e33527a29fbcfa729e8b006ecb235978
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:
a year ago or so, there was a change that updated the way RCTBundleURLProvider creates the IP url depending on if HERMES_BYTECODE_VERSION existed, and this test was never updated, so fixing it accordingly
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32638669
fbshipit-source-id: 3824b90570f60ad5299939b09b99fb56d2b3ddaa
Summary:
we couldn't run the RNTesterUnitTests before because these tests didn't respect the nullability specification. after this diff, we can run the tests.
as for the tests.... well 2 are still failing, i'm taking a look at them.
Changelog:
[iOS][Fixed] - fixed RCTImageLoaderTests
Reviewed By: sammy-SC
Differential Revision: D32635689
fbshipit-source-id: d68ae6a3e7f1370d7d76d68c7a6d9812928e6c12
Summary:
The Codegen is generating a broken output if using the default library name: `Packages<GradleModuleName>Spec`.
This diff is fixing the codegenerator to don't call the `.lowerCase` on the library name when generating the Makefile.
Changelog:
[Android] [Fixed] - Do not .lowerCase the library name when codegenerating TurboModule Specs
Reviewed By: ShikaSD
Differential Revision: D32597578
fbshipit-source-id: dee729a44134d7b3878074507191bb2a1c200608
Summary:
AGP 7.x is changing the path where we can find
the precompiled static libraries. Therefore is getting complicated
to share prebuilt `.a` files. I'm updating `libruntimeexecutor` to be
a shared library instead so this will solve this issue for now.
Changelog:
[Internal] [Changed] - Update libruntimeexector to be a shared lib rather than a static lib
Reviewed By: ShikaSD
Differential Revision: D32646112
fbshipit-source-id: ce42e930076c1d3b5f54f3d8adcca1c38909d0fb
Summary:
Bump Android Gradle Plugin to 7.
## Changelog
[Android] [Changed] - Bump Android Gradle Plugin to 7.
This will make Java 11 a requirement for users that are either:
* Cloning react-native to contribute
* Using react-native while building from source.
* Creating new project from the template.
Pull Request resolved: https://github.com/facebook/react-native/pull/32589
Test Plan: CI is green
Reviewed By: ShikaSD
Differential Revision: D32427945
Pulled By: cortinico
fbshipit-source-id: c1ea464d87c3e397616c55154b3d8b1c3ea6c592
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:
similar to android, we want to handle removing dropped surfaces. in this diff, we add the API to do so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32557069
fbshipit-source-id: 2487c459df3f1f412ad0da77568d6c0ab0a1298c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32642
This Diff adapts the Dangerfile to be a bit more friendly
for PRs that are exported from Phabricator. Specifically,
I'm disabling the check for Test Plan as those are not exported
externally. The check for Summary and Changelog are instead adapted
to work with the format exported for Phabricator.
Changelog:
[Internal] [Changed] - Make Danger Phabricator-friendly
Reviewed By: yungsters
Differential Revision: D32594622
fbshipit-source-id: e31f29defdd926a267cecc9efa6d63de2e580f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32640
This Diff shows how an application can provide a custom Fabric Components Registry.
The idea is to extend the CoreComponentsRegistry from rncore to provide the extra
components that are generated from RNTester.
Please note that this Diff can't be shipped as it is and should be rebased on top of:
- D32493605 (https://github.com/facebook/react-native/commit/aa4da248c12e3ba41ecc9f1c547b21c208d9a15f) As the CLANGFORMAT is disabled for RNTester at the moment
- D32045059 (https://github.com/facebook/react-native/commit/d29f3d2a6b84c17ad057f4e9c8dc35b3fe16fb19) and D32128979 as they're effectively adding the sample component and the iOS code.
Changelog:
[Internal][Added] - Adding a Custom Fabric Component to RNTester
Reviewed By: ShikaSD
Differential Revision: D32498360
fbshipit-source-id: 1a737359498dddb571c8a445bec18e5dbcf53e04
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
This diff prevents view flattening for views that are handling some events in the JS side
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253124
fbshipit-source-id: acda2b12287f0a9c39a810b23a101765093ba217
Summary:
This diff updates the internals of Fabric to add support for onEnter/onExit/onMove events.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253128
fbshipit-source-id: 5b30e927bda0328ba1332801f66a6caba77f949b
Summary:
This diff updates the BaseViewManager in order to store metadata in views that are handling JS events.
This information will be used later in the stack to optimize dispatching of hover events and fix viewFlattening bugs
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D32253127
fbshipit-source-id: b6b74f0b1a5b8cc652b3ac3fff42165ee4ce85e1
Summary:
This diff updates the ViewConfigs in RN Android to add support for onEnter/onExit/onMove events.
Open questions:
- Should we just remove the override for RN VR: https://www.internalfb.com/code/ovrsource/[c82b81893393ad0c6f8c6e7f347e82bba39dc8cc]/arvr/js/libraries/reactvr/VrShellPanelLib/rn-support/setUpViewConfigOverrides.js
- Should we use w3c naming now (e.g. onPointerEnter / onPointerExit / onPointerMove) ? or should we migrate to it later? what would be the effort for VR to migrate now to onPointerEnter / onPointerExit / onPointerMove?
changelog: [Android][Changed] Add ViewConfigs to support onEnter/onExit/onMove events
Reviewed By: RSNara
Differential Revision: D32253129
fbshipit-source-id: 539d8672825c7f18f0b6a2570764a5988cd936bc
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:
fixing oncall issue: https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
in this diff, we add the properties to the native views that are needed for the `onScroll` event.
`UITextField` is not a `UIScrollView` unlike `UITextView`, so we need to add these dummy properties
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32523147
fbshipit-source-id: 1d4f227f498fa1c333e2d6c457484b559ca18f7e
Summary:
Changelog: [Internal]
# Context
Whilst looking at Marketplace Loom traces, ShikaSD made the remark that we could potentially start the JS work much earlier instead of waiting for the View.onMeasure call, a behaviour that is already built-in Venice.
Reviewed By: ShikaSD
Differential Revision: D32559505
fbshipit-source-id: cc6337955ad2b6a6581a0347f1f976679eaca54d
Summary:
This is expected with Suspense/CM enabled. We are measuring the perf impact of extra CREATE instructions atm, and will revert the change if it regresses too much.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D32558829
fbshipit-source-id: 2e0c91be3aba4ca632814739aed6b8964e21b5a8
Summary:
This PR add [volta](https://volta.sh/) support to find-node.sh for use by `scripts/react-native-xcode.sh`, `scripts/generate-specs.sh`, etc.
## Changelog
[iOS] [Added] - add volta support to find-node.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32611
Test Plan:
Manually tested with volta installed node (and [relevant change](https://docs.volta.sh/guide/understanding#managing-your-project) added to the project's package.json). Without this patch, the `Bundle React Native code and images` Build Phase fails, with it, it succeeds.
Tested with both `curl https://get.volta.sh | bash` installed and `brew install volta`. One check works for both because the `node` shim will always be installed to the same location (and the required environment variable exports are the same also)
Wasn't sure if you'd want the package.json change applied to rn-tester? Shouldn't affect people who don't use volta. Shout if you want me to add it to this PR.
Reviewed By: cortinico
Differential Revision: D32498267
Pulled By: yungsters
fbshipit-source-id: 93ee187bd2178bfcd8f9009a1a0668c6f5583aa3
Summary:
This diff refactors the scroll animation from `ReactScrollView` and `ReactHorizontalScrollView` into the `ReactScrollViewHelper` to reduce repeated code. The `Animator` is now shared between all the scroll views in the app, which I believe is the right behavior.
It also helps to make the animator changes in future diffs apply to both horizontal and vertical scroll view.
- Move `reactSmoothScrollTo` to `smoothScrollTo` in the helper class
- This means one Animator for all ScrollViews
- Move `updateStateOnScroll` to the helper class
- Add interface for accessing instance scroll state properties in ScrollView
- This means each ScrollView keeps their own scrolling state
- Use `Point` class for pairs of x and y values
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32372180
fbshipit-source-id: 529180eea788863689c3b440191ed50c5a6f04e5
Summary:
This diff supports monorepo/custom configuration where node_modules may not be located under app_root.
The default (RN_root, '..') should support most cases, but I also added an option to provide a custom location for users to set.
Changelog: [internal]
Reviewed By: ShikaSD
Differential Revision: D32469957
fbshipit-source-id: 6b8a6c775c21bde72ef542e34973701d698f678f
Summary:
resolving issue in https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
we didn't hook up the onScroll event to the fabric text input component yet, so this stack does that
in this diff, we add the onScroll event to the event emitter
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D32479450
fbshipit-source-id: 3ac0e6f87a4bf391e3ceee24b5765e3e41ecc59d
Summary:
As we're working on C++ code for RNTester to integrate Fabric, we should enable CLANGFORMAT for the files over there.
Changelog:
[Internal] [Changed] - Enable CLANGFORMAT on fbsource/xplat/js/react-native-github/packages
Reviewed By: ShikaSD
Differential Revision: D32493605
fbshipit-source-id: 7b5d63f6d2fae1a1aa1e782738953c8cd2cdbe4b
Summary:
This diff adds a very simple example to show the use of new architecture in a component.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32045059
fbshipit-source-id: f388bfb765241122de425fbef61cea0620cd31ac
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 diff adds a support to generate ThirdPartyFabricComponentProvider when codegen discovery isn't enabled. This functionality will be removed when we start using the new way of generating code as a default.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D32420306
fbshipit-source-id: 219bcdf6cb186196ca62e651086dedab485b063e
Summary:
This messes with python version selection. At least based on
the comments, it is no longer needed, as /opt/local/bin appears to be
empty on my devserver and on a sandcastle host.
D32337004 revealed the problem. T105920600 has some more context. I couldn't repro locally, so D32451858 is a control (which I expect to fail tests) to confirm that this fixes the test failures.
#utd-hermes
Reviewed By: neildhar
Differential Revision: D32451851
fbshipit-source-id: 4c9c04571154d9ce4e5a3059d98e043865b76f78
Summary:
Ensures (under a flag) that CREATE instructions will be issued even if the node was supposed to be preallocated before from create or clone. This addresses cases when differ considers nodes to be deleted->created, but we skip the "create" part because of revision check.
Changelog:
[Internal] Disable node revision checks during mount under a flag
Reviewed By: sammy-SC
Differential Revision: D32440831
fbshipit-source-id: 4da8c4961fd7bc43c8f4166798bdfb5d897184e0
Summary:
Changelog:
[Internal][Fixed] - I have been reading this header file recently and discovered some typos
Reviewed By: kodafb
Differential Revision: D32455214
fbshipit-source-id: c27291943476014b787ee1641fd8642056bdbc5a
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:
Bump Gradle to 7.3, also configure gradle cache key to include gradle version so that we don't keep cache for other versions and have smaller cache, faster CI.
## Changelog
[Android] [Changed] - Bump Gradle to 7.3
Pull Request resolved: https://github.com/facebook/react-native/pull/32588
Test Plan: CI is green
Reviewed By: ShikaSD
Differential Revision: D32427806
Pulled By: cortinico
fbshipit-source-id: 776406ef3aa7962cf3a4abc178e3c8a4762a01e0
Summary:
motivation: I have a custom setup and needed to provide `react.cliPath`. I mistakenly provided path to `react-native-community/cli` which resulted into JS bundle not being generated. This error message provides a little more detail.
## 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] [Changed] - Improved error message in react.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/32593
Test Plan: I guess it's not needed in this case
Reviewed By: ShikaSD
Differential Revision: D32427929
Pulled By: cortinico
fbshipit-source-id: 2be340a8be15c8ec08873c0368a36b449c8b5030
Summary:
Bump react-native-android docker image to 5.0, which includes JDK 11.
## Changelog
[Internal] [Changed] - bump react-native-android docker image to 5.0, which includes JDK 11.
Pull Request resolved: https://github.com/facebook/react-native/pull/32186
Test Plan: Android CI must be green
Reviewed By: ShikaSD
Differential Revision: D30897954
Pulled By: cortinico
fbshipit-source-id: 9b6696bac424ab188a0443b8315edbb9596dd166
Summary:
There will still be a case where this script is used when fabric is disabled. This diff adds the flag so that whether to generate fabric components can be controlled by the user.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32380881
fbshipit-source-id: 786931848b1eca5015c8f58f4361b395c8d341cc
Summary:
This moves the output location for turbo modules from build/generated/ios/react/renderer/components/ to build/generated/ios/ so that the third party modules can use Spec/Spec.h to import. In the future we might use the same folder structure for both components and modules.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32340162
fbshipit-source-id: 6ad7c8ae92e072cd26e44b47914afa33618acbcb
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:
Fixed a bug in `react_native_assert` that was not effectively letting the app
call `abort()`. The app was actually printing on log twice.
Ref: https://developer.android.com/ndk/reference/group/logging#__android_log_assert
Changelog:
[Android] [Changed] - Let react_native_assert really abort the app
Reviewed By: JoshuaGross
Differential Revision: D32204080
fbshipit-source-id: ca16c50aaf4e41a2318277c233be0e944b2ad8f1
Summary:
I'm adding a `EmptyReactNativeConfig` for Java as we had a similar class in C++.
Ideally inside the Playbook we can allow users to use this class rather than having to
create an anonymous inner class.
Changelog:
[Internal] [Added] - Introduce EmptyReactNativeConfig inside Java
Reviewed By: ShikaSD
Differential Revision: D32277916
fbshipit-source-id: f6bbeb0477681d536dfd89930b732609add7c43a
Summary:
Changelog:
[General][Fixed] - Modal accepts a testID but didn't forward it to RCTModalHostView, therefore not making it show up for e2e tests depending on viewhierarchy.
Reviewed By: motiz88
Differential Revision: D32354377
fbshipit-source-id: 51df3a1f81c4b77240e83101b367b033ce98b0c7
Summary:
Summary
bugfix for multiple shadow threads rendered at the same time, small probability crash.
Changelog
Android
Fixed
ViewManagersPropertyCache.class
Background:
4 tab(RN Page) has 4 ReactInstanceManager.
4 ReactInstanceManager has 4 shadow threads and 4 JS threads.
4 RN Page if rendered at the same time. small probability crash
the key crash log(full log at the end):
java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
need Dynamic and got String.
Reasons of crash: PropSetter class field : VIEW_MGR_ARGS, VIEW_MGR_GROUP_ARGS, SHADOW_ARGS, SHADOW_GROUP_ARGS is static.
one shadow thread put data in static array, it was changed by another shadow thread before method invoke.
No.1 shadow thread put "Dynamic" in static array.
No.2 shadow thread put "String" in the same static array(replace the "Dynamic").
No.1 shadow thread invoke method with the static array as params. the crash..
The solution:
use ThreadLocal instead of static array.
Pull Request resolved: https://github.com/facebook/react-native/pull/32167
Test Plan:
I make 4 tab page rendered at the same time and test 100 times. it is not crash again.
about 15% chance of crash before fixed.
Crash stack:
2021-09-08 11:56:07.392 16776-17062/com.shopeepay.merchant.id.debug E/unknown:ViewManager: Error while updating prop width
java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:111)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.488 16776-17062/com.shopeepay.merchant.id.debug E/unknown:ReactNative: CatalystInstanceImpl caught native exception
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'width' in shadow node of type: RCTView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:125)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
Caused by: java.lang.IllegalArgumentException: method com.facebook.react.uimanager.LayoutShadowNode.setWidth argument 1 has type com.facebook.react.bridge.Dynamic, got java.lang.String
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:111)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.488 16776-17062/com.shopeepay.merchant.id.debug E/com.shopeepay.merchant.id.debug: com.shopee.app.react.util.ReactJSException: Error while updating property 'width' in shadow node of type: RCTView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:125)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackShadowNodeSetter.setProperty(ViewManagerPropertyUpdater.java:161)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:65)
at com.facebook.react.uimanager.ReactShadowNodeImpl.updateProperties(ReactShadowNodeImpl.java:320)
at com.facebook.react.uimanager.UIImplementation.createView(UIImplementation.java:251)
at com.facebook.react.uimanager.UIManagerModule.createView(UIManagerModule.java:469)
at java.lang.reflect.Method.invoke(Native Method)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:236)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:923)
2021-09-08 11:56:07.571 16776-16776/com.shopeepay.merchant.id.debug E/com.shopeepay.merchant.id.debug: com.shopee.app.react.util.ReactJSException: Trying to add unknown view tag: 1519
at com.facebook.react.uimanager.NativeViewHierarchyManager.manageChildren(NativeViewHierarchyManager.java:487)
at com.facebook.react.uimanager.UIViewOperationQueue$ManageChildrenOperation.execute(UIViewOperationQueue.java:209)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:917)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1028)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:48)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1088)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.615 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.626 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.674 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.677 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.686 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:07.698 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:08.406 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:08.423 16776-16776/com.shopeepay.merchant.id.debug E/unknown:ReactContextBaseJavaModule: Unhandled SoftException
java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by Timing
at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:67)
at com.facebook.react.modules.core.TimingModule.access$000(TimingModule.java:22)
at com.facebook.react.modules.core.TimingModule$BridgeTimerManager.callTimers(TimingModule.java:28)
at com.facebook.react.modules.core.JavaTimerManager$TimerFrameCallback.doFrame(JavaTimerManager.java:84)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1056)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:809)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
2021-09-08 11:56:09.594 16776-16776/com.shopeepay.merchant.id.debug E/unknown:DeviceInfo: Unhandled SoftException
com.facebook.react.bridge.ReactNoCrashSoftException: No active CatalystInstance, cannot emitUpdateDimensionsEvent
at com.facebook.react.modules.deviceinfo.DeviceInfoModule.emitUpdateDimensionsEvent(DeviceInfoModule.java:99)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.emitUpdateDimensionsEvent(ReactRootView.java:755)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForDeviceDimensionsChanges(ReactRootView.java:713)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:664)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8383)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1058)
at android.view.Choreographer.doCallbacks(Choreographer.java:880)
at android.view.Choreographer.doFrame(Choreographer.java:813)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1043)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:7876)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
Reviewed By: cortinico
Differential Revision: D31904828
Pulled By: ShikaSD
fbshipit-source-id: 1337a1e9f0320417b441efe84e9066f15ffcd12e
Summary:
Changelog: [Internal]
* Sets a default custom reporter in `scripts/packager.sh` that redirects Metro's logs to a JSON file when the `RCT_PACKAGER_LOG_PATH` environment variable is set. Otherwise we use Metro's `TerminalReporter`, [like the CLI does by default](https://github.com/react-native-community/cli/blob/0993f627869f4de0e5a8a9a950d38a9f15e18fb2/packages/cli-plugin-metro/src/commands/start/runServer.ts#L124).
* Modifies `scripts/launchPackager.command` to write logs to `$RCT_PACKAGER_LOGS_DIR` (and in particular use the JSON reporter) if this environment var is set.
* Uses [`open -n`](https://ss64.com/osx/open.html#:~:text=Open%20a%20new%20instance%20of%20the%20application) to execute `launchPackager.command` from Xcode, so that environment variables are reliably passed to the script even if a Terminal process is already running.
Reviewed By: yungsters
Differential Revision: D32295290
fbshipit-source-id: 4d783e1f94d122d3a35c104b2b02dbfaf8e1a1a3
Summary:
Adds a phase to generate-artifacts.js to generate the third party components provider for fabric. The output path needs to align with where the rest of generated files go (the work is wip).
Changelog:[internal]
Reviewed By: hramos
Differential Revision: D32128834
fbshipit-source-id: 8721b8a19bcf01bb388a293ce17162b4e578a72a
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
This diff makes the manual changes necessary to fix many of the errors in the stacked diff codemod.
See https://fb.workplace.com/groups/flowlang/posts/917522612186736 for details on this effort.
Reviewed By: bradzacher
Differential Revision: D31615035
fbshipit-source-id: 179b2df516833d59873b9003350f81eb4a6b4e9d
Summary:
When transpiling flow with a Babel config like
```
{
plugins: [['babel/plugin-transform-flow-strip-types', {requireDirective: true}]]
}
```
all files containing Flow syntax need to have `flow` at the top of the file.
```
node_modules/react-native/Libraries/Blob/URL.js: A flow directive is required when using Flow annotations with the `requireDirective` option.
55 | _searchParams = [];
56 |
> 57 | constructor(params: any) {
| ^^^^^
58 | if (typeof params === 'object') {
59 | Object.keys(params).forEach(key => this.append(key, params[key]));
60 | }
```
In URL, it was removed (mistakenly I think) by https://github.com/facebook/react-native/commit/63038500a23d2dc10798cc116bb70c03064db8bc#diff-552f9731d5c9bc329105a5f4224319966395e59b5bb23202b756c5d152e0f007. Only the `strict-local´ part should have been removed, not the whole line.
## 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] - Complete missing Flow declarations in URL
Pull Request resolved: https://github.com/facebook/react-native/pull/32566
Test Plan: See above
Reviewed By: yungsters
Differential Revision: D32295816
Pulled By: lunaleaps
fbshipit-source-id: 1ad19a032e3399434f4e6a8eebbf37071a0f97be
Summary:
lunaleaps did [0.66.3](https://github.com/facebook/react-native/releases/tag/v0.66.3) yesterday - this PR adds the entries for it in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entry for 0.66.3
Pull Request resolved: https://github.com/facebook/react-native/pull/32576
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D32321194
Pulled By: yungsters
fbshipit-source-id: dadffb21fd9ece245acf761947e8fef544a00b7d
Summary:
Currently, we don't have a way to extend RCTFabricComponentsPlugins in OSS. This diff adds a codegen to generate ThirdpartyFabricComponentsProviderwhich will be used to extend RCTFabricComponentsPlugins.
It works almost exactly the same as RCTFabricComponentsPlugins, and in the future we might want to consider merging them together.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128760
fbshipit-source-id: b4f3a082f94c3053251cc6a0323c488f649deaa9
Summary:
Eliminates all of the console logs that appear when successfully running Jest tests for React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D32304619
fbshipit-source-id: 8bc8ef9337ae6af588238cec7cfb874ac6067340
Summary:
Update the version of flow-parser used by JSCodeshift to the latest, so it can handle new syntax like indexed access types.
Fix up some jscodeshift scripts that had failing tests due to updated parser.
Reviewed By: yungsters
Differential Revision: D32226600
fbshipit-source-id: cdd045bad523df9bf14af35ddab9516fc75ce900
Summary:
When I upgraded React Native to Prettier v2.x, I removed `format` from a few files to reduce the number of changes.
This is a follow-up to bring back `format` and fix any remaining issues.
Changelog:
[Internal]
Reviewed By: zertosh
Differential Revision: D32287259
fbshipit-source-id: 37ea6d2c973b1db5d37c46d73675bdf436fb9a9d
Summary:
Upgrades ESLint to v7.28.0. This is the latest version before v8.0.0, which would be a more involved upgrade.
Upgrades all ESLint-related dependencies to their latest version, except for [eslint-plugin-flowtype](https://github.com/gajus/eslint-plugin-flowtype/). This is because eslint-plugin-flowtype@8.0.0 dropped support for ESLint v7.
Configures ESLint for Metro to extend `plugin:prettier/recommended`.
## Changelog
[General][Changed] - Upgraded packages to the latest versions for ESLint v7.
Pull Request resolved: https://github.com/facebook/react-native/pull/32560
Test Plan:
Run this on an open source checkout of `facebook/react-native`:
```
# See no new errors or warnings.
$ yarn run lint
```
Run this internally:
```
$ js1 test xplat/js/tools/__tests__/dependency-constraints-test.js
```
Verify linting works:
```
js1 lint xplat/js/RKJSModules/Libraries/Core/
```
Reviewed By: lunaleaps
Differential Revision: D32258399
Pulled By: yungsters
fbshipit-source-id: d11b3fc3e33770157a90f3dee352cf80b39c442c
Summary:
Renames `Keyboard.removeEventListener` to `Keyboard.removeListener`.
When I implemented the compatibility layer in {D26589441 (https://github.com/facebook/react-native/commit/035718ba97bb44c68f2a4ccdd95e537e3d28690c)}, I accidentally used the wrong name. Since `Keyboard.removeEventListener` was always deprecated, this removes it completely.
Changelog:
[General][Changed] - Rename deprecated `Keyboard.removeEventListener` to `Keyboard.removeListener`.
Reviewed By: lunaleaps
Differential Revision: D32282743
fbshipit-source-id: 309382af3269f85f781d38367d115a2ce3690efb
Summary:
Changelog:
[Android][Added] Adding new API `onChildEndedNativeGesture` to the RootView interface to let its implementations notify the JS side that a child gesture is ended.
Reviewed By: javache
Differential Revision: D32228745
fbshipit-source-id: ad1f26546dd60f9c5a569b0bc3ad5020a01b90cc
Summary:
The conversion between std::string and Java strings is failing when initializing the `SurfaceHandler`. Instead of manually converting strings, this change makes native init use built-in fbjni helper instead.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32281900
fbshipit-source-id: 056fce56b40c036d454925c8734bbf2a16f327ff
Summary:
The `Event.getSurfaceIdForView` method I added recently is actually a duplicate of `UIManagerHelper.getSurfaceId`, except that the latter doesn't support RootViews very well.
Changelog:
[Android][Changed] - Improved UIManagerHelper.getSurfaceId and removed Event.getSurfaceIdForView
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D32102175
fbshipit-source-id: 01741df6b646037a4575e9ca302ea248af9fd6f3
Summary:
Instead of using `.prettierrc` to ignore the files sync'd from React, replace `format` with `noformat`.
This is necessary because currently, the version of Prettier used in React Native (v2.4.1) differs from the version used in React (v1.19.1). We can revert this when React is upgraded.
Changelog:
[Internal]
Reviewed By: ShikaSD
Differential Revision: D32129937
fbshipit-source-id: ca3b379edd732670a9a0b1b20b3f31bdad4b74aa
Summary:
Ignores the `Libraries/Renderer/` directory of files which are synchronized from React (and should not be modified).
Also, formats some EventEmitter modules that for some reason were missed when I upgraded to Prettier v2.x.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/32524
Test Plan:
```
yarn run format-check
```
Reviewed By: javache
Differential Revision: D32129837
Pulled By: yungsters
fbshipit-source-id: 1cb42cec210508db499850e13f77beefdb35eb25
Summary:
## Changes
- StaticViewConfigValidator.validate() now outputs a ValidationOutput object, that contains a Array<Differences>, if invalid
- The Difference type now contains the nativeValue and the staticValue. This makes the validate() function more useful in reconciling ViewConfigs.
- Nothing should change in NativeComponentRegistry.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32139973
fbshipit-source-id: a9556fa370d2c14f9e5d0540b44824cd61773958
Summary:
NOTE: Second attempt at merging https://github.com/facebook/react-native/pull/32486 (D32080994 (https://github.com/facebook/react-native/commit/25d4cb98b07434a98cbc415cdf248bd8e20ab8b8)).
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan: See `react-native-oss-ios` Sandcastle job succeed.
Reviewed By: fkgozali
Differential Revision: D32256761
Pulled By: yungsters
fbshipit-source-id: c7f32b72287018f070910b26aad02aa0adf4a61f
Summary:
This is a nit, but the capitalization of `ComponentFactory` is wrong
and should be lowercase. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix capitalization of ComponentFactory in RNTester
Reviewed By: ShikaSD
Differential Revision: D32247341
fbshipit-source-id: e8a9f264139f20d85a8e00fad947b2c9465ef630
Summary:
I've unified the function that is responsible of getting the `reactNativeArchitectures` property
to a single one (ideally we could move it inside the Gradle Plugin in the future).
I've also added a property in the `gradle.properties` file. This makes easier for users to customize the
architecture to build without having to specify a CLI flag or edit multiple gradle files.
Changelog:
[Android] [Added] - Make the `reactNativeArchitectures` property more discoverable
Reviewed By: ShikaSD
Differential Revision: D32244997
fbshipit-source-id: 33180544400f9abe63e9b539ff16fefa17a024ba
Summary:
Currently the release build of RNTester is broken
as it's loading the debug native libraries. I had to create
separate tasks for the two variants as we can't benefit
of automatic variant matching between project (as of now till
we use prefabs or find another approach).
Changelog:
[Internal] [Fixed] - Fix Release build of RNTester
Reviewed By: ShikaSD
Differential Revision: D32203637
fbshipit-source-id: 5c260a365626e9b3c66e76166086711236a38264
Summary:
Changelog: [Internal] - Don't fail build_npm_package when there is no PR environment set to post the link to.
The script will fail with an error thanks to changes: https://github.com/facebook/react-native/commit/86491749ee67562e424209f644f7273061633687
Reviewed By: fkgozali
Differential Revision: D32221758
fbshipit-source-id: ceb7fb654e4c13e195f20e28798e66e6854bcbcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32543
Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version
Context:
* There are two types of tags, git and npm, they are unrelated.
* When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version.
* When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version.
* npm and git's `latest` tag should always point to our most recent stable version
This change:
* Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest"
* If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag
* Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`.
* This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version.
Reviewed By: hramos
Differential Revision: D32196239
fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function
Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds
Reviewed By: hramos
Differential Revision: D32196237
fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544
Summary:
lunaleaps did a few patch releases over the last few days. This PR adds the entries for them in the changelog.md file.
## Changelog
[Internal] [Changed] - add changelog entries for 0.64.3, 0.65.2 and 0.66.2
Pull Request resolved: https://github.com/facebook/react-native/pull/32549
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D32205887
Pulled By: cortinico
fbshipit-source-id: c4b173730c6bdf1349c29df26d136aa9f6d4568d
Summary:
For native animations,
* Add NS_ASSUME_NONNULL_BEGIN / END to RCTNativeAnimatedNodesManager since most of its params are nonnull.
* Explicitly mark nullable params.
Reviewed By: philIip
Differential Revision: D32209819
fbshipit-source-id: c881294d8ba8c2cdcaa931801c977cd5bbe764f4
Summary:
Make viewName in native animations nullable, because viewName is not used when the RCTAnimationNode is managed by Fabric.
Changelog: [Internal] Minor: Make viewName nullable in native animated modules for Fabric
Reviewed By: philIip
Differential Revision: D32196270
fbshipit-source-id: 76d05dc7fd2850efb097f953ccd22fd3f6d80599
Summary:
Use generate-artifacts.js script when USE_CODEGEN_DISCOVERY envvar is set to 1 at `pod install` time. Setting this envvar will disable the old codegen script.
Added `[Codegen]` prefix to all codegen log output.
Note: This script is not ready for production use at the moment.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31693778
fbshipit-source-id: 25da95bdb33315ac42c6dfb40334e22ec9823cb1
Summary:
When switching between split screen or resizing the screen window on Android causes a restart by reconstructing the app components as described on this issue https://github.com/facebook/react-native/issues/25040
## 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] - Don't reconstruct app components https://github.com/facebook/react-native/issues/25040
Pull Request resolved: https://github.com/facebook/react-native/pull/32536
Test Plan:
### How to reproduce
- create a new project
- build app and install on Android
- minimize app and start split screen
Expected:
- App enters split screen
Result:
- App restart
Same issue can be seen when resizing the split screen window
Reviewed By: cortinico
Differential Revision: D32175433
Pulled By: yungsters
fbshipit-source-id: 93dccaa134074eea260cca61eba2150444fa5688
Summary:
C++-only TurboModules, not to be confused with [TurboModules](https://www.internalfb.com/intern/wiki/React_Native/Building_Product_Experiences/Intro_to_Native_Modules/), directly allows you to call C++ from JS instead of going through the native layer. Referred to modification of C++-only TurboModule D30158226 and https://fburl.com/code/rcf73a42 for C++ to JS call (jsInvoker is an object that can schedule work on the JavaScript thread)
This example shows JS to C++ call and storing a JS function in C++ to call later.
Notes:
* To use the module, import the C++ module directly in objc.
* Meanwhile, create a js spec and use it in RN code. Spec methods don't need to be marked as optional.
* C++ and js spec will be linked when built
Reviewed By: RSNara
Differential Revision: D32080496
fbshipit-source-id: 9c214ca22c18f793d5f8b54997d129bdfa73e61a
Summary:
The current warning assumes the ruby binary to be single arch, but the ruby version shipping with macOS is universal `universal.arm64e-darwin20`. This PR changes the check to search for `arm64` in any position instead of just the beginning to fix false positives.
## Changelog
[iOS] [Fixed] - Fix Rosetta2 CocoaPods warning on Apple Silicon
Pull Request resolved: https://github.com/facebook/react-native/pull/32498
Test Plan:
### Before
On M1 Mac `pod install` using system ruby always yields a warning.
### After
`pod install` does not yield a warning.
`arch -x86_64 pod install` yields a warning.
Reviewed By: fkgozali
Differential Revision: D32013176
Pulled By: sota000
fbshipit-source-id: 84f517c210318b5d073d161b6849b9aee367bba6
Summary:
Running `pod install` from outside the `ios` folder fails because the
path to `React-Codegen` is wrong:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
[!] No podspec found for `React-Codegen` in `ios/build/generated/ios`
```
## 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] - `pod install --project-directory=ios` fails due to wrong path to `React-Codegen`
Pull Request resolved: https://github.com/facebook/react-native/pull/32489
Test Plan:
1. Verify that `pod install` still works in `/packages/rn-tester`
2. Verify that `pod install --project-directory=ios` also works:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
```
Reviewed By: lunaleaps
Differential Revision: D32158140
Pulled By: sota000
fbshipit-source-id: 98f12b0073cd911cb9de06201222d866ef7649a4
Summary:
## Rationale
- **Consistency with Static View Configs**: In Static View Configs, if there isn't a diff or process function, we do not generate a property for it.
- **Type-safety**: The [Flow type for attributes](https://fburl.com/code/tafncg5c), doesn't allow null diff/process functions.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32152924
fbshipit-source-id: 4156158c5fe09868feec1a0c55aa411d2bd72a27
Summary:
Setting `reactNativeDebugArchitectures` currently does not seem to work for RNTester, since it sets `abiFilters` which conflicts with the `splits` option we're already setting.
Gradle then complains:
```
neildhar@neildhar-mbp ~/f/x/j/react-native-github (default) >
./gradlew -PreactNativeDebugArchitectures=x86_64 :packages:rn-tester:android:app:installJscDebug
> Configure project :ReactAndroid
Unable to detect AGP versions for included builds. All projects in the build should use the same AGP version. Class name for the included build object: org.gradle.composite.internal.DefaultIncludedBuild$IncludedBuildImpl_Decorated.
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':packages:rn-tester:android:app'.
> com.android.builder.errors.EvalIssueException: Conflicting configuration : 'x86_64' in ndk abiFilters cannot be present when splits abi filters are set : x86_64,x86,armeabi-v7a,arm64-v8a
```
Consolidate everything with the `splits` option.
In addition, it's convenient to also be able to control the native architecture for release builds.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D31834075
fbshipit-source-id: c6375d2a1e242981d0017f6e0a9d428b074a3fbd
Summary:
CircleCI stopped populating `CIRCLE_PULL_REQUEST` without providing an
alternative, so now it's impossible to get the PR number unless it comes
from a forked repo.
## Changelog
[Internal] [Fixed] - ignore bundle size reporter failures
Pull Request resolved: https://github.com/facebook/react-native/pull/32490
Test Plan: CI should ignore bundle size reporter failures.
Reviewed By: fkgozali
Differential Revision: D32008694
Pulled By: lunaleaps
fbshipit-source-id: 68e25ac2fbb23c1d7a55e667c90aec3a61302b8a
Summary:
Ensures that copy of the native touch objects happens before consuming them.
The reverse order seems accidental after refactor, as copying objects doesn't consume them whereas adding to a native array does. This behavior didn't show up during testing in dev environment (only affects CANCEL events), and it seems to be the cause of high-firing crash on production.
Changelog: [Internal] Copy touch objects before consuming them in the new touch path.
Reviewed By: mdvacca
Differential Revision: D32112036
fbshipit-source-id: e9ec47689b7ceb0a40a23bab9f03367c4acb8632
Summary:
Makes new touch processing path check for double dispose on touch events.
Old event dispatcher has a race condition which makes it double-dispose some events, so we need to make sure it also processes touches correctly.
Changelog: [Internal] Check for double dispose when sending touch event
Reviewed By: cortinico
Differential Revision: D32110250
fbshipit-source-id: d6a12cbac60f9ff5e836cfaca5a47c467bea06c7
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:
We are in the middle of a Prettier upgrade and some of the files which disagree between Prettier v1.x and v2.x are now being flagged by `eslint-plugin-prettier` as lint errors.
The correct fix here is probably to update `eslint-config-prettier` and `eslint-plugin-prettier`, but I am landing this first to unbreak CI.
Reviewed By: mendoncakeegan
Differential Revision: D32129458
fbshipit-source-id: a5206a5ef58f1d7614f9459c99b9e39109be6de9
Summary:
**Motivation:** Readability. It was hard to tell how componentName, paperComponentName, and paperComponentNameDepreacted produced the NativeComponentRegistry.get call.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D32108276
fbshipit-source-id: ea7c9fe4dc50cdd6fec94b5cd25f7bbcfb451ef6
Summary:
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan:
- Clone this branch on both an Apple Silicon- & Intel-based Mac
- Run `pod install` in `packages/rn-tester`
- Confirm that build passes successfully
Reviewed By: cortinico
Differential Revision: D32080994
Pulled By: yungsters
fbshipit-source-id: 76a7c5bba20d91905455920609c890e92bb5b980
Summary:
For the sake of the playbook, I'm bumping the codegen to the latest stable.
This is needed as there was a change in the Android NDK Makefile that wasn't shipped yet.
Changelog:
[Internal] [Changed] - Bump codegen to 0.0.10
Reviewed By: hramos
Differential Revision: D32101355
fbshipit-source-id: c20268f1ea93ebad8f92f760874a43c8ceeaf9f9
Summary:
For the sake of the playbook, I'm bumping the Gradle Plugin to the latest stable.
Specifically a change in how CLI args are parsed (D31908041 (https://github.com/facebook/react-native/commit/70785e3d5a41bc85cea83aec0240e9f11aeff1ff)) was not backward compatible,
therefore we need to migrate users to the new version.
Changelog:
[Internal] [Changed] - Bump gradle-plugin to 0.0.3
Reviewed By: hramos
Differential Revision: D32101577
fbshipit-source-id: 9a29b988a4b520a8ece10a90a9a4bedc02ec16ad
Summary:
This PR adds the following GitHub actions:
- https://github.com/lucasbento/core-workflow-create-version-label - Create version labels (such as `Version: 0.65.1`) whenever there's a new release;
- https://github.com/lucasbento/core-workflow-apply-version-label - Apply a version label to opened/edited issues based on the version mentioned on the issue body.
## Changelog
N/A.
## Few things to keep in mind
- A label named "Version: unspecified" must be created;
- The GitHub action to create labels will only run when there's a new release or if one is edited, it will then create all the other labels bases on the previous releases until it encounters one that already exists.
---
Example of issue with version label: https://github.com/lucasbento/test-issue-forms/issues/4
Pull Request resolved: https://github.com/facebook/react-native/pull/32508
Reviewed By: cortinico
Differential Revision: D32055682
Pulled By: lunaleaps
fbshipit-source-id: 04d3e942eb1f71b3bc1d5a643b0156c35ef5f00b
Summary:
## Rationale
**Disclaimer**: This is an incremental step towards more maintainable/readable react-native-codegen generators. In the future, we may want to replace these templates/string concat logic with *something better*. But until we decide what that *something better* is, let's at least get rid of all this gross string find/replace.
Benefits of using Function templates over String.prototype.replace.
- **Self-documenting**: Template Functions enumerate/describe their exact data dependencies in their signature. You no longer have to read the template implementation to see what data you need to pass into the template.
- **Improved Readability**: JavaScript syntax highlighting makes it really easy to see where/how the data is inserted into the templates. Also template variables used be prefixed/suffixed with ::, which made things really confusing in C++ code (e.g: wtf is `::_CLASSNAME_::EventEmitter::::_EVENT_NAME_::`?).
- **Simpler Interpolation**: Don't have to worry about .replaceAll vs .replace, or calling these replace functions with regexes or strings.
- **Template Type-safety**: Ensure that the correct data types are passed to the component templates (e.g: flow will complain if you accidentally pass null/undefined when a template expects a string).
- **Template Type-safety**: Ensure that we don't pass in extra data to templates (this diff catches/fixes instances of this error). Ensure that we don't forget to pass in data to the template.
- etc.
After this diff, both our Component and NativeModule generators will be using template functions. This string find/replace exists no more in react-native-codegen.
This is also a very surface-level change. I made no efforts to simplify these templates. Let's take a look at that later, as necessary.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32021441
fbshipit-source-id: f8f27069bcbf9d66dcafb7d1411da1f938eb6dcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32443
This diff removes all the custom Gradle machinery to build the native code and delegates to AGP
the triggering of the `ndk-build` command. This means that the native build will be now invoked
with the `:ReactAndroid:externalNativeBuild<Variant>` task.
An important thing to notice is that that task will always run, and will delegate to Make the
compilation avoidance. If you invoke the task twice, the second time it will be significantly faster.
On my machine this takes ~6/7 mins the first time, and 30 seconds the second time.
There are some gotchas that are worth noting:
* The native build will run on every build now. Given the complexity of our native build graph,
even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the
targets and mention that there is no work to be done. I believe this could be impactful for local
development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI
of the target device (e.g. arm64 for a real device and so on).
This reduces the native build to ~10 seconds.
* All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be
considered invalid. Therefore they will re-extract the header files inside the folders that are
used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building
locally, if you plan to edit react-native-gradle-plugin and relaunch
rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here
would be to invoke the tasks like
```
gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \
-x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \
-x generateCodegenSchemaFromJavaScript
```
Changelog:
[Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task
Reviewed By: ShikaSD
Differential Revision: D31683721
fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
Summary:
Change usages of `exports.foo` and `module.exports.foo` to just `foo`.
This will fix future errors when Flow no longer allows reads from `exports`/`module.exports`.
Changelog: [Internal]
Reviewed By: bradzacher
Differential Revision: D32009490
fbshipit-source-id: bb609b37ba948b44c3877f8dbbfa9137b963586b
Summary:
The debug message stays `Building RNTester with Fabric enabled.` even if we set `fabric_enabled = false`
This pull request changes the message like below when `fabric_enabled = false`
`Building RNTester with Fabric disabled.`
## 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] - Fix the debug message for Fabric in rn-tester
Pull Request resolved: https://github.com/facebook/react-native/pull/32502
Reviewed By: sota000
Differential Revision: D32027858
Pulled By: lunaleaps
fbshipit-source-id: baf5301581e354f588830acd12a5e8171799b1ca
Summary:
Make `generate-specs-cli.js` use named arguments.
Updated all `generate-specs-cli.js` callsites to make use of named arguments.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31908041
fbshipit-source-id: f2cb5967db3c3b847e1095e35e8d5d21585be27b
Summary:
When calculating the offset range, we assume the first item is always at offset zero position and skipped that (as the smallerOffset is zero). However, this may not be the case in some situations. This diff changes the range measuring loop to always start from the first item.
Changelog:
[Android][Fixed] - Do NOT skip the first child view in the scroll view group when measuring the lower and upper bounds for snapping.
Reviewed By: mdvacca
Differential Revision: D31887086
fbshipit-source-id: af7221a621b2719d057afa6b64aa91c94ac01295
Summary:
Publishing a new version of the Gradle plugin as we need to distribute some
changes before releasing the playbook to the public.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.0.2
Reviewed By: ShikaSD
Differential Revision: D31957686
fbshipit-source-id: ef6742a205f2b568714c349dcb6481af33254b9b
Summary:
I'm removing the `src/test` folder from the npm bundle as it's not really
needed for the sake of distributing the gradle plugin.
Changelog:
[Internal] [Changed] - Do not publish tests inside the react-native-gradle-plugin npm package
Reviewed By: ShikaSD
Differential Revision: D31956449
fbshipit-source-id: b84138d24a7c51c44b92ebfc84f35afb3668dee5
Summary:
While working updating the codeden Makefile template for Android, I've removed
the `libreact_debug` and `libreact_render_debug` dependencies as they were unused in a
simple turbomodule. Turns out that `:ReactAndroid` is depending on having those dependencies.
Moving the build file to use AGP APIs, triggers this scenario and is making `ReactAndroid`
failing to build (see the build status for https://github.com/facebook/react-native/pull/32443).
I'm updating the codegen Makefile template to reintrodce the two libraries + I've update the prebuilt
makefile (used in the playbook) to include `react_debug` prebuilts as they were missing.
Changelog:
[Internal] [Changed] - Re-add libreact_debug to codegen makefile and add prebuilts for them
Reviewed By: ShikaSD
Differential Revision: D31900675
fbshipit-source-id: ff188c0498a0dca4a951a548a580ca8dd0674782
Summary:
Some of the prerendered surfaces rely on Android context being present to have correct theming (e.g. for platform colors) and measurements of platform components. This change uses context provided to initialize the surface as themed context before view is attached.
This way it is possible to configure theming with `ContextThemeWrapper` the same way as Litho does it for prerendering. The assumption is that any kind of customization done through Android theme will be applied from prerendering entry point as well.
Changelog: [Internal] - Use context from surface for prerendering
Reviewed By: mdvacca
Differential Revision: D31906091
fbshipit-source-id: 344fc96eb2f85ba5b762bee64d1a29443b3fd1d3
Summary:
I missed to push this change in the previous diff D31809012 (https://github.com/facebook/react-native/commit/f7e4c07c84b636fc33c64b434964c8a64c43438f).
This diff adds a check so that only when fabric is enabled it include the React-graphic dependency.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D31919354
fbshipit-source-id: 0b4e7f489155f868cdf58bec3f61f309470ca0c6
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:
Several desktop forks (`react-native-macos`, `react-native-windows`, `react-native-web`) support mouse events, and while the stock Pressable component has the ability to support mouse events, it seems we aren't forwarding some props properly from Pressable -> Pressability.
Pressability will calculate onMouseEnter / onMouseLeave event handlers based on the `onHoverIn/onHoverOut` callbacks passed into PressabilityConfig.
https://github.com/facebook/react-native/blob/ad0d4534a751ed05f84ff971714c8f7a4d1deb3a/Libraries/Pressability/Pressability.js#L552
However, Pressable does not pass take in onHoverIn/onHoverOut props to pass to PressabilityConfig, so we can't take advantage of this functionality. This change should simply address that by passing the props through.
## 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] - Pressabel not passing hover props and event handlers to PressabilityConfig
Pull Request resolved: https://github.com/facebook/react-native/pull/32405
Test Plan: I fixed a similar issue in `react-native-macos` that I am now trying to contribute back upstream. https://github.com/microsoft/react-native-macos/pull/855
Reviewed By: yungsters
Differential Revision: D31667737
Pulled By: sota000
fbshipit-source-id: f0bbe48302703bb2c45280d2afeec8d7a4586b6a
Summary:
As per the XMLHttpRequest specification [1], getAllResponseHeaders() should return a string of headers with lowercased names and sorted by their uppercase representation, with each header ending with '\r\n'.
[1] https://xhr.spec.whatwg.org/#the-getallresponseheaders()-method
## Changelog
[General] [Changed] XMLHttpRequest.getAllResponseHeaders() now returns headers with names lowercased and sorted in ascending order, as per specification
Pull Request resolved: https://github.com/facebook/react-native/pull/32363
Test Plan:
Test derived from Web Platform Test repository:
https://github.com/web-platform-tests/wpt/tree/master/xhr
Reviewed By: yungsters
Differential Revision: D31626217
Pulled By: sota000
fbshipit-source-id: 299d005facbe1c15b8cda5eed6750db75addca80
Summary:
Adding an error check to make debugging easier when codegen fails when invalid library_type option is passed.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31907880
fbshipit-source-id: c1ffa6bbd7b3e4faede88da2ee8d3378fa086780
Summary:
Currently, some filtering of generated files are done in multiple places (e.g. generate-specs-cli.js, react_native_pods.rb, etc). I am introducing this arguments so that only needed files are generated for components and modules.
Changelog: [internal]
Reviewed By: hramos, cortinico
Differential Revision: D31878098
fbshipit-source-id: d2dc8f51ea14a5d0ba1548bd481814220c9ae3a2
Summary: Changelog: [Internal] Remove github action to close upgrade-related issues. We will be moving these issue to react-native repo and using this tag
Reviewed By: cortinico
Differential Revision: D31837195
fbshipit-source-id: 51fdd6efd88c0ebd5c504730406b217c8dbb3a88
Summary:
Fixes https://github.com/facebook/react-native/issues/27052
Since react-native 0.62, the `devDisabledIn${buildType}` syntax has stopped working for apps with multiple `productFlavors`. This PR adds the `disableDevForVariant` lambda to allow dev mode to be disabled for different variants.
## 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] - Fix devDisabledIn not working with multiple productFlavors
Pull Request resolved: https://github.com/facebook/react-native/pull/30606
Test Plan:
I added the following log into `react.gradle` and ran the Android build for my app:
```
println("devEnabled: ${targetName}, ${devEnabled}")
```
```
# build.gradle
project.ext.react = [
entryFile: "index.android.js",
enableHermes: true, // clean and rebuild if changing
bundleInLive: true,
disableDevForVariant: {
def variant -> variant.name.toLowerCase().contains('release') || variant.name.toLowerCase().contains('live')
},
]
...
flavorDimensions 'branding'
productFlavors {
cve {
dimension 'branding'
}
whce {
dimension 'branding'
}
}
```
Console output:
```
Reading env from: env/cve/live
devEnabled: CveDebug, true
devEnabled: CveRelease, false
devEnabled: CveLive, false
devEnabled: WhceDebug, true
devEnabled: WhceRelease, false
devEnabled: WhceLive, false
```
Reviewed By: cortinico
Differential Revision: D31649977
Pulled By: ShikaSD
fbshipit-source-id: 520734314f4bca7608b8dca67c7c5ce0be6d31a5
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: Changelog: [Internal] Fix up basic styling of dark mode for examples. Individual examples still may be broken and will be fixed up individually
Reviewed By: yungsters
Differential Revision: D31710790
fbshipit-source-id: 6ca4fb8a6238f38ff484ec91518057b243ba1d7b
Summary:
Single and composite animations were handled inconsistently in AnimatedMock. Also added a guard to prevent callbacks from triggering additional animations, since we had a test-scenario that did exactly that.
Changelog:
[General][Fixed] - Composite animations will now be ran immediately when the app is in testing mode
Reviewed By: yungsters
Differential Revision: D31826967
fbshipit-source-id: a6416b42e227fe79f5c3a55a9c51beb8451874f8
Summary:
Bumping the codegen to a new version to ship a change to the Android template.
Changelog:
[General] [Changed] - Bump react-native-codegen to 0.0.9
Reviewed By: hramos, mdvacca
Differential Revision: D31762139
fbshipit-source-id: 71a96210a3577c12ff3c9f9013c6e72adf4a0ecb
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
Fix the `scripts/update-ruby.sh` so it always use the correct [bundle config](https://bundler.io/man/bundle-config.1.html#DESCRIPTION). In the current version it wasn't using the correct configuration inside the `template/` directory, resulting in incorrect platform for `template/Gemfile.lock`.
While at that, update the gems to their latest version:
- ethon 0.14.0 -> 0.15.0
- json 0.5.1 -> 0.6.0
- zeitwerk 2.4.2 -> 2.5.1
- bundler 2.2.28 -> 2.2.29
## Changelog
No changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/32456
Test Plan:
Run `bump-oss-version.js` and see `template/Gemfile.lock` lists `ruby` as the `PLATFORM` (no diff in that line).
## References
- https://github.com/facebook/react-native/commit/e18cf90d71d0bef2e2a0caf30a89e53129152965#r58230816
Reviewed By: yungsters
Differential Revision: D31841524
Pulled By: charlesbdudley
fbshipit-source-id: 695c245fcb344c866afed45f747e04233e5c91e4
Summary:
Adds utility script which crawls through a React Native app's Node dependencies and, for each compatible library, generates the relevant native code artifacts.
This script is for development purposes, and is not hooked into the existing codegen integration by design.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D28915433
fbshipit-source-id: de36d3e1dc0e11aad3ca55cea5e6731db09c5377
Summary:
The `ReactScrollView.java` constructor is using `ReactContext` instead of `Context`, which is inconsistent to the horizontal scroll view. This is the result from D3863966 (https://github.com/facebook/react-native/commit/2cf2fdbc04bc5309f6942ed464ad61cd06a26ce8) when an OSS issue needs to be addressed. That issue and all call sites to use the `ReactContext` are deprecated now.
Revert this back to use `Context` to be less restrictive.
Changelog:
[Android][Fixed] - Revert `ReactScrollView` to use `Context` instead of `ReactContext` in the constructor to be less restrictive.
Reviewed By: javache
Differential Revision: D31819799
fbshipit-source-id: 3f00d64850aebd2e20615033b2e1f1c721fed37e
Summary:
Changelog: [internal]
This change had to be reverted because it caused some issues internally at Facebook. After we solved those we re-applied the changes but this also has issues in OSS apps. Specifically, the option in Metro to inject modules to execute before the EntryPoint (in this case `InitializeCore`) doesn't work if those modules aren't part of the bundle in the first place.
This reverts again so we can think about a long-term solution for this.
Original commit changeset: ba145a30ead5
Reviewed By: ShikaSD
Differential Revision: D31825736
fbshipit-source-id: 393b3d5d2a726951a9ac386dc2b1c19ef4a916a5
Summary:
Colocate the surface ID generate with the code that consumes it. This allows us to re-use this method in other event emitter locations.
Changelog: [Android][Changed] Add helper to get surfaceId for event dispatching
Reviewed By: philIip
Differential Revision: D31651881
fbshipit-source-id: 109e189f90261d3ba0077ffa519c3d12a9111439
Summary:
Changelog:
[Android][Changed] RootView's onChildStartedNativeGesture now takes the child view as its first argument
Reviewed By: philIip
Differential Revision: D31399515
fbshipit-source-id: b9438f6118e604a04799ef67d0b46303a06d6434
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:
Adds the `glob` type definition via `flow-typed` so that the `combine-js-to-schema-cli.js` script does not need a Flow suppression.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D31800809
fbshipit-source-id: 3e01a096d2153639a619a7152bd06332df57f06b
Summary:
Many have reported about the misguiding error `Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so` even though they don't use Hermes (for example issues https://github.com/facebook/react-native/issues/26075#25923).
**The current code does not handle errors correctly when loading JSC or Hermes in `ReactInstanceManagerBuilder`**.
**ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManagerBuilder.java:**
```java
try {
return new HermesExecutorFactory();
} catch (UnsatisfiedLinkError hermesE) {
// We never get here because "new HermesExecutorFactory()" does not throw an exception!
hermesE.printStackTrace();
throw jscE;
}
```
In Java, when an exception is thrown in static block, it will be RuntimeException and it can't be caught. For example the exception from `SoLoader.loadLibrary` can't be caught and it will crash the app.
**ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/HermesExecutor.java:**
```java
static {
// Exception from this code block will be RuntimeException and it can't be caught!
SoLoader.loadLibrary("hermes");
try {
SoLoader.loadLibrary("hermes-executor-debug");
mode_ = "Debug";
} catch (UnsatisfiedLinkError e) {
SoLoader.loadLibrary("hermes-executor-release");
mode_ = "Release";
}
}
```
This PR fixes the code so that the original exception from failed JSC loading is not swallowed. It does not fix the original issue why JSC loading is failing with some devices, but it can be really helpful to know what the real error is. For example Firebase Crashlytics shows wrong stack trace with current code.
I'm sure that this fix could have been written better. It feels wrong to import `JSCExecutor` and `HermesExecutor` in `ReactInstanceManagerBuilder.java`. However, the main point of this PR is to give the idea what is wrong with the current 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
-->
[Android] [Fixed] - Fix error handling when loading JSC or Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/30749
Test Plan:
* from this PR, modify `ReactAndroid/src/main/java/com/facebook/react/jscexecutor/JSCExecutor.java` so that JSC loading will fail:
```java
// original
SoLoader.loadLibrary("jscexecutor");
// changed
SoLoader.loadLibrary("jscexecutor-does-not-exist");
```
* Run `rn-tester` app
* Check from Logcat that the app crashed with correct exception and stacktrace. It should **not** be `java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so`
Tested with Hermes
```
SoLoader.loadLibrary("hermes-executor-test");
```
Got this one in logcat
```
09-24 20:12:39.552 6412 6455 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes-executor-test.so
```
Reviewed By: cortinico
Differential Revision: D30346032
Pulled By: sota000
fbshipit-source-id: 09b032a9e471af233b7ac90b571c311952ab6342
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:
This diff updates the Makefile generated by `react-native-codegen`
to include the correct list of modules. Specifically I've removed some modules that are unused
like `libreact_debug` and added others that are necessary for the build to compile correctly
such as `libfbjni`.
Plus I've bumped the C++ version to 17 as we had a mixture of 14 and 17 across the codebase.
Changelog:
[Internal] [Changed] - Update codegen template to include correct native modules and C++17
Reviewed By: mdvacca
Differential Revision: D31754427
fbshipit-source-id: 8490fa5c5ad298689b564f760c3fc65550c94547
Summary:
Similary to the `release_blocker_form` we already have, this is migrating the
Bug report template to be an issue form.
Changelog:
[Internal] [Changed] - Move Bug Report Issue template to Issue Form
Reviewed By: lunaleaps
Differential Revision: D31729676
fbshipit-source-id: e78d5f4e8776fead17d45d340d98932cc41681e9
Summary:
I missed some spots where an unsupported key (fbandroid_compiler_flags) was being referenced.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31796826
fbshipit-source-id: 491b5121ef6461bef4a59c6aef65ce61f683341f
Summary:
This Diff is adapting the codegen configuration for ReactAndroid
to specify a path for the codegen package. I've used the `findNodeModulePath`
so this will work for both:
* The top level OSS project as `node_modules` will be at the top level
* The scenario where ReactAndroid will be included and built from source (as `node_modules` is in the `..` folder).
Changelog:
[Internal] [Changed] - Use explicit codegen path in ReactAndroid
Reviewed By: mdvacca
Differential Revision: D31730920
fbshipit-source-id: 6637da5d0098114f4379bcaeb8a40e976c46f194
Summary:
SurfaceHandlerBinding uses string from JVM memory when initializing, which is released before it is used. If JVM manages to collect this memory before instance init, it can lead to use-after-free.
Changelog:
[Internal] - fix memory corruption in cxx binding of surface handler
Reviewed By: mdvacca
Differential Revision: D31794515
fbshipit-source-id: 3944ebd065f42a516f036096d07c0126a43c912f
Summary:
Turns out that the Java generator is (as expected) outputting only Java code.
Therefore the C++ and the Markdown files are still generated by `react-native-codegen`.
I'm updating the logic to make sure the Java generator is not mutually exclusive and
overrides the output of `react-native-codegen`
Changelog:
[Internal] [Changed] - useJavaGenerator output should override the react-native-codegen one
Reviewed By: sshic
Differential Revision: D31754428
fbshipit-source-id: 3e6dae8212fbfebd28247ec17e88243871265808
Summary:
This diff is making sure that we're not failing the build
if either `ANDROID_NDK_PATH` or `ANDROID_NDK_VERSION` are missing.
Currently if any of the two is missing, a Gradle sync will fail.
This is problematic for the New Arch Rollout playbook as users will
import the `:ReactAndroid` project to build from source, and those
properties are instead defined at the `react-native` top level project.
Changelog:
[Internal] [Changed] - Safely access the project NDK properties
Reviewed By: sshic
Differential Revision: D31731291
fbshipit-source-id: ce4b762998ed545b3ec7ddcc07abbe4452602190
Summary:
I had to make this change when enabling Fabric in OSS. Without the full path, it can't find the modules like processColor within node_modules.
Changelog: Internal
Reviewed By: motiz88
Differential Revision: D31300424
fbshipit-source-id: 59b82470ec1ce63b63704931786e22b98f4bf046
Summary:
This bug is caused by RNAndroid dispatching an incorrect sequence of events to JS when the user taps on a Text.
Taking into consideration the example P462662009, when the user taps of the "Inner" text, RN Android is dispatching three events:
topTouchStart, topTouchStart and topTouchEnd.
The information stored on the first two JS events is correct, but the problem is that it is duplicated. This sequence of events makes Pressability to dispatch the event to the incorrect target.
This was originally introduced in D3035589 (https://github.com/facebook/react-native/commit/39fdce259dd46de8fd715efbfd12ede4bc24c8c2) (2016)
In this diff I'm changing the way RN Android bubbles events when the user taps on a ReactTextView. From now on, events won't be bubbled anymore, and they will be handled by the ReactRootView.onInterceptTouchEvent: https://fburl.com/code/rbt8$
Additionally, I'm creating a FeatureFlag in case this change has a unknown side effect that's only detected in production.
I will create a MC for FB4A in the next diffs of the stack
changelog: [Fixed][Android] Fix onPress event for nested Text in RN Android
Reviewed By: javache
Differential Revision: D31628461
fbshipit-source-id: 177397d4369191a3c97e2f86e801757b27ee5121
Summary:
Changelog: [Internal]
Now that Flow releases include a type def of `queueMicrotask`,
we can just inherit it from Flow
Reviewed By: yungsters
Differential Revision: D31754482
fbshipit-source-id: f42f8ec955f898d7a964ff85b6061d4840590d4d
Summary:
Creates a new `StaticViewConfigValidator` module that does strict, bidirectional validation. This is notably different from `verifyComponentAttributeEquivalence`, which is undirectional validation.
This will enforce that two configs are equivalent so we can start addressing the inconsistencies (especially per platform). It also improves upon the reporting format by providing more details about the invalidations.
It is hidden behind a `strict` runtime configuration parameter.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29024229
fbshipit-source-id: 10271945e089183f505205bd41de5e01faea7568
Summary:
The new architecture generates code that needs to be included in the xcode project. This diff adds a method that will be called when calling "pod install". There will be following diffs that will add the usage of this function.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31699330
fbshipit-source-id: 491de7f60afee69aae750bbda6a687cea2526cc0
Summary:
this little PR remove `accesibilityStates` config in validAttributes, like comment says it can be removed after next release.
## Changelog
[General][Removed] - `accessibilityStates` no longer passed through to RCTView.
Pull Request resolved: https://github.com/facebook/react-native/pull/29656
Reviewed By: philIip
Differential Revision: D31732866
Pulled By: yungsters
fbshipit-source-id: 83b6eb223e76537a09c13ccdb382317421ab4585
Summary:
The documentation of back easing contains a old link that
is now stale. I'm updating it to link to https://easings.net/#easeInBack
Fixes https://github.com/facebook/react-native/issues/32419
Changelog:
[Android] [Fixed] - Fixes documentation for back Easing animation
Reviewed By: hramos
Differential Revision: D31728560
fbshipit-source-id: 99f7aa60d3748af5429b4ae1aa6cbd79326c5fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32418
This commit does 2 things:
* Process and store stats for *-stable branches, in addition to main
* Print out the new stats to stdout, so that CI jobs can display them for verification purpose
This also means a new field `branch` is used for the Firestore data.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D31717251
fbshipit-source-id: 9dbfa8fb8f0243c013dcd822230400d26c09eaa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32426
This diff refactors the extractHeader and extractJni tasks to a single Gradle task in the `.internal` package.
The reason for this change is that those two tasks were always running, therefore invalidating the
whole native build cache.
Changelog:
[Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task
Reviewed By: mdvacca, ShikaSD
Differential Revision: D31682942
fbshipit-source-id: 191cc77902e82c0425949cee743d240ded790137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32427
This diff refactors the `prepareJSC` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareJSC` was just a plain `Task` and not a `Copy` task.
It was defining a top level `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the JSC headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareJSC to an internal task
Reviewed By: ShikaSD
Differential Revision: D31682293
fbshipit-source-id: 3d4cd9d9ce2fcd45e61f3c8c6685b69a622a1912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32424
This diff refactors the `prepareBoost` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareBoost` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Boost headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareBoost to an internal task
Reviewed By: ShikaSD
Differential Revision: D31662120
fbshipit-source-id: 87ba82c634da832ee54c3d13561df45d3fd71381
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32425
This diff refactors the `prepareLibevent` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareLibevent` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Libevent headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareLibevent to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661988
fbshipit-source-id: e55c2179a187fa156f701c25bae3b48a796e2660
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32421
This diff refactors the `prepareGlog` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareGlog` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Glog headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareGlog to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661668
fbshipit-source-id: efcd5505a67d6c9f02fcab7a5c3255a160215661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32422
While working on the NDK AGP Api I realized that the `enableVmCleanup` function,
that is supposed to cleanup the extra `.so` files from the final artifacts, is broken
for apps with variants. Specifically say for a `liteDebug` app it tries to search for `.so` files inside:
```
intermediates/stripped_native_libs/lite/debug/out/lib
```
while the `.so` files are located inside:
```
intermediates/stripped_native_libs/liteDebug/out/lib
```
I've fixed changing the token of the path from `targetPath` to `variant.name`
Changelog:
[Android] [Fixed] - Fix enableVmCleanup not working for apps with product flavors
Reviewed By: ShikaSD
Differential Revision: D31654704
fbshipit-source-id: 4af3478a3079ebcde4bd8e0c62bf4df7b6c75c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32420
While working on the NDK AGP Apis, I realized the the `applyAppPlugin` is accessed
too early inside the Gradle plugin. Specifically is accessed once the plugin is applied,
and the extension is not configured afterwards. This means that the extension is always set
the default values.
I'm fixing it moving it inside the `project.afterEvaluate` that was already need to access
the variant informations.
Changelog:
[Internal] [Changed] - Fix applyAppPlugin being accessed too early in the React App Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D31652984
fbshipit-source-id: e7ead3f8acb24372bf953fd90ad2a5dfbbeeeec0
Summary:
The [first implementation of `TextAttributes` in Fabric](https://github.com/facebook/react-native/commit/62576bcb7832e08c6fd9f9482285882c37a2ece5) included two separate props instead of `textDecorationStyle`: `textDecorationLineStyle` (single, double, ...) and `textDecorationLinePattern` (dot, dash, dotdash, ...). These two props were implemented in C++ and iOS but never supported in JS.
Pre-Fabric (and CSS) on the other hand use a single prop `textDecorationStyle: 'solid' | 'double' | 'dotted' | 'dashed'`.
This diff implements this same API in Fabric, and removes the unused `textDecorationLineStyle` and `textDecorationLinePattern` props.
Changelog:
[iOS][Fixed] - Implement `textDecorationStyle` on iOS and remove unused `textDecorationLineStyle` and `textDecorationLinePattern` from Fabric.
Reviewed By: dmitryrykun
Differential Revision: D31617598
fbshipit-source-id: f5173e7ecdd31aafa0e5f0e50137eefa0505e007
Summary:
While reworking our media picker, I ended up replacing the RNFetchBlob library to use `fetch()`, leveraging React Native's file resolver (especially to interpret `photos://` URI paths).
The migration process was pretty straightforward, however I kept getting RCTConvert errors when calling `fetch` with a `PUT` method and a blob body:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
+[RCTConvert NSString:]
RCTConvert.m:59
-[RCTBlobManager handleNetworkingRequest:]
-[RCTNetworking processDataForHTTPQuery:callback:]
-[RCTNetworking buildRequest:completionBlock:]
-[RCTNetworking sendRequest:callback:]
__invoking___
-[NSInvocation invoke]
-[NSInvocation invokeWithTarget:]
-[RCTModuleMethod invokeWithBridge:module:arguments:]
Test Plan:
I'll put my `fetch` snippet here. This is using a third-party library in order to get a signed URL, but it is otherwise pretty straightforward.
This snippet would trigger an error before the changes introduced by this PR.
```js
// Setup (specific to third-party lib)
const key = `file/path/in/bucket`
const params = {
Key: key,
Bucket: 'my.awesome.bucket',
}
const s3url = await s3.getSignedUrl('putObject', params)
// Letting RN handle how to retrieve a platform-specific resource URI
const localFetch = await fetch(localPath)
// Getting the blob to upload as octet-stream
const blob = await localFetch.blob()
// Actually uploading
await fetch(s3url, {
method: 'PUT',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/octet-stream',
},
body: blob,
})
```
Reviewed By: RSNara
Differential Revision: D31625636
Pulled By: sota000
fbshipit-source-id: a7770018bc3ff2f41321b1bd26ec145b86b18784
Summary:
The size information is currently not used for release branches. Further, the CI step failed because there is no PR associated with commits in RC branch. This commit fixed that error by skipping the entire work altogether.
Sample error: https://app.circleci.com/pipelines/github/facebook/react-native/10161/workflows/3625732a-531f-435d-83b6-1dbc638e1bab/jobs/215405/parallel-runs/0/steps/0-125
In theory, we should be storing RC bundle sizes as well, but the current backing Firebase DB has not been configured with proper index:
```
Error [FirebaseError]: The query requires an index.
...
```
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D31705912
fbshipit-source-id: 26757174f7937cb23d8e55066b833ae15ec011e3
Summary:
Changelog: [Internal]
making these imports a little more optimal & clean
Reviewed By: javache
Differential Revision: D31594240
fbshipit-source-id: 076610454a6f3c35ac58e97bd9f887b05b86f5bb
Summary:
Noticed we were sometimes receiving incorrect paths through the view hierarchy. This was largely harmless, as the hover events generated from this would still be correct. We just sometimes send more onExit/onEnter events than necessary.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D31434300
fbshipit-source-id: 3888270eaa16edf48f5d894a1e6daeca1ecfed1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32403
As the title says, we should cleanup issues that are really stale (i.e. more than one year inactive).
I ended up using actions/stale which is the first party solution for this.
Changelog:
[Internal] [Changed] - Add stale GitHub action
Reviewed By: hramos
Differential Revision: D31653083
fbshipit-source-id: 48538a571183f9ff28a23e7d1fdd01980581de35
Summary:
These dynamic_casts aren't really giving us much (they have never fired once in dev! and don't run in prod anyway). They also prevent us from disabling RTTI. So, let's get rid of them.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31634895
fbshipit-source-id: 4a9b259837127feb324f64fa3e9e23eb1cc481a6
Summary:
Using `WriteableNativeArray` directly in common code is breaking unit tests on CircleCI.
Changelog:
[Android][Internal] - Use mock of native array for sending touches
Reviewed By: mdvacca
Differential Revision: D31665842
fbshipit-source-id: 886418ff6a3f07046e8e17d4743060d80c26b288
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Centralize C++ compiler flags in rn_defs.bzl.
There is really no reason for these Cxx libraries to specify their own compiler flags: nearly 100% of them are identical, and the copypasta makes it difficult to make repo-wide changes (like upgrading C++ versions, etc).
This is now causing build failures until everything is migrated properly, and there are two flags (enable_rtti and enable_exceptions) that MUST have the same value and can be configured per-module, as needed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631767
fbshipit-source-id: 84f0441eb0ad09219e97d13babe0707d25f08472
Summary:
This seems like a remnant of an old refactor. This is passed in, we wrap it with a JMessageQueueThread and then never use it again.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31506280
fbshipit-source-id: aca01439dcddbe2b44ce80342fa8664f827919c9
Summary:
Updates touch events in Fabric to be dispatched through the same pipeline as the rest of events, instead of relying on custom dispatch behavior.
Previous method of handling touches was reusing Paper behavior which required:
1. Transform event into a Paper-compatible form of WritableArray and dispatch it to `RCTEventEmitter.receiveTouches`.
2. Intercept `receiveTouches` for Fabric and redirect it to `FabricEventEmitter`
3. Perform transformations copied from Paper JS renderer in Java, transform it to the final form and dispatch this event as usual after.
The new behavior uses emitter's `receiveEvent` method directly to dispatch events. Additionally, it should decrease allocations done when transforming events during step 3 above, as `WritableNativeMap`-based operations performed many re-allocations when reading/re-creating arrays.
Changelog:
[Android][Changed] - Added an experimental touch dispatch path
Reviewed By: JoshuaGross
Differential Revision: D31280052
fbshipit-source-id: 829c2646ac6b0ebff0f0106159e76d84324ac732
Summary:
Simplifies logic of touch dispatch by retrieving surface id and other require info from the event directly.
Changelog: [Android][Internal] - Simplify logic of dispatching touches
Reviewed By: cortinico
Differential Revision: D31583314
fbshipit-source-id: c6b6e131a759c2ebe0cf4441c3aeb1a8b9f5781e
Summary:
Ref https://github.com/facebook/react-native/issues/25601#issuecomment-510856047.
From https://github.com/facebook/react-native/pull/31040.
The `hermesFlagsRelease` option only works with the release build type, but not with other build types.
This PR allows hermes flags on a per variant basis to be specified using the `hermesFlagsForVariant` lambda.
It also allows the hermes debugger cleanup to be run on a per variant basis using the `deleteDebugFilesForVariant` lambda.
## 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] - Fix hermesFlags not working with multiple variants
Pull Request resolved: https://github.com/facebook/react-native/pull/32281
Test Plan:
Set the following options in `android/app/build.gradle` and ensure warnings are hidden when running `./gradlew assembleRelease` and `./gradlew assembleLive`.
```
hermesFlagsForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live') ? ['-w'] : []
},
deleteDebugFilesForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live')
},
```
Reviewed By: cortinico
Differential Revision: D31234241
Pulled By: ShikaSD
fbshipit-source-id: 2cb3dd63adbcd023061076b5a3b262a87b470518
Summary:
Propagate event category definition to every event that is using `dispatchModernV2` (gated in production), providing opportunity to override categories of some events if needed. No events are meaningfully affected by this change, as coalesced events (e.g. scroll) are always dispatched as continuous and touch events are handled separately.
Changelog:
[Internal] Expose event category in Event class
Reviewed By: cortinico
Differential Revision: D31276249
fbshipit-source-id: f9a756b3a5cf5897e17209f3d0aed6a1c16cbd2e
Summary:
This Diff is restricting the scope of `mavenCentral` to do not
include react-native packages. This will make us sure we don't pickup older
versions of react-native.
This specifically is a problem if you're building on a nightly as the version
of RN nightly is `0.0.0.xxx` which is lower than then version on maven central.
More on this here https://github.com/facebook/react-native/pull/32326#issuecomment-933368880
Changelog:
[Internal] [Changed] - Restrict mavenCentral to exclude react-native older packages
Reviewed By: ShikaSD
Differential Revision: D31571803
fbshipit-source-id: d7ce7e82825cbebda2e4e534565d7ab15dba2624
Summary:
https://reactnative.dev/docs/view.html doesn't work, this diff replaces the url for the new link
[Changelog]
[General][Fixed] - Updated documentation link in `View`.
Reviewed By: yungsters
Differential Revision: D31519836
fbshipit-source-id: c93feee4652caf4ef8390a047599149fc547db48
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 (https://github.com/facebook/react-native/commit/1a9e2d5d5589ce5cee92868ea5bccceb6e161eff). 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: Changelog: [Internal] - Change accessibilityValue.text type to allow for Stringish type
Reviewed By: yungsters
Differential Revision: D31577860
fbshipit-source-id: af12505794037a68850a16ce139359e2f8a879e4
Summary:
Added more logs to understand what's the root cause for https://fburl.com/logview/kgknonri
```java.lang.IllegalStateException: Message queue threads already initialized
at X.5y2.A0I(:64)
at com.facebook.venice.ReactInstance.<init>(:112)
at X.PrB.EgB(:33)
at X.2pN.run(:4)
at X.2pA.execute(:32)
at X.2p6.A00(:30)
at X.2p6.A08(:2)
at X.PrC.EgB(:26)
at X.Pr7.run(:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
Changelog:
[Android][Changed] - Add some logs
Reviewed By: RSNara
Differential Revision: D31584264
fbshipit-source-id: 11b8bb2c6c9af2266688e3dae95e09f0160de79a
Summary:
This is a proposal to adjust the in-code documentation to clarify the semantics of the `enableHermes` variable.
This fixes https://github.com/facebook/react-native-website/issues/2813.
## 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] - Clarified in-code documentation in the template's `android/app/build.gradle`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32382
Test Plan: This is just an update to documentation, no need for tests.
Reviewed By: yungsters
Differential Revision: D31550133
Pulled By: Huxpro
fbshipit-source-id: d60e5d256e1ffaf8556710b75582f1ae1c0f1fd3
Summary:
The elevation barriers that limited view reordering were applied incorrectly, disabling elevation completely for some combinations of views. This change ensures the order of barriers is correct and only disables elevation reorder between the children and not on them.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D31541961
fbshipit-source-id: 2fa4dc6906790053bd4445c841aeda0e2b3830e5
Summary:
The test_docker_android job on Circle CI has a simple function: verify the base community RN Android image can be downloaded, and verify that we can use it to build a container with a compiled Android test app.
Since the job is not strictly running a suite of tests, it can be moved to GitHub Actions. It will run on GitHub Actions as a Check on commits to main and pull requests.
As building the test image requires the use of the base React Native Android image, we can skip downloading the base container and go straight to building the test image.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31521978
fbshipit-source-id: ca8372a1464054e37f2da28a3ecfbc8f84db0408
Summary:
The `scrollTo` method in ScrollViews are using the `(x, y)` position they got from upperstream to scroll, and to set the state for Fabric. This diff fixes an edge case where the scroll result is not ended up to `(x, y)`. For example, if we are going to scroll to the last item in the list, the item may not scroll to the `(x, y)` position, but stay at the end position of the view.
- Change `scrollTo` method to use the actual `scrollX` and `scrollY` position after scrolling to set current state.
Changelog:
[Android][Fixed] - scrollTo API in ScrollView will check the actual scroll position before setting the scroll state
Reviewed By: JoshuaGross
Differential Revision: D31492685
fbshipit-source-id: e5513fb735ea68c5014b5c47fadffe461cad5c94
Summary: Changelog: [Internal] Configure circleCI to comment on PR after building tarball
Reviewed By: hramos
Differential Revision: D31387660
fbshipit-source-id: 28902148cf5e2ea15320333b90a6a7fa9d553c3b
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 module is imported by all flavors of the React Native renderers (dev/prod, Fabric/Paper, etc.), which itself imports `InitializeCore`. This is effectively a no-op in most React Native apps because Metro adds it as a module to execute before the entrypoint of the bundle.
This import would be harmless if all React Native apps included all polyfills and globals, but some of them don't want to include everything and instead of importing `InitializeCore` they import individual setup functions (like `setupXhr`). Having this automatic import in the renderer defeats that purpose (most importantly for app size), so we should remove it.
The main motivation for this change is to increase the number (and spec-compliance) of Web APIs that are supported out of the box without adding that cost to apps that choose not to use some of them (see https://github.com/facebook/react-native/pull/30188#issuecomment-929352747).
Changelog: [General][Removed] Breaking: Removed initialization of React Native polyfills and global variables from React renderers.
Note: this will only be a breaking change for apps not using the React Native CLI, Expo nor have a Metro configuration that executes `InitializeCore` automatically before the bundle EntryPoint.
Reviewed By: yungsters
Differential Revision: D31472153
fbshipit-source-id: 92eb113c83f77dbe414869fbce152a22f3617dcb
Summary:
We are defining an alias for the global variable in React Native called `GLOBAL`, which is not used at all at Facebook and it doesn't seem it's used externally either. This alias is not standard nor common in the JS ecosystem, so we can just remove it to reduce the pollution of the global scope.
Changelog: [General][Removed] - Removed unnecessary global variable `GLOBAL`.
Reviewed By: yungsters
Differential Revision: D31472154
fbshipit-source-id: 127c3264848b638f85fb2e39e17ed2006372d2dd
Summary:
The Modal's mock always render its children (whether it is visible or not), whereas in reality the Modal renders `null` when the Modal is not visible.
This causes troubles when trying to test whether the Modal is visible or not. Instead of testing if the children are rendered (using getByText from React Native Testing Library for instance), we are forced to test the value of the visible prop directly (see https://github.com/callstack/react-native-testing-library/issues/508 and https://github.com/callstack/react-native-testing-library/issues/659).
This is not ideal because we are forced to test implementation detail and can't test from the user perspective. I also believe the mock should be closest as possible from reality.
I had 2 options:
1. Rendering the Modal without its children
2. Not rendering the Modal at all
The latter has the advantage of being closer to the reality, but I chose the former to still be able to test the Modal through the visible prop, so there is no breaking change (only snapshots update will be required).
## Changelog
[General] [Changed] - Update Modal's mock to not render its children when it is not visible
Pull Request resolved: https://github.com/facebook/react-native/pull/32346
Test Plan:
I added a test case when visible is false, then updated the mock so the children are not rendered. The before / after is here:
Reviewed By: yungsters
Differential Revision: D31445964
Pulled By: lunaleaps
fbshipit-source-id: 08501921455728cde6befd0103016c95074cc1df
Summary:
changelog: [internal]
Catch JavaScript errors and forward them to `ErrorUtils` in *RuntimeScheduler*. This makes sure that JS errors are handled by ErrorUtils and do not bubble up to bridge.
Reviewed By: philIip
Differential Revision: D31429001
fbshipit-source-id: 50f865872e4cd3ba180056099ff40f5962ee7a77
Summary:
We noticed that by default when the RootView / ReactView calls runApplication, we're logging at an info level any props ("params") passed to that component. In our case, one of these props was sensitive in nature, causing the value to leak out in logs for our release builds. This is especially problematic on Android where device logs can be accessed by any app which requests that permission.
This is probably more of a concern for brownfield react-native apps, but it seems worthwhile locking this down in non-dev builds.
## 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] [Security] - Avoiding logging root view params outside of dev / debug mode builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31522
Test Plan: * build app in release mode on Android and verified I could not see: `Running "my app" with { sensitive: 'thing' }` in logcat in Android Studio with a tethered device
Reviewed By: yungsters
Differential Revision: D31064902
Pulled By: charlesbdudley
fbshipit-source-id: 8b10a46d92a9ec44243dd74384299087260c7d83
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:
In https://github.com/facebook/react-native/issues/31609, the deprecated `jcenter()` was replaced with `mavenCentral()`. In the template build.gradle, it _also changed the order of repos_. I am not sure if this was done intentionally or not (dulmandakh please confirm). Instead of appearing right _after_ `google()`, `mavenCentral()` was put **first** in the list, even before the local repos (that, for example, contain the `react-native` artifacts fetched by npm). Now, under normal circumstance, this _might_ not cause issues because of latency, but there is chance that Gradle could resolve incorrect versions (or at least look in the wrong repo first). The last version of `react-native` published to the public repo was [`0.20.1`](https://mvnrepository.com/artifact/com.facebook.react/react-native/0.20.1), uploaded in February 2016!
This PR changes the order of `mavenCentral()` so that is consistent with both the repo's current [root level build.gradle](https://github.com/facebook/react-native/blob/main/build.gradle.kts#L34), as well as other default Android templates. Putting the local repos first will ensure they have the highest priority when looking for artifacts. `react-native` should _always_ come from the locally downloaded `node_modules/` folder, not from a remote repo.
## Changelog
[Android] [Changed] - Move mavenCentral repo below local paths
Pull Request resolved: https://github.com/facebook/react-native/pull/32326
Test Plan: Create new app from template, ensure local repos appear before remote repos; `react-native` resolves to correct version.
Reviewed By: yungsters
Differential Revision: D31375678
Pulled By: cortinico
fbshipit-source-id: e47737262b4eebb06e22a955cacd6114059bb2f4
Summary:
When the overflow style set to 'scroll', React ViewGroup does nothing to the container. Instead it should be clipped just like hidden.
Changelog:
[Android][Changed] - Setting `overflow: scroll` in View component style will clip the children in the View container
Reviewed By: javache
Differential Revision: D31350605
fbshipit-source-id: e0d618f5e872fec9cf9ecb2d4cfe7af9a2f3c063
Summary:
changelog: [internal]
Retaining `EventEmitter` beyond runtime triggers a crash. Let's try to use raw pointer in `EventEmitterWrapper` to see if it fixes some crashes.
Reviewed By: philIip
Differential Revision: D31307332
fbshipit-source-id: cd059b6c56f8dffe985b3ecb62cdafe823ba1462
Summary:
Implement par of the discussion https://github.com/react-native-community/discussions-and-proposals/discussions/411, except the `.nvmrc` part, this includes:
- Setting `.ruby-version` in the main project and also `template/`
- Fixing the CocoaPods version with a project-level `Gemfile` and also `template/Gemfile`
- Using all `pod` executions from `bundle exec pod`, using the determined version
- Script to manage and update the ruby version
## Changelog
[iOS] [Added] - Gemfile with CocoaPods 1.11 and ruby-version (2.7.4)
Pull Request resolved: https://github.com/facebook/react-native/pull/32303
Test Plan: Build for iOS and run all CircleCI tests to see if nothing changed
Reviewed By: RSNara
Differential Revision: D31344686
Pulled By: fkgozali
fbshipit-source-id: 25c63131ca9b16d3cf6341019548e0d63bdcaefe
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:
changelog: [internal]
This is a pre-condition to get rid of `shared_ptr` from `EventEmitterWrapper`. Also saves us a few copies of shared_ptr, this is negligible though.
Reviewed By: mdvacca
Differential Revision: D31307048
fbshipit-source-id: b84654bed2359b66faf3995795e135e88fe51cb6
Summary:
Event merging or "coalescing" is done on Java side from Android, but Fabric also includes some Cxx logic to merge those events. Although Android doesn't need this logic in particular, it is important to follow this path to ensure these events (e.g. scroll) are dispatched as "continuous", allowing for correct prioritization in Concurrent Mode.
`dispatchModernV2` selects between `dispatch` and `dispatchUnique` based on the `canBeCoalesced` parameter of the event, which is exactly what we need. The logic is only used in the "new" event dispatcher at the moment, so I wrapped it with feature flag to validate it doesn't cause any regressions.
Changelog:
[Android][Internal] - Try dispatching coalescing events as unique to Fabric
Reviewed By: sammy-SC
Differential Revision: D31272585
fbshipit-source-id: 6b67b61bd13fbff019d9eb8c5172bdd814a7b5b8
Summary:
Assuming this method was deprecated to mean experimental.
This execution path is used by overwhelming majority of events and it seems as stable as it can be.
Changelog:
[Android][Changed] Removed experimental deprecation from `dispatchModern`
Reviewed By: cortinico
Differential Revision: D31270721
fbshipit-source-id: 5a7e50455ab2850adf9bc86a248773b170bf0ab9
Summary:
We forgot to make ClipboardModule TurboModule compatible. I think this was most likely because our codemods targeted all Java classes that extended ReactContextBaseJavaModule. The ClipboardModule extends ContextBaseJavaModule instead.
There are no other NativeModules that extend ContextBaseJavaModule.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D31291293
fbshipit-source-id: cf5d21898101699f8c349b013a77e8329339a8d3
Summary:
Pressability previously was filtering which events get forwarded through the PerformanceEventEmitter, but this causes issues for native telemetry systems which won't know which events Pressability has skipped (or why).
Also, the "delay ms" no longer has any meaning because the native timestamps and Date.now() have a different time-basis entirely.
Changelog: [Internal]
Differential Revision: D31251300
fbshipit-source-id: f097047ac150e8dddb0f3857d9f375bae2318681
Summary:
Original commit changeset: ab1e842b60c5
Changelog:
[Internal] [Changed] - Back out "[RN][Android] Make react-native depend on react-native-gradle-plugin"
Reviewed By: fkgozali
Differential Revision: D31310547
fbshipit-source-id: 46c4c1e41b0f5432bc24975f754e0852e7180769
Summary:
Similarly to what we did for react-native-codegen, I'm introducing
a dependency between RN and the Gradle plugin, to be processed upon OSS bumps.
Changelog:
[General] [Added] - Make react-native depend on react-native-gradle-plugin
Reviewed By: fkgozali
Differential Revision: D31206303
fbshipit-source-id: ab1e842b60c51d0dce272892a30be2e27350f9bb
Summary:
When we were iterating on the Fabric renderer, animated components went through some iteration to ensure that animated shadow nodes were not flattened away. At the time, `collapsable` was not supported on iOS, even in Fabric, because the legacy renderer would not publish the `collapsable` prop on the view config.
This has since been fixed and `collapsable` is supported on both Android and iOS. We no longer need the `nativeID` workaround to prevent view flattening.
For use cases of the JavaScript driver and legacy renderers, this change will cause views which used to be flattened to no longer be flattened. This seems like an appropriate change considering the direction that we are moving (in which everything is eventually transitioned to using the Fabric renderer).
Changelog:
[Android][Changed] - Native views backing Animated.View (w/ JavaScript-driven animations) will no longer be flattened; this should be a transparent change.
Reviewed By: lunaleaps, mdvacca
Differential Revision: D31223031
fbshipit-source-id: 48dc63471eef406f4c215bfea0b3ef82a05d4b24
Summary:
Add examples for Switch component in RN Tester app for:
- ios_backgroundColor
- onChange
## 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] [Added] - Added examples to Switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/30611
Test Plan: 
Reviewed By: lunaleaps
Differential Revision: D25680480
Pulled By: sota000
fbshipit-source-id: 91202a0d8699554b0535f1a91875fd9fc664d54d
Summary:
Expands the building of npm tarballs to include branches that match the /^(\d+)\.(\d+)-stable$/ regexp.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31272377
fbshipit-source-id: a536a0b5e14812ece8266f3c83497071405a164a
Summary:
changelog: [internal]
This code assured that view preallocation is only triggered if ShadowNode is cloned from revision 0 to revision 1 (first time ShadowNode is cloned).
Node can go from virtual to view forming in subsequent clones, not just the first one. This is more of a case in Concurrent React where the node can be cloned many times before it is first mounted.
Reviewed By: mdvacca
Differential Revision: D31237719
fbshipit-source-id: 13fe6d10fdc815dbdae785d1d9d86d1c8fd36be4
Summary:
Updates event category deduction to match iOS implementation.
The event priority is used by concurrent mode to prioritize certain events, where Cxx part already assigns the correct priority based on the `ContinuousStart` -> `ContinuousEnd` spans. These spans can be deduced from the touch events, which we do in this implementation.
All events that can be "coalesced" (dispatched through `invokeUnique`) are assigned `Continuous` by default in Fabric core, so scroll/slider change events will never be discrete.
Changelog:
[Internal] Add category deduction to Android touch events
Reviewed By: mdvacca
Differential Revision: D31233233
fbshipit-source-id: f5b039aa137f1b4d2e2b15578bfc29ab6903a081
Summary:
For iOS, event category deduction is done from the C++ code, but the touch events are handled on Java layer in Android. This change exposes the category parameter through the `EventEmitterWrapper` called from Java, allowing to define category for events in the future.
Changelog:
[Internal] - Expose event category through JNI
Reviewed By: mdvacca
Differential Revision: D31205587
fbshipit-source-id: f2373ce18464b01ac08eb87df8f421b33d100be2
Summary:
Removes `metro-babel-register` as a runtime dependency of the `react-native` package, where it is only used as a dev dependency (in the Jest preprocessor).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D31177424
fbshipit-source-id: bf7b7216116744a3234beea089d0028c0bfe4d1e
Summary:
Fix Image defaultSource not showing on iOS.
This bug was introduced somewhere between RN 0.63 and 0.65. On iOS, defaultSource does not show while the image is being downloaded, only if it fails or there's no internet.
## 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] - Fix Image defaultSource not showing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32172
Test Plan: Ran both debug and release builds on an iPhone 12 pro (iOS 14.6)
Reviewed By: sammy-SC
Differential Revision: D30822805
Pulled By: lunaleaps
fbshipit-source-id: c4ef18723a8311ef3be1d7ae25ff3c205e8fff62
Summary:
This diff extends the current implementation of ScrollView.snapToAlignments from RN Android to reach feature parity with RNiOS
changelog: [Android][Changed] Implement ScrollView.snapToAlignments in RN Android
Reviewed By: javache
Differential Revision: D31206398
fbshipit-source-id: b6534965c476a0a4745ac98b419cbe05dc5c746e
Summary:
This diff implements the SnapToAlignment functionality in ReactScrollView for RN Android.
In order to use SnapToAlignment, the pagingEnabled prop should be set
Based on the documentation the behavior implemented in this diff is more "advanced" than the one implemendted in RNiOS, because it let you snap without specifying any interval nor offset (it calculates the intervals in real time based on the size of its content)
I still need to verify how different RNiOS and RN Android behaviors are
changelog: [Android][Added] Implement SnapToAlignment in ReactScrollView
Reviewed By: JoshuaGross
Differential Revision: D31182786
fbshipit-source-id: a9b55d9c00326ae21ca9b89575e79c60bf9edcca
Summary:
This diff adds the new snapToAlignment into ReactScrollViewManager
changelog: [Android][Added] Implement snapToAlignment into ReactScrollViewManager
Reviewed By: JoshuaGross
Differential Revision: D31182787
fbshipit-source-id: 8049ceb462461a11f184dbc1b40ca8079a3e8b60
Summary:
This diff implements the SnapToAlignment functionality in ReactHorizontalScrollView for RN Android.
In order to use SnapToAlignment, the pagingEnabled prop should be set
Based on the documentation the behavior implemented in this diff is more "advanced" than the one implemendted in RNiOS, because it let you snap without specifying any interval nor offset (it calculates the intervals in real time based on the size of its content)
I still need to verify how different RNiOS and RN Android behaviors are
changelog: [Android][Added] Implement SnapToAlignment in ReactHorizontalScrollView
Reviewed By: JoshuaGross
Differential Revision: D31174544
fbshipit-source-id: 204a82f55e3b7598124ce2528d8ad7d854c0ac77
Summary:
This diff adds the new snapToAlignment into ReactHorizontalScrollViewManager
changelog: [Android][Added] Implement snapToAlignment into ReactHorizontalScrollViewManager
Reviewed By: JoshuaGross
Differential Revision: D31174545
fbshipit-source-id: c56bfca207980428be98dd21a5387a0ff6bcd296
Summary:
Add a new -v or --to-version argument to the bump-oss-version script.
When the bump-oss-version script runs, it will use the version string that is passed in, instead of trying to infer it from the current commit. This fixes a bug in the last nightly release where the bump script used a different version string than what the publish script expected.
Nightlies now run at 20:00 hours UTC.
Changelog: [Internal]
Reviewed By: fkgozali, TheSavior
Differential Revision: D31261829
fbshipit-source-id: a9341f93c3c7bf0379aa3c5e7f345182df70f846
Summary:
Bump the version of Xcode used in internal and external iOS tests, as well as the CocoaPods version used in RNTester (and therefore, the internal CocoaPods offline mirror).
New versions used:
* Xcode 13.0.0
* CocoaPods 1.11.2
See Circle CI Xcode 13.0.0 macOS Container Software manifest: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v6052/index.html
* Xcode 13.0 Build version 13A233
* CocoaPods 1.11.2
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31253170
fbshipit-source-id: c85f3ee12fa708d9e54fef1200f3124810211d2f
Summary:
Since Apple released its own silicon M1, an ARM64, the react-native build is broken or at least not as effective as it should.
This PR stops excluding `arm64` simulator (this is not needed on the M1 neither on Intel devices) and removes the problematic `$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)` from `LIBRARY_SEARCH_PATHS`, since on Xcode 12.5 and 13.0 this folder contains only `i386/x86_64` binaries and will fail compilation.
Instead this PR forces `$(SDKROOT)/usr/lib/swift` while it removes the incorrect directory. Ideally we could just remove `LIBRARY_SEARCH_PATHS` altogether if `$(inherited)` and `$(SDKROOT)/usr/lib/swift` were the only entries, but it would require us a **newer CocoaPods**, since that was fixed with `1.11` (see https://github.com/CocoaPods/CocoaPods/commit/6985cbf7de73f645029e8a716cad0c89ff81e3c8). Since we don't enforce that, lets keep the `$(SDKROOT)/usr/lib/swift` and call it done.
Last but not least, deprecate the `__apply_Xcode_12_5_M1_post_install_workaround()` as it's not needed anymore, at least with recent versions of the dependencies, no patching is required with RCT-Folly, neither we need to force `IPHONEOS_DEPLOYMENT_TARGET=11.0`
## Changelog
[iOS] [Fixed] - Xcode 12.5+ build of iPhone Simulator on Apple M1
[iOS] [Changed] - Do not exclude the arm64 iphonesimulator
[iOS] [Deprecated] - __apply_Xcode_12_5_M1_post_install_workaround()
Pull Request resolved: https://github.com/facebook/react-native/pull/32284
Test Plan:
* Build `packages/rn-tester` on M1 and see it still works properly
* Run `pod install` on x86_64 and arm64 (m1) and see the `project.pbxproj` is not changed
## References:
* Closes https://github.com/facebook/react-native/issues/31480
* The initial fix https://github.com/facebook/react-native/commit/ac4ddec542febda744de218dae3a3d34edc7da84
* Upgrading CocoaPods to 1.11 would bring us https://github.com/CocoaPods/CocoaPods/commit/6985cbf7de73f645029e8a716cad0c89ff81e3c8 and we could avoid adding `$(SDKROOT)/usr/lib/swift` ourselves
Reviewed By: lunaleaps
Differential Revision: D31248460
Pulled By: fkgozali
fbshipit-source-id: 5a0d69593e889e296a2ba2e7b4387ecbd56fc08d
Summary:
Package a npm tarball for react-native on pull-request commits, for ease of testing during development.
Ensure npm/github secrets are not exposed on pull-request builds (e.g. Circle CI will only grab the CIRCLE_NPM_TOKEN and GITHUB_TOKEN on jobs triggered by tagged commits or commits on main)
Renames Circle CI `publish_npm_package` job to `build_and_release_npm_package`, and uses `build_npm_package` for dry runs (e.g. commitlies).
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D31243726
fbshipit-source-id: 2907febac3286a1504984c2f14e84dec1d819858
Summary:
This diff introduces a new interface named `SurfaceDelegate`. The interface abstracts the API for interacting with a surface, which is required for platforms other than mobile to implement how it wants to show and hide a surface. For existing Mobile use cases, the `LogBoxDialogSurfaceDelegate` is provided as a fallback solution so everything still works.
Changelog:
[Android][Added] - Add SurfaceDelegate abstraction to support interaction in multiple platforms and provide default implementation in LogBoxModule
Reviewed By: mdvacca
Differential Revision: D31132285
fbshipit-source-id: 13315a8bc5b7bcaee9b5e53ef5c6f6cc8cb01f31
Summary:
Fixed typo in Share component docs
## 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
-->
[Internal] [Fixed] - Fix typo in Share component docs
Pull Request resolved: https://github.com/facebook/react-native/pull/31295
Test Plan: N/A
Reviewed By: yungsters
Differential Revision: D31152173
Pulled By: charlesbdudley
fbshipit-source-id: 831252f24876986fd053ff5e9875fef1132fa957
Summary:
Original commit changeset: 9ccfb4b6d477 / D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195)
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:
Nightlies will be tagged with the commit they are based off and a timestamp.
> Example: `react-native-0.0.0-084a8b5f0-20210928-054053`
Commitlies now use the proper name on Circle CI for their job: `build_commit_package`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31224640
fbshipit-source-id: d1742a1d475aaf60d7b4c0708e30a5c5b205182d
Summary:
Scheme names may contain whitespace characters is used as path of the
path for various files during build time. This means any path that
includes the scheme name in it needs to be surrounded by quotes.
You can see the generated command below for a project with a scheme
called `Some Scheme`:
node ./node_modules/react-native/cli.js bundle \
--entry-file index.js \
--platform ios \
--dev false \
--reset-cache \
--bundle-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle' \
--assets-dest './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app' \
--sourcemap-output ./ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle.map
`--bundle-output` and `--assets-dest` are properly quoted, but
`--sourcemap-output` is not.
This changes `$EXTRA_ARGS` to an array of strings so that we can
propertly quote `$PACKAGER_SOURCEMAP_FILE` when passing it to the
`--sourcemap-output` argument. When running the bundle command, this
array is unwrapped and all its elements passed as individual arguments.
It also applies the same unwrapping to `$EXTRA_PACKAGER_ARGS` so that
users can also pass an array of options when arguments containing spaces
are needed.
It's important to note that these changes ARE backwards compatible: if
`$EXTRA_PACKAGER_ARGS` is defined as a simple string, instead of an
array of strings, the command won't break, as it will still expand
correctly.
## 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] - Source map path for schemes containing whitespaces
Pull Request resolved: https://github.com/facebook/react-native/pull/31587
Test Plan:
With the new change, the generated command becomes:
node ./node_modules/react-native/cli.js bundle \
--entry-file index.js \
--platform ios \
--dev false \
--reset-cache \
--bundle-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle' \
--assets-dest './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app' \
--sourcemap-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle.map'
Reviewed By: yungsters
Differential Revision: D30911631
Pulled By: charlesbdudley
fbshipit-source-id: 0c2d98746b365285fe693bcc867a24d3fc649f50
Summary:
About asdf-vm: https://asdf-vm.com/
This PR add [asdf-vm](https://asdf-vm.com/) support to `find-node.sh` for `scripts/react-native-xcode.sh` in `Bundle React Native code and images` build phrase and potentially other scripts using `find-node.sh` to get executable nodejs
## Changelog
[iOS] [Added] - add asdf-vm support in find-node.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/30111
Test Plan: Xcode is able to complete `Bundle React Native code and images` build phrase without errors when node is installed by asdf-vm
Reviewed By: yungsters
Differential Revision: D31064080
Pulled By: charlesbdudley
fbshipit-source-id: aa73620fc39027c58c9cdfbb554cd5698b917850
Summary:
Update the showcase url to the right url.
When I did check out the repository and I was about to navigate to showcase. I found out the url was wrong.
## 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] [Changed] - Changed the showcase URL
Pull Request resolved: https://github.com/facebook/react-native/pull/32277
Reviewed By: lunaleaps
Differential Revision: D31206326
Pulled By: cortinico
fbshipit-source-id: a4092e9bb74d9a9cc68d7252aa131083dd38b6ca
Summary:
Changelog: [Internal]
Some environments that use codegen don't have Haste enabled, breaking the `require('NativeComponentRegistry')` call in generated view configs. Here we change it to reference an explicit path relative to `react-native`.
Reviewed By: JoshuaGross
Differential Revision: D31166063
fbshipit-source-id: cebc23d0d95b5cde76d0f8473eabc03ca82a862e
Summary:
Before we can publish `0.0.1` of `react-native-gradle-plugin`, we
need to write a README file for it.
Changelog:
[Internal] [Changed] - Add a README before publishing the react-native-gradle-plugin
Reviewed By: ShikaSD
Differential Revision: D31206204
fbshipit-source-id: 0168298d04d4619dde931eb75d9555982f50fffe
Summary:
Removing the App postfix from the plugin as that is
a result of the merging. This aligns the plugin ID to the plugin
class name.
Changelog:
[Internal] [Changed] - Renamed Gradle Plugint to `React`
Reviewed By: ShikaSD
Differential Revision: D31205318
fbshipit-source-id: 23cd24c91fa8526137045e8537f03f560be939cb
Summary:
The version of npm available in Circle CI is 6.x, which does not support the `--pack-destination` argument. As a result, `npm pack --pack-destination build` was interpreted as a request to package the 'build' directory for distribution.
Since we need to make sure the output of `npm pack` is consumed by Circle CI's `store_artifacts` directive, we move the commitlies release packing logic to the Circle CI job config itself as to reduce coupling between `publish-npm.js` and the Circle CI config.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31183635
fbshipit-source-id: f0e0baae4ae31941dbb78dd1fec689f0f3398b52
Summary:
We only need to ensure `react-native-codegen` is a direct dependency of `react-native` in open source releases. Otherwise, we can use the package from source at `packages/react-native-codegen`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31190817
fbshipit-source-id: 527b1c370a35c3efad2448b510172a87c7345ee2
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:
When TouchEvent is created in RN, we're currently using System.currentTimeMillis - but this can differ from the MotionEvent timestamp by a few milliseconds.
This difference is very minor but makes it challenging to implement touch telemetry. It's easy and should be zero-impact otherwise to align the timestamps.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31183733
fbshipit-source-id: 5b275ee534658dc429beb1d3cec0c83a779b5ea3
Summary:
OSS uses old architecture and being able to use RNTester as a test ground for non-fabric components.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31186468
fbshipit-source-id: d5e7fb679b8ce28ba3050f83cd2d61d42cb4a122
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:
Otherwise known as "commitlies," these are per-commit releases that do not get published to npm. They can be downloaded from Circle CI's artifacts pane on the relevant "build_npm_package" job.
If `--dry-run` flag is passed to `publish-npm.js`, it will perform the same steps as a `--nightly` but it will stop short of publishing the nightly to npm. The tarball for the release will be available in the `build/` directory.
Commitlies are implemented by triggering a `--dry-run` publish step on any commit that is not tagged as an open source release (e.g. `/v[0-9]+(\.[0-9]+)*(\-rc(\.[0-9]+)?)?/`).
Changelog:
[Internal]
Reviewed By: sota000
Differential Revision: D31177828
fbshipit-source-id: 7d4f79e1ed15718a177d2cb8fc620d5fb860ccf9
Summary:
Uses `enableZ` trick to ensure that Skia doesn't try to reorder the views based on elevation. Unfortunately, it only helps for some cases, but the proper fix would require reimplementing `ViewGroup` completely to remove its internal logic of reordering based on Z coordinate.
Changelog: [Android][Fixed] Ensure elevated views are behind sticky header in FlatList
Reviewed By: cortinico
Differential Revision: D30700566
fbshipit-source-id: d2c59b22332922c610f4f2d415df34e81f5a33c5
Summary:
The generate script file was removed but the package.json file was never update.
I'm doing it here.
Changelog:
[Internal] [Changed] - Removed extra missing script from package.json
Reviewed By: ShikaSD
Differential Revision: D31171736
fbshipit-source-id: 5b9474651d10374ccbb0b06f2c83bc34da01a179
Summary:
This diff adds a `package.json` inside `react-native-gradle-plugin`
so it can be distributed and used inside the `template/` project
similarly to what we do with the `react-native-codegen` package.
Changelog:
[Internal] [Added] - Setup a package inside `react-native-gradle-plugin`
Reviewed By: fkgozali
Differential Revision: D31081980
fbshipit-source-id: 9a9ad696ee6db01666bae75255616fd20aadd243
Summary:
This diff fixes a bug with `GenerateCodegenArtifactsTask` that was causing
two generators to be called one after the other (first the JS and then the Java one).
Now they're mutually exclusive.
Changelog:
[Internal] [Changed] - Fix GenerateCodegenArtifactsTask calling two generators with Java enabled
Reviewed By: ShikaSD
Differential Revision: D31169379
fbshipit-source-id: 668d8e440ad6b3f06654f29c5cbc344ef82c4b9c
Summary:
Changelog: [Internal]
Add a path calculation method to TouchTargetHelper to avoid relying on the view hierarchy ourselves and better support virtual touch targets.
Reviewed By: JoshuaGross
Differential Revision: D30993410
fbshipit-source-id: 17577c815413ab0f03bcb6a2140ea1d4c9fd694a
Summary:
This file was placed in the wrong package. I'm moving it.
Changelog:
[Internal] [Changed] - Move `PathUtilsTest.kt` to the correct package
Reviewed By: motiz88
Differential Revision: D31168890
fbshipit-source-id: 59d09b5fd329b776bd2800921889281a116c26ee
Summary:
Adding tests for the `GenerateCodegenSchemaTask`.
Plus fixing a bug where `delete()` was used instead of `deleteRecursively` causing
the files inside the output folder to don't be properly cleaned up.
Changelog:
[Internal] [Changed] - Add unit tests for GenerateCodegenSchemaTask
Reviewed By: ShikaSD
Differential Revision: D31142346
fbshipit-source-id: 69bb026fa2c64d91193a153fdc99c9b5d0a9e1ff
Summary:
This Diff is adding some tests for BuildCodegenCLITask.
Plus I found a bug in how we pass the input/output relative to `codegenDir`
so I'm fixing the properties to use `by lazy{}`.
Moreover the `output` was not correctly annotated with `OutputDirectories`,
fixing it here.
Changelog:
[Internal] [Changed] - Add unit tests for BuildCodegenCLITask
Reviewed By: ShikaSD
Differential Revision: D31109599
fbshipit-source-id: bec75b216e8cef18072179c89c3223ee2bad74e3
Summary:
Since we moved several classes from the older Java plugin to standalone files,
we can now remove the old `CodegenPlugin.java` class and have a single plugin class.
Changelog:
[Internal] [Changed] - Merge `CodegenPlugin` with `ReactAppPlugin`
Reviewed By: ShikaSD
Differential Revision: D31080558
fbshipit-source-id: c4b005f8648ab62a71cb5bee22c06ae5272ecc44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32228
This setups a step on Circle to
test the Android template with the head of `main` of react-native to make
sure we're not actually breaking the Android template.
Changelog:
[General] [Added] - Test the Android template on CircleCI
Reviewed By: ShikaSD
Differential Revision: D31018850
fbshipit-source-id: 6f0abc9e0c22ef61e1aa79b513c70065ace5088e
Summary:
This is the last task from the Codegen Plugin that is exported to
its own Task file and converted to Kotlin.
Changelog:
[Internal] [Changed] - Export `GenerateCodegenArtifactTask` to its own task.
Reviewed By: ShikaSD
Differential Revision: D31054781
fbshipit-source-id: 6787065b497570fb312310e3d9f4120f0629f374
Summary:
The `react-native-codegen` package handles the generation of native code artifacts for modules and components in the new React Native architecture.
This change moves the dependency from being an application-level dependency to being a direct dependency of the `react-native` package.
Changelog:
[General] Move react-native-codegen dependency to react-native root package.json
Reviewed By: yungsters
Differential Revision: D31129619
fbshipit-source-id: dfa0df589c4dbca70dde6db0208485431e304809
Summary:
There was some hardcoded validation logic to verify package.json and gradle.properties update. Running `pod install` before that failed this validation on release branch, so let's move the pod update a bit later in the flow.
This also restrict the version number change check to the specific files for better reliability
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31160139
fbshipit-source-id: d32470d7dfc48c2efab1d2767f3892b33e0b77dd
Summary:
To ensure consistency of RNTester Podfile.lock:
* introduce a script to run `pod install` on the current commit
* have the script check the exact CocoaPods version to use for consistency
* have version bump script run this automatically to keep it up-to-date with the version change
To validate, have this change in `0.66-stable` branch, then try:
```
./scripts/bump-oss-version.js 0.66.0-rc.5
```
This automatically ran `pod install` which produced the Podfile.lock update.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D31132867
fbshipit-source-id: 1c82653ca0cfc5471ed2c5091c09648a7acbab90
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:
to open possibilities for some DX enhancement, the pr introduces `DevSupportManagerFactory` customization. applications could implement a different DevSupportManager in ReactNativeHost.
## Changelog
[Internal] [Added] - Support custom DevSupportManager
Pull Request resolved: https://github.com/facebook/react-native/pull/31841
Test Plan: this pr just introduces some new interfaces and should not break existing functionalities.
Reviewed By: RSNara
Differential Revision: D30878134
Pulled By: yungsters
fbshipit-source-id: ccdf798caa322b07a876da8312b97002da057388
Summary:
Having mavenLocal specified as part of the build is creating confusion as stale artifacts could be used inside the build.
This Diff is attempting to remove. Developers that need it for local development can still re-add it.
Changelog:
[Internal] [Changed] - Remove mavenLocal()
Reviewed By: ShikaSD
Differential Revision: D31057038
fbshipit-source-id: 90335047a0ba5a537ce347e4c1592bfe756d4135
Summary:
When running `scripts/react_native_pods.rb`, the `Pods` directory may not be in the current working directory, for example, when calling [`pod install`](https://guides.cocoapods.org/terminal/commands.html#pod_install) with `--project-directory=ios`. Therefore, `sed` fails and, ultimately, the build fails.
References:
* https://rubydoc.info/gems/cocoapods/Pod%2FInstaller:sandbox
* https://rubydoc.info/gems/cocoapods/Pod/Sandbox#root-instance_method
## Changelog
[iOS] [Fixed] - Fix build error after running `pod install` with `--project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32243
Test Plan:
1. `npx react-native init AwesomeProject --version 0.66.0-rc.3 --skip-install`
2. `cd AwesomeProject`
3. `yarn install`
4. `pod install --project-directory=ios`
This command prints “sed: Pods/RCT-Folly/folly/portability/Time.h: No such file or directory” but still exits with 0.
5. `npx react-native run-ios`
The build fails because of “typedef redefinition with different types” as described in https://github.com/facebook/flipper/issues/834.
6. Apply this patch using `(cd node_modules/react-native && curl https://github.com/kontist/react-native/commit/ec330f756e477e53dde891fe02fd74916d9faef0.patch | patch -p1)`
7. Re-run `pod install --project-directory=ios`
8. Re-run `npx react-native run-ios`
The iOS app should now run successfully.
Reviewed By: sota000
Differential Revision: D31089656
Pulled By: fkgozali
fbshipit-source-id: 431898bed88f68761c7e0e6c79074dc04f43ed23
Summary:
Just a fix of a typo
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D31076782
fbshipit-source-id: 192de92ba080a565acd67e038b370917ea9fcddc
Summary:
Try to reuse currentActivity when the new context from "mReactInstanceDevHelper.getCurrentActivity()" is null to fix "Unable to launch redbox because react activity is not available..."
Changelog:
[Android][Fixed] - Fix currentActivity being null when launching Redbox
Reviewed By: philIip
Differential Revision: D30942434
fbshipit-source-id: faf03390adc545376f3cec223eac5a16bf8233ea
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:
Previous iterations of this diff that were reverted: D30678341 (https://github.com/facebook/react-native/commit/800945982fae92c859f4525e777d016bb61b138b), D30868627 (https://github.com/facebook/react-native/commit/abd0f387cd9b60887d5d8ad986e7cbda7a49ec40).
With the power of selects, we can move the base AppleTVOS flags into the regular
base Apple flags.
While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as
it's driving me insane.
Note - This puts get_visibility_option() on all Apple builds. I believe this is
the right thing to do as everything except macOS static libraries already do it,
and it shouldn't affect binaries.
Changelog: [Internal]
Reviewed By: mzlee, jdonald
Differential Revision: D31024459
fbshipit-source-id: be85296cda3612836c1c74632dc52f6e3f89512e
Summary:
Similarly to the previous diff, this is moving another small part of the codegen
to its own Kotlin separate task. I've used the Gradle idiomatic APIs and added a couple of tests.
Changelog:
[Internal] [Changed] - Export `GenerateCodegenSchemaTask` to its own task.
Reviewed By: ShikaSD
Differential Revision: D31017274
fbshipit-source-id: f0d288a63883e92a9d725eb3bf695a3aa77f9030
Summary:
Changelog: [Internal]
Previously, the `accessibilityHint` value isn't passed through the underlying component so that the voice over system doesn't announce it. This diff fixes that.
Reviewed By: sammy-SC
Differential Revision: D31017275
fbshipit-source-id: 1bf5a5e36fdfed2a199986b82684a40e18325ba1
Summary:
This diff moves `BuildCodegenCLITask` from being inlined to have its own task definition
I've also cleaned up the task body and refactored a bit how we do the CLI invocation.
Changelog:
[Internal] [Changed] - Export `BuildCodegenCLITask` to its own task class
Reviewed By: ShikaSD
Differential Revision: D31016610
fbshipit-source-id: 8407fc2a62ea473daa775196925c1b9b6f4f2f4b
Summary:
Fix the `find-node.sh` call in `react-native-xcode.sh` script
## Related issue
https://github.com/facebook/react-native/issues/32168
## Changelog
[iOS] [Fixed] - Fix for unable to find `find-node.sh` in `react-native-xcode.sh` script
Pull Request resolved: https://github.com/facebook/react-native/pull/32227
Test Plan: • Run an Xcode build which uses the `scripts/react-native-xcode.sh` in the JS Bundle build phase.
Reviewed By: TheSavior
Differential Revision: D31022043
Pulled By: GijsWeterings
fbshipit-source-id: 10aafd595c3a3a87c22f385ca4f61756f67e9b9d
Summary:
Changelog: [Internal]
Small optimization, we can avoid evaluating some properties if `formsStackingContext` is already set, because the end-result is always true.
Reviewed By: sammy-SC
Differential Revision: D30990925
fbshipit-source-id: 08f500aa4b75446a6c644e8821f84dbfccbfebb6
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
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
Use `js_glob()` to guarantee that we're only processing JS related files, not iOS/Android files.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D30982575
fbshipit-source-id: 9a5466fd16f41558f2bfb294aaed2a551ec4334b
Summary:
Previous iteraton of this diff that was reverted is D30678341 (https://github.com/facebook/react-native/commit/800945982fae92c859f4525e777d016bb61b138b).
With the power of selects, we can move the base AppleTVOS flags into the regular
base Apple flags.
While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as
it's driving me insane.
Note - This puts get_visibility_option() on all Apple builds. I believe this is
the right thing to do as everything except macOS static libraries already do it,
and it shouldn't affect binaries.
Changelog: [Internal]
Reviewed By: aniketmathur
Differential Revision: D30868627
fbshipit-source-id: 86441ff40db15dd7cb3ac800d248ce1e074c2773
Summary:
I'm cleaning up the extension to be just ReactExtension and not ReactAppExtension.
Similarly the name of the extension will be just `react` and not `reactApp`.
Changelog:
[Internal] [Changed] - Rename extension to just ReactExtension
Reviewed By: ShikaSD
Differential Revision: D30964793
fbshipit-source-id: 8a4207825d424e133e51495c34c21284c50363ae
Summary:
It is no longer necessary to specify USE_FABRIC=1 when running `pod install` in order to enable Fabric in RNTester.
Changelog: [INTERNAL]
Reviewed By: fkgozali
Differential Revision: D30977549
fbshipit-source-id: fccc3e433041a710b02ddc516cdff07ce7af2409
Summary:
RN codegen generates `lib/` folder in OSS which invalidates caches for macOS build. By only globbing `src/` folder we can avoid these issues.
Changelog:
[Internal] Exclude codegen files built in OSS to fix internal build.
Reviewed By: cortinico, motiz88
Differential Revision: D30959522
fbshipit-source-id: 6371beb3997bc15ed155a7f7871fb80c199367a3
Summary:
Changelog: [Internal] - Port facebook/react-native/commit/cae063798652fcf394ccf3af4645fd971ed76c19 to main
This was something added to 0.65 branch when they were testing that release.
Comments from Lorenzo:
> When you do the local E2E test script a few times there are some files that get cached even if you try to be careful and wipe everything every time
but in particular during 0.64 when we were trying to investigate an iOS build problem we had inconsistency in repro because of caching because of the package name
so we introduced the extra "timestamp" in the name to avoid any "collisions" with existing caches
Reviewed By: fkgozali
Differential Revision: D30954323
fbshipit-source-id: e0196ee1e0f0c6e05a846d93d72e8c4efe175fb5
Summary:
When using monorepo with react-native you need to provide `android/app/build.gradle` following params(`cliPath`):
```
project.ext.react = [
root: "../../../../",
cliPath: "../../../../node_modules/react-native/cli.js",
entryFile: "...",
hermesCommand: "../../../../node_modules/hermes-engine/%OS-BIN%/hermesc"
]
```
With latest react-native `0.64.2` version you will get:
```
* What went wrong:
Execution failed for task ':app:bundleReleaseJsAndAssets'.
> Process 'command 'node'' finished with non-zero exit value 1
```
Debugging this issue showed that providing `cliPath` options ends up building wrong path to cli:
```
> Task :app:bundleReleaseJsAndAssets FAILED
node:internal/modules/cjs/loader:944
throw err;
^
Error: Cannot find module '/node_modules/react-native/cli.js'
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:941:15)
at Function.Module._load (node:internal/modules/cjs/loader:774:27)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
at node:internal/main/run_main_module:17:47 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
```
Changed `react.gradle` for proper File creation for `cliPath` to support this configuration option.
## Changelog
[Android] [Fixed] - Changed `react.gradle` `detectCliPath` function logic for `cliPath` case
Pull Request resolved: https://github.com/facebook/react-native/pull/31839
Test Plan: Run `./gradlew assembleRelease` or `./gradlew assembleDebug`
Reviewed By: yungsters
Differential Revision: D30877674
Pulled By: sshic
fbshipit-source-id: 26b75f8d29bf26b01630dde576b9052d0b94d89e
Summary:
The IDE is complainign as we're using capitalization functions that
are not locale-independent. I'm changing this to use `Locale.ROOT`.
Once we move to Kotlin 1.5 we're going to replace those functions with newer ones.
Changelog:
[Internal] [Changed] - Use Locale.ROOT for capitalization of variant names
Reviewed By: ShikaSD
Differential Revision: D30958992
fbshipit-source-id: 225af4e7e323f143ab75bad106f3bca3db510b22
Summary:
This Diff is merging over all the properties from `CodegenPluginExtension` to
`ReactAppExtension`. Some of the properties were duplicate and generally having two
extensions is creating a lot of confusion for the users (e.g. don't know where to place a
specific property).
Therefore I'm merging the two to have only one. I've also updated the property to use the
Gradle Lazy Configuration API.
Changelog:
[Android] [Changed] - Gradle: Merge CodegenPluginExtension inside ReactAppExtension
Reviewed By: ShikaSD
Differential Revision: D30961343
fbshipit-source-id: 66be3157efef356392c0701aaef2283d058d3161
Summary:
changelog: [internal]
As per title, prevent view from flattening if `accessibilityViewIsModal` is true.
Reviewed By: jimmy623
Differential Revision: D30696223
fbshipit-source-id: 0c6bfc116458d1808f152cb13ba6c941c58f052e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32215
Currently `test_docker` is the biggest offender in terms of time consumed
on CI (~70 minutes). I'm splitting it in smaller steps to let us investigate better
what is going on.
Changelog:
[General] [Changed] - Splits test_docker into smaller steps
Reviewed By: ShikaSD
Differential Revision: D30958906
fbshipit-source-id: 2a80535afe77f98427dd0d38e66c6de3fdf80188
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32214
This Diff updates part of the Gradle plugin to use the Gradle Lazy Api (mostly `Property` classes).
This will defer the time when those value are accessed from configuration to execution phase.
So far I've converted the `Extension` class that should be our primary entry point to the public API.
I haven't converted the tasks as well, therefore we have several `.get()` calls around now.
I'll take care of them once I go over the Tasks file as well.
Moreover, I added some documentation to the Extention properties, as those will show up in the `build.gradle`
autocompletion for our users.
On the API point of view, this is going to be a breaking change for users that are testing the Gradle plugin AND
are on Gradle Kotlin DSL (which I believe are really limited so I don't think is a problem at the moment). Users
relying on `react.gradle` are unaffected.
Changelog:
[Internal] [Changed] - Use Gradle Lazy API
Reviewed By: ShikaSD
Differential Revision: D30902517
fbshipit-source-id: 5af4625e901b82f4b1c65bd631aa4bb9b505b2d0
Summary:
Just fixing a minor typo
Changelog:
[Internal] - Fixing a minor typo in the verify-android-sdk script
Reviewed By: sshic
Differential Revision: D30933339
fbshipit-source-id: b9191089b67dc05813609702dababc3e36a5e6f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32177
This diff merges the `react-native-gradle-plugin` and the `react-codegen/android` into a single plugin.
This will allow us to iterate faster on a single plugin, will create less confusion for our users (`react` vs `reactApp`)
and will help us avoid race conditions when the two plugins are applied together (as we will control the whole lifecycle of it).
Changelog:
[Internal] [Changed] - Merged the two Gradle Plugins
allow-large-files
Reviewed By: ShikaSD
Differential Revision: D30765147
fbshipit-source-id: fcb02a181c7d900daa514107c637d0ee0225976c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32207
This diff is removing some of the unnecessary steps on our CircleCI setup.
Specifically all the `setup_` steps are just checking out the code on different runners and nothing more
therefore I'm cleaning that up. A simple `checkout` should do the job.
I'll do a couple of runs to understand if that is also impacting performances or not.
Changelog:
[Internal] [Changed] - Simplify the CircleCI setup steps
Reviewed By: mdvacca
Differential Revision: D30932949
fbshipit-source-id: 2dec1aaa829416fdf10f4f13089f024a81c14082
Summary:
If I understand the code correctly, component.extendsProps is expected to have more than 1 entry. I encounter a bug where it was an empty and produced an broken Props.h file while testing out in OSS.
```
// Example of the broken file.
class RNTMyNativeViewProps final : {
public:
```
In this diff, it makes it clear that the function has failed so that the codegen fails when the input is wrong.
There is probably an upstream problem that we should warn about, but this diff is just to make sure this method fails loudly.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D30847173
fbshipit-source-id: 34c894f0a7bb81e132b6ed44f51d0f92ed9a5a20
Summary:
Seems like we discard the `extraArgs` for `BundleJsAndAssetsTask` and it doesn't look right.
I'm fixing it here.
Changelog:
[Internal] [Changed] - Do not wipe extraArgs for `BundleJsAndAssetsTask`
Reviewed By: ShikaSD
Differential Revision: D30902743
fbshipit-source-id: 787a7fafab1d3f62d9fdc84d4f55a0cc381bcef8
Summary:
changelog: [internal]
Pulling a function from class since it doesn't use any of the ivars.
Reviewed By: RSNara
Differential Revision: D30766917
fbshipit-source-id: 219d9b7d3bc0b110b659d7188f5e3877c7b480ff
Summary:
When we fail to assign the methodQueue to a NativeModule in the TurboModule system, we say "You must either synthesize the bridge property", when we should say "You must either synthesize the methodQueue property".
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: philIip
Differential Revision: D30909907
fbshipit-source-id: 07dc1060497be3fdd16bdfcf6e80cfed182bc5c7
Summary:
Addresses https://github.com/facebook/react-native/issues/28934
## 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] - When sending OS intents, always set "FLAG_ACTIVITY_NEW_TASK" flag (required by OS).
Pull Request resolved: https://github.com/facebook/react-native/pull/29000
Test Plan:
1. Open RNTester on Android
2. Go to Linking section
3. Try opening "POWER_USAGE_SUMMARY" intent
4. App should open settings, instead of crashing
Reviewed By: cortinico
Differential Revision: D30876645
Pulled By: lunaleaps
fbshipit-source-id: e427bfeadf9fb1ae38bf05bfeafd88e6776d71de
Summary:
Changelog:
* Rename `ENABLE_PACKAGER_CONNECTION` macro to a more appropriate name `RCT_DEV_SETTINGS_ENABLE_PACKAGER_CONNECTION` to reflect this is only used in RCT_DEV_SETTINGS
* Introduce `RCT_PACKAGER_LOADING_FUNCTIONALITY` that can be separate from `RCT_DEV_MENU`, by default, it equals to `RCT_DEV_MENU`
Reviewed By: fkgozali
Differential Revision: D30546025
fbshipit-source-id: f409c02dc1486041d7db5abdbf7eb482520fa171
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32193
This Diff is backporting the change in https://github.com/facebook/react-native/pull/31839/
applied to `react.gradle` also to the React Gradle Plugin. Ideally we would like to two
logic to be in sync as much as possible.
Changelog:
[Internal] [Changed] - Backport the cliPath fix to the Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D30899057
fbshipit-source-id: a28628b36b3dfe565dbdc8d6416c5d25ddf1fe03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32194
This Diff fixes the `test_android` CircleCI that is currently broken due to a faulty `BundleJsAndAssetsTask`
(that's my fault sorry for this).
The CI is failing with a `execCommand == null!` error message. The message is happening as the aformentioned
task is not correctly overriding `exec()` but just declaring a `TaskAction`. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix broken Android CI due to broken `BundleJsAndAssetsTask` override
Reviewed By: GijsWeterings
Differential Revision: D30899742
fbshipit-source-id: a39b01b7d429bd7e87411282e1c22a7606ea22e0
Summary:
Another diff to remove code from `ReactAppExtension` to a Util file and test it.
Changelog:
[Internal] [Changed] - Export and test `detectedHermesCommand` function from `ReactAppExtension`
Reviewed By: feedthejim
Differential Revision: D30866510
fbshipit-source-id: 0023a063793d669ee4b2190679ca7fbd01e9a3fc
Summary:
This diff disables the TurboModuleManager delegate locking by default in the TurboModule system.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30862260
fbshipit-source-id: 917c1e5862c69a753e33813705eead0e97cf5e9a
Summary:
changelog: [internal]
In this diff, we delete default initialised for ShadowViewMutation to prevent accidentally creating empty ShadowViewMutation.
The other initialiser is made private and all of its uses are migrated to designated initialisers. This makes for safer API.
Reviewed By: RSNara
Differential Revision: D30774900
fbshipit-source-id: d2064bf08409850e75e13ad06558b7980a7f5d8d
Summary:
changelog: [internal]
I'm chasing down a crash in LayoutAnimations, it would help me to simulate the memory access which causes the crash to learn where the bad memory is coming from.
Reviewed By: RSNara
Differential Revision: D30776840
fbshipit-source-id: 1e97fac28ba2df37ba3e47ec2c110043c3823e70
Summary:
changelog: [internal]
This looks like a bug where the author did not intend the conversion to boolean. This means that `onlyMutationIsUpdate` was evaluated to true even if more than 1 animation was in the vector.
Reviewed By: RSNara
Differential Revision: D30767172
fbshipit-source-id: 0ef47b65a5d8ef07d774d9e0b358e5642dc0a9ea
Summary:
changelog: [intenal]
The variable is never read, removing it.
Reviewed By: RSNara
Differential Revision: D30767134
fbshipit-source-id: de72740f9dc7ad10d651129404fe4df093e6206d
Summary:
changelog: [internal]
Add a log behind feature flag to learn more about missing component descriptor.
Component descriptor should never be missing, that's a state of program that is impossible as far as I can tell. This logic was introduced in D22216030 (https://github.com/facebook/react-native/commit/6342e6e3f11219391ac3296d41233735af7e6cad) and I think it is just cover the real cause of crashes in LA on iOS.
Reviewed By: RSNara
Differential Revision: D30765947
fbshipit-source-id: 6843384e02529de2f024c59c61ae21b8682ac371
Summary:
First part of the codegen script cleanup effort. Everything that was done in generate-specs.sh is now part of the CocoaPods recipe (e.g. codegen method in `react_native_pods.rb`).
Now that `generate-specs.sh` has been removed, the codegen may still be invoked manually for test purposes like so:
```
cd react-native
# Generate Schema - do this whenever your JS specs change
node packages/react-native-codegen/lib/cli/combine/combine-js-to-schema-cli.js <output_file_schema_json> <javascript_sources_dir>
# Generate native interfaces for iOS (use schema.json generated by previous step)
node scripts/generate-specs-cli.js ios <output_file_schema_json> <output_dir> <library_name>
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30648067
fbshipit-source-id: 29688e0aac5496886657db82becb05bc8da076c9
Summary: Changelog: [Internal] Create FlatList example index for 3 levels of navigation
Reviewed By: charlesbdudley
Differential Revision: D30816721
fbshipit-source-id: a3bdae7f385bab3695a9c2dc6fe3148ebdbd12b4
Summary:
This Diff is adapting the `BundleJsAndAssetsTask` to be a bit more idiomatic. Here the summary of changes.
- Make the task `abstract` to let Gradle properly implement it.
- Make all the annotated filed `public` instead of `internal` as they will be easier to access for Gradle + will show up
correctly in logs/scans
- Update the Task to subclass a `Exec` that is a specificed Task
- Do not reference `project.` inside the Task body as that is breaking the Configuration Caching of Gradle
Changelog:
[Internal] [Changed] - Make the `BundleJsAndAssetsTask` Task more Gradle friendly
Reviewed By: mdvacca
Differential Revision: D30865159
fbshipit-source-id: 74d4c77f6a2b3fac944e7e0b123726e6a423ba1d
Summary:
Ideally a Gradle `Extension` should contain only properties as it's the public facing API of our
Gradle surface. Here I'm movign a couple of functions away from it. Now they're located inside their
own Util file. Moreover I've added tests and documentation to those.
Changelog:
[Internal] [Changed] - Export `detected*` functions fron `ReactAppExtension` to its own file
Reviewed By: mdvacca
Differential Revision: D30865494
fbshipit-source-id: 59925414c0eb427161691950f5b9b6495121da00
Summary:
Another small diff to setup some testing for our Gradle Plugin.
Here I exported a couple of extension functions on `File` to a separate
Utils file + I've added some tests for them.
Changelog:
[Internal] [Added] - Add tests for AndroidConfiguration
Reviewed By: mdvacca
Differential Revision: D30841339
fbshipit-source-id: fcb00d7397d1f3e2b4500e9920508c71f20c76f3
Summary:
This JavaScriptTimerManager interface calls into JavaScript to execute timers. For that reason, I think JavaScriptTimerExecutor is a better name for the interface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D30851912
fbshipit-source-id: de282068d18693fd67331586e66847105ea16531
Summary:
This reverts https://github.com/facebook/react-native/issues/31128 - For the reasons stated in the thread. Files should have the correct endings in the repo (i.e. Windows .bat CRLF). There is no reason to perform additional conversion with attributes and/or an editorconfig. It was originally fixed in https://github.com/facebook/react-native/issues/29792 in August 2020.
⚠️ **EDIT 2021-08-31**
Commits 85249cafe8 and 13107fa3d0 accidentally converted the gradlew.bat files to LF again, resulting in modified files to appear in the working directory:
```
$ git status -s
M gradlew.bat
M packages/react-native-codegen/android/gradlew.bat
M template/android/gradlew.bat
```
The reasons why this is happening are explained in detail in the two PRs linked above.
I've added an additional (new) commit to the PR head branch to fix the line endings in all three `gradlew.bat` files of the repo and rebased it. It should be ready for merge.
CC cortinico
EDIT 2021-09-02
The additional commit was removed again, but the original one remains.
To test the scenario locally run the following commands on a clean `main` branch (currently 455433f481):
```
$ rm gradlew.bat
$ git status -s
D gradlew.bat # Git shows the file as (D)eleted, as expected
$ git checkout gradlew.bat # This should restore the file
$ git status -s
M gradlew.bat # The file still shows up, now as (M)odified with all line endings changed
```
The modified file will remain in the working directory until they are committed, or a different branch is _force_ checked out. `gradlew.bat` files are generated automatically by Gradle (with the correct line endings in the first place). There is no need to special case them and perform line ending conversion using Git and/or editorconfig.
## Changelog
[General] [Fixed] - Line endings in Windows files, Git/EditorConfig related conversions
Pull Request resolved: https://github.com/facebook/react-native/pull/31398
Test Plan: Verify files are stored correctly in the repository (e.g. using the `file` command).
Reviewed By: yungsters
Differential Revision: D30839864
Pulled By: cortinico
fbshipit-source-id: dfc53e8c5d9276d2f9bfd4d4a4e6b44c3143a164
Summary:
Adding an error message when codegen doesn't recognize any modules to help users understand what's going on.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D30624535
fbshipit-source-id: 781f1f874a5b0c16a05191186b81c2d3892da95b
Summary:
I applied the changes requested in this PR: https://github.com/facebook/react-native/pull/29089
We upgraded to RN 0.62.2 on our latest release and started to see again the "Failed to load WebView provider: No WebView installed" (see below for Crashlytics screenshot)
This crash had been fixed by https://github.com/facebook/react-native/pull/24533 but https://github.com/facebook/react-native/pull/26189 (added in 0.62) reverted the fix
Indeed the exception raised in Crashlytics is actually a `AndroidRuntimeException` and `MissingWebViewPackageException` is only part of the message.
For instance, in the screenshot above, the exception message is `android.webkit.WebViewFactory$MissingWebViewPackageException: Failed to load WebView provider: No WebView installed`
Now these crashes are quite tricky to reproduce, so to be on the safe side, I'm filtering out all exceptions containing `WebView` as suggested by thorbenprimke on the original fix.
If my reasoning is correct, it should fix siddhantsoni 's issue as well, since `WebView` is included in `MissingWebViewPackageException`
But following that reasoning, I am not sure https://github.com/facebook/react-native/pull/26189 fixed siddhantsoni 's issue, so siddhantsoni if you could check that this PR also fixes your issue, that would be great!
## Changelog
[Android] [Fixed] - Fix missing WebView provider crash in ForwardingCookieHandler
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/32165
Test Plan:
I created a version of react native with this patch applied
```
"react-native": "almouro/react-native#release/062-2-fix-missing-webview-provider"
```
Before the fix ~0.1% of our users were impacted on Android, no new crashes have occurred after the update.
This is putting back what was already in place and working for us, but making the check wider to catch more errors.
Reviewed By: lunaleaps
Differential Revision: D30847404
Pulled By: sota000
fbshipit-source-id: fe3b5fa2c9ebde5bedd17a9d6394a52ccdbdf0d0
Summary:
Modifies `js1 build buckfiles` to also parse files that depend on `ReactSafeMobileConfig` for MobileConfig references.
That module was introduced in {D30470489}.
This fixes a bug where the MobileConfig reference in `ReactNativeInternalFeatureFlags` is not being correctly defined via Metro Buck.
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D30815779
fbshipit-source-id: 156b0838fe47e7ab42c62258a1401875690813a6
Summary:
changelog: [internal]
Just moving two functions to separate file.
Reviewed By: RSNara
Differential Revision: D30765732
fbshipit-source-id: e85e749c2910f6f38f07e56b23a21fb9f1cbc9b5
Summary:
changelog: [internal]
Prefer `unordered_set` over `vector`. Makes for nicer APIs and has better performance characteristics.
Reviewed By: RSNara
Differential Revision: D30756215
fbshipit-source-id: d259da07f8f0d5837441dc8ba11c00324aac3fa4
Summary:
changelog: [internal]
Maybe invalid keyframe animation shouldn't be queued. This adds a fix behind feature flag to verify if it fixes iOS crashes.
Reviewed By: RSNara
Differential Revision: D30730005
fbshipit-source-id: 8a2bb54c449449a95d14d51a1a78bfaccad61877
Summary:
Another small diff to setup some testing for our Gradle Plugin.
Specifically this one is also setting up a test environment where we would be able to exercies
AGP usages on top of `ProjectBuilder`. This will allow us to verify that an Android project
is configured correctly for a React Native build.
Changelog:
[Internal] [Added] - Add tests for AndroidConfiguration
Reviewed By: GijsWeterings
Differential Revision: D30839600
fbshipit-source-id: 10e3b3c0fcf5979c2a0eaf64320f87ae58093fbd
Summary:
This change migrates fetching locale information from the deprecated Android locale api to the new locale api on sdk version 30+. The old api was deprecated some time ago and should not be used.
https://developer.android.com/reference/android/content/res/Configuration#locale
## Changelog
[Android] [Changed] - Use new Locale API on Android 11 (API 30)+
Pull Request resolved: https://github.com/facebook/react-native/pull/30701
Test Plan:
```js
if (Platform.OS === 'android') {
locale = NativeModules.I18nManager.localeIdentifier; // returns ex. 'EN_us'
}
```
Reviewed By: mdvacca
Differential Revision: D30821396
Pulled By: lunaleaps
fbshipit-source-id: 31622cd9c71c6057ff98ab5245898bc687b5ac60
Summary:
Fixes the issue explained in https://github.com/facebook/react-native/issues/28446
It basically disabled the gflags include before configure can detect the header on the users system.
## Changelog
[iOS] [Fixed] - Fixed inability to build apps when gflags is installed
Pull Request resolved: https://github.com/facebook/react-native/pull/28451
Test Plan: Tested by installing gflags `brew install gflags` and verifying that apps build after.
Reviewed By: javache
Differential Revision: D30345352
Pulled By: sota000
fbshipit-source-id: 04c98d7ddebe6708057407c4b4bf3701434822a3
Summary:
## Context
In bridgeless mode, RCTRootView is actually an instance of RCTSurfaceHostingProxyRootView.
A lot of code that uses RCTRootView uses its RCTEventDispatcher or RCTModuleRegistry properties. Both of properties reach into the bridge, which means these APIs only work in bridge mode.
## Changes
- Give RCTSurfaceHostingProxyRootView access to the bridgeless RCTModuleRegistry, in bridgeless mode.
## Benefits
- This makes the RCTEventDispatcher and RCTModuleRegistry properties of RCTSurfaceHostingProxyRootView work in bridgeless mode. This allows us to eliminate branching in native code that uses these properties. Diffs incoming.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30753829
fbshipit-source-id: 0815f8ae5507686bd5aff20a3abc1843533bb132
Summary:
## Context
RCTModuleRegistry allows NativeModules to require other NativeModules, regardless of if they're using the old or the new system.
## Problems
Currently, the TurboModuleManager owns the RCTModuleRegistry. This results in the following ownership diagram:
{F660246242}
As you can see, for the bridge case, we're maintaining two *different* RCTModuleRegistry objects, both of which maintain a backward reference to the bridge and the TurboModuleManager.
## Changes
If we stop having TurboModuleManager own the RCTModuleRegistry, and just have React Native's initialization layer attach it to NativeModules, then we can simplify the above ownership diagram to this:
{F660246285}
## Benefits
- Less complicated design for RCTModuleRegistry
- RCTModuleRegistry understands the old and the new NativeModule system. So, it makes more sense for RCTModuleRegistry to be owned by the bridge, which also understands the old and the new NativeModule system.
- **Actual Motivation:** This allows us to start exporting RCTModuleRegistry from the bridgeless core, which is safer than leaking the TurboModuleManager from the bridgeless core. Diffs incoming.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30753286
fbshipit-source-id: cf374092b7b939bc177c3c3448424f2fb53033c3
Summary:
changelog: [internal]
Group public, protected and private methods in header and implementation file. Nothing else is changed in this diff.
Reviewed By: RSNara
Differential Revision: D30729103
fbshipit-source-id: 047bfb86794caedddcf6569ffeee224fee811794
Summary:
changelog: [internal]
There was extra bookkeeping associated with lifetime of `LayoutAnimationCallbackWrapper`. We can just copy it into runtimeExecutor lambda to manage its life cycle and delete `jsi::Function` once it was called.
Reviewed By: RSNara
Differential Revision: D30728210
fbshipit-source-id: 6fc60ee83846cb73648f1c09e5aaf1ed04bd0817
Summary:
Fix broken link
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/32169
Reviewed By: yungsters
Differential Revision: D30809096
Pulled By: GijsWeterings
fbshipit-source-id: b600e411c7292ba840e076d68f66cb3043887335
Summary:
This Diff is adding some really simple tests for TaskUtils.
It also adds a couple of utilities to run some sample tests (e.g. mocking the OS version)
that would come handy the more we keep on writing tests and adding functionalities to the Gradle plugin.
Changelog:
[Internal] [Changed] - Added tests for TaskUtils
Reviewed By: mdvacca
Differential Revision: D30809779
fbshipit-source-id: c401cb78e386964e429c6f459c699e6f18f54f11
Summary:
With the power of selects, we can move the base AppleTVOS flags into the regular
base Apple flags.
While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as
it's driving me insane.
Note - This puts get_visibility_option() on all Apple builds. I believe this is
the right thing to do as everything except macOS static libraries already do it,
and it shouldn't affect binaries.
Changelog: [Internal]
Reviewed By: aniketmathur
Differential Revision: D30678341
fbshipit-source-id: be30ba1989b2cadbf8aedd68c4101d346c36da6c
Summary:
Removed the deaultProps in the DrawerLayoutAndroid file and replaced it with a default value in case props are undefined.
## Changelog
[General] [Changed] - Remove defaultProps from the DrawerLayoutAndroid Component.�lunaleaps this is the fix for issue https://github.com/facebook/react-native/issues/31606
Pull Request resolved: https://github.com/facebook/react-native/pull/32162
Test Plan: Ran test suite
Reviewed By: lunaleaps
Differential Revision: D30776242
Pulled By: cortinico
fbshipit-source-id: 51408acd92aecb8d725b0bbf39ddb059924481e5
Summary:
changelog: [internal]
Use set instead of vector. It makes for nicer API to check if the element exists.
Reviewed By: cortinico
Differential Revision: D30728211
fbshipit-source-id: 7b7cc1e94bb82a44b064e2945a753adbbce5dc2c
Summary:
changelog: [internal]
LayoutAnimations only animates changes inside View and Paragraph nodes. This diff extends it to any node that's ViewKind.
Reviewed By: JoshuaGross
Differential Revision: D30603138
fbshipit-source-id: 63ca1e5df420149c4ba66151e97fea419fdfe631
Summary:
the `LogBoxData.addIgnorePatterns` function shows the wrong code to get a item in `Set`. because every item in `set.entries` looks like `[value, value]`, but not `value`.
while the `addIgnorePatterns` function evalutes two itertaions that is not necessary. So I refacted this function.
## 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] - for LogBox checking existingPattern in a wrong way.
[General] [Changed] - addIgnorePatterns runs in one iteration.
[General] [Added] - add a function `getIgnorePatterns` in `LogBoxData.js` for tests or other usecases.
Pull Request resolved: https://github.com/facebook/react-native/pull/31977
Test Plan:
test codes in `LogBoxData-test.js`:
````js
it('adding same pattern multiple times', () => {
expect(LogBoxData.getIgnorePatterns().length).toBe(0);
LogBoxData.addIgnorePatterns(['abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(1);
LogBoxData.addIgnorePatterns([/abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
LogBoxData.addIgnorePatterns(['abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
LogBoxData.addIgnorePatterns([/abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
});
it('adding duplicated patterns', () => {
expect(LogBoxData.getIgnorePatterns().length).toBe(0);
LogBoxData.addIgnorePatterns(['abc', /ab/, /abc/, /abc/, 'abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(3);
LogBoxData.addIgnorePatterns([/ab/, /abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(3);
});
````
and they have passed
Reviewed By: rickhanlonii
Differential Revision: D30675522
Pulled By: yungsters
fbshipit-source-id: 4a05e0f04a41d06cac416219f1e8e540bf0eea02
Summary:
changelog: [internal]
No need for ivar here.
Reviewed By: sshic
Differential Revision: D30726786
fbshipit-source-id: ba8f71c9f182c1afbfd5118adc15a098d9f56027
Summary:
RCTRootView exposes the RCTEventDispatcher directly via the .eventDispatcher property. So, there's no need to access the bridge to access the eventDispatcher.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30753792
fbshipit-source-id: 5820d65c061e9b88382692dfc2791ed4a4841c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32139
Currently RN Gradle Plugin is using `kotlin-dsl` that comes will all sorts of side effects on Gradle plugins projects.
Specifically we can't specify the Kotlin version, plus it makes harder to include Java source code in a single
project.
I'm removing it in favor of Kotlin-JVM plugin. I've adapted the code to use the correct APIs.
Specifically most of the lambdas are changing the scope of the parameter (from `this` to `it`) so I had to adapt
those as well.
Changelog:
[Internal] [Changed] - Do not use `kotlin-dsl` for `react-native-gradle-plugin`
Reviewed By: yungsters
Differential Revision: D30726977
fbshipit-source-id: b10635eefdbbb496c4adddd418db6b0ab613ab59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32140
This diff is setting up the Gradle wrapper inside packages/react-native-gradle-plugin/.
Currently the `./gradlew` file is missing so it's not possible to `cd` inside the project and build it from
there (also opening that folder inside the IDE will trigger the creation of the files I added here).
This diff is fixing. The files have been generated with the command:
```
gw -p packages/react-native-gradle-plugin wrapper --gradle-version 7.0.2 --distribution-type=all
```
Changelog:
[Internal] [Added] - Setup Gradle Wrapper inside packages/react-native-gradle-plugin/
Reviewed By: yungsters
Differential Revision: D30730145
fbshipit-source-id: a0bd6be0ac062e089b2b90a55b47987c0f4b6644
Summary:
Changelog:
[Category][Internal]
This diff reverts the [Androids-specific heap size overrides](github.com/facebook/react-native/commit/63d20d3b1ef35cb4398d63d62f631f7f5d2935c7#diff-4c59ddca85e294a90a0e1bd15ed323ff4e130911d9642680dde44aacbcd7d32c) after
[Hermes has changed its default max heap size to 3GiB](https://github.com/facebook/hermes/commit/5f2b47d0be6281fd2605d24efc0b43af42b4033d).
You can read about more context there.
Reviewed By: yungsters
Differential Revision: D30726067
fbshipit-source-id: 1bcc93fdf4da817f3b3d60bd09c6a5a64166eb7e
Summary:
RCTBaseViewController uses RCTRootView.bridge to call RCTViewEventEmitter.emit.
## Changes
- RCTEventDispatcher now exposes a method to dispatch RCTViewEventEmitter events.
- RCTRootView (for paper), and RCTSurfaceHostingProxyRootView (for fabric and bridgeless mode) now exports the RCTEventDispatcher by grabbing it from the bridge
- RCTBaseViewController now uses the event dispatcher exported from RCTRootView to dispatch the RCTViewEventEmitter event.
## Benefits
- RCTBaseViewController no longer uses the bridge to dispatch RCTViewEventEmitter events
- In the future, we'll make RCTSurfaceHostingProxyRootView work with bridgeless mode, which'll allow us to remove the bridge/bridgeless fork in RCTBaseViewController.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434884
fbshipit-source-id: d961a56ac2abc08a661f8fe7c37926f219b731d0
Summary:
RCTRootVeiw exports the bridge. One reason why is to allow users of RCTRootView users to access NativeModules.
## Changes
- RCTBridge now exports the RCTModuleRegistry
- RCTRootView now exports the RCTModuleRegistry exported by the bridge
- Users of RCTRootView use the RCTModuleRegistry exported by RCTRootView to access NativeModules
## Benefits
Down the line, we'll change how RCTRootView gets the RCTModuleRegistry (i.e: it won't use the bridge in bridgeless mode).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434886
fbshipit-source-id: 875fce24d2fd9ee6350f128c8612e613e61e390e
Summary:
Users of RCTRootView access the bridge from it, to see if it's nil or not.
## Changes
- Instead of exposing the bridge from RCTRootView for this use-case, we're now exposing a property on RCTRootView: hasBridge. This will be false in bridgeless mode, and true in bridge mode.
## Benefits
This takes us one step closer towards removing RCTBridge leakage through RCTRootView.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434885
fbshipit-source-id: 02f50e16831852b5049a626e8b08d59a90b2059a
Summary:
Fixes https://github.com/facebook/react-native/issues/23364
The current logic using `_isTouching` does not work because `_handleTouchCancel` is always called before scroll events begin. This means `_isTouching` is always false. To fix it I moved the logic to `_handleScrollBeginDrag` which is only called once when scroll drag beings. This accomplishes the expected behavior and is better than keeping it in onScroll where it would be called for each scroll event.
## Changelog
[Android] [Fixed] - Fix keyboardDismissMode="on-drag" on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31943
Test Plan: Tested in an app that on-drag does not work before and works after this patch.
Reviewed By: sshic
Differential Revision: D30674276
Pulled By: yungsters
fbshipit-source-id: aa0bd605809fa01518f70fbf323c06e32c76ed1d
Summary:
Right now, `react-native` on Android passes in an explicit Hermes config when initializes Hermes. The upcoming version of Hermes shipping with React Native 0.66 will handle this default config itself, so there's no need to override it from Android anymore.
Changelog:
[Android][Changed] - Hermes initialization will no longer need an explicit configuration.
Pull Request resolved: https://github.com/facebook/react-native/pull/31900
Test Plan: I compiled and ran a React Native app using the Android build, making sure to build `ReactAndroid` from source. I confirmed that the config was actually being applied by testing how much memory an application could eat before being killed.
Reviewed By: sshic
Differential Revision: D30675510
Pulled By: yungsters
fbshipit-source-id: 5eef056893b72ddd433ee808eb08d0eb56f22f72
Summary:
Use the same technique as other flipper transitive deps to make sure it is excluded from release builds.
## Changelog
[iOS][Fixed] - Exclude OpenSSL-Universal flipper dependency from release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31938
Test Plan: Tested in an app that it still builds and works.
Reviewed By: mweststrate
Differential Revision: D30674216
Pulled By: yungsters
fbshipit-source-id: f2ab5154c80036e6df90d1a98882cc4b85734485
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32137
Bumping the minor version of Kotlin. I don't expect any major breakage.
Changelog:
[Android] [Changed] - Bumped Kotlin to 1.4.32
Reviewed By: ShikaSD
Differential Revision: D30698315
fbshipit-source-id: e1de6251c1c17c490700298540dea5b48d034e3c
Summary:
Changelog:
[Internal][Changed] - revert to class component of ScrollViewStickyHeader. There is a redbox error during unmount in the functional version
Reviewed By: lunaleaps
Differential Revision: D30705974
fbshipit-source-id: b564c522b0026db0b334cc834a80bbbe9cd261e2
Summary:
Changelog: [internal]
Remove RuntimeSchedulerManager on Android in favor of different way to initialise RuntimeScheduler.
Reviewed By: ShikaSD
Differential Revision: D30486975
fbshipit-source-id: 9fe38de12be452bd9d2c92bb54cf5933ce7555b5
Summary:
changelog: [internal]
Don't use C++ 17 features in RuntimeScheduler module as it needs to be imported into C++14 module.
Also removes redundant dependency.
Reviewed By: ShikaSD
Differential Revision: D30485642
fbshipit-source-id: 0a20f85c596eebe193affc815c8ca851fc72e46d
Summary:
changelog: [internal]
`_rootTag` is never assigned to and never read, let's remove it.
Reviewed By: RSNara
Differential Revision: D30667860
fbshipit-source-id: f4b89ebe6b6d26559188b0e19682f5ac765d40b6
Summary:
changelog: [internal]
Use surfaceId type instead of raw int type in PropsParserContext
Reviewed By: RSNara
Differential Revision: D30667540
fbshipit-source-id: 2bf890b892851e785318e3566692ac72ec782b91
Summary:
Displays views from the surface mounting manager after we hit a crash during mounting.
This change should help with debugging mounting crashes (e.g. when view is added before removal)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D30681339
fbshipit-source-id: f83cecaf8e418a2fa5aa0713513c51bb1be77013
Summary:
Changelog: [Internal[Fixed] - Revert, yarn workspaces only used in private packages. Copy dependencies over from repo-config instead
Original commit changeset: 1dd2adc6a036
Reviewed By: fkgozali
Differential Revision: D30599065
fbshipit-source-id: 0efffaaf38bc23bac339e6e1d917736243e1750e
Summary:
Changes `react-native/normalize-color` to be useable from Node.js by making the following changes:
1. Rename `base.js` to `index.js` so importing is more convenient.
2. Move Flow definitions into a seprate library definition flow so `index.js` can be consumed directly.
I also made a few improvements to the actual implementation:
1. Avoid allocating `matchers` for non-strings.
2. Avoid allocating an object of all the color keywords. This will reduce memory usage (in exchange for slightly larger compiled bytecode).
Changelog:
[General][Changed] - react-native/normalize-color now supports Node.js
Reviewed By: lunaleaps
Differential Revision: D30595908
fbshipit-source-id: e6279e9ff815d8d1f489811187deabfdf53b8fbf
Summary:
Context: there are multiple issues currently exposed by Xcode 12.5 and/or M1 machine + Flipper. To unblock the new 0.66 release, let's add this workaround in the official react_native_pods.rb recipe and make RNTester and new app Podfile's call it directly.
Changelog: [iOS][Fixed] Added workaround for Xcode 12.5 / M1 machines build issues
Reviewed By: lunaleaps
Differential Revision: D30691291
fbshipit-source-id: 8b24cc60da3d620dbc90f95c77f2345e18c28212
Summary:
The original $ENTRY_FILE check was added in https://github.com/facebook/react-native/pull/29012 to help catch misconfiguration for the entry JS file. That turned out breaking some RNTester builds/tests, so https://github.com/facebook/react-native/pull/29263 was added to accommodate the fact that RNTester .xcodeproj file has its own directory hierarchy.
The 2nd PR had multiple issues:
* It is incorrect to assume that the $ENTRY_FILE always exists in the parent dir of the .xcodeproj location. This caused an issue in RC 0.66: https://github.com/react-native-community/releases/issues/249#issue-983474535
* RNTester has since moved to packages/rn-tester/ (from RNTester/), hence breaking that assumption
It turns out RNTester .xcodeproj has incorrectly misconfigured this JS bundling step (not sure since when). The original script invocation passed in the correct path for `RNTesterApp.ios.js`, but as an arg to the `react-native-xcode.sh` instead of by setting `ENTRY_FILE` env var.
So this diff does 2 things:
* Undid https://github.com/facebook/react-native/pull/29263
* Fix RNTester JS bundling invocation to set the ENTRY_FILE correctly
{F659123377}
Changelog: [iOS][Fixed] Unbreak $ENTRY_FILE handling for JS bundling
Reviewed By: lunaleaps
Differential Revision: D30690900
fbshipit-source-id: 7c5802b3eac56c0456edcd4b7478bfa4af48fc27
Summary:
Create a ScreenshotManager.podspec (codegen recipe included) and add ScreenshotManager Pod to the Podfile.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D30623054
fbshipit-source-id: be20880a53ba8a08f8b42b8d81c868c8a21960e1
Summary:
The version of this package needs to be bumped for me to release the changes from https://github.com/facebook/react-native/issues/28637 to NPM.
## Changelog
[Internal] [Added] - Bump react-native-community/eslint-config version
Pull Request resolved: https://github.com/facebook/react-native/pull/32117
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D30663708
Pulled By: yungsters
fbshipit-source-id: f433c324f12663d76e55c9395630cd642955b25e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32124
This Diff adds `template/android/` as part of the top level build as an included
build. This means that the Android template will be loaded inside Android studio and it
will be easier to invoke tasks directly there.
I'm also bumping Gradle to 7.0.2 for the template.
Please note that the template relies on the `template/node_modules` folder to
work correctly, as the Gradle build is loading a file from there.
Therefore I've added a check to verify that we import the build only if `node_modules`
is available.
Changelog:
[Internal] [Changed] - Load template/android/ inside the build.
Reviewed By: ShikaSD
Differential Revision: D30672845
fbshipit-source-id: 7253296b54e1fde7448e0e170d59b244ed9ec8fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32073
This Diff bumps the version of Gradle used to build the project to
7.0.2. Ideally we could bump to 7.2.x directly, but I'll do one minor version
at a time to exclude potential build problems.
This diff is addressing all the extra build warnings that got raised by the new version.
Changelog:
[Android][Changed] - Bumped Gradle project version to 7.0.2
Reviewed By: ShikaSD
Differential Revision: D30486612
fbshipit-source-id: 70e0f7d18e547013ca7b1d12f8dd64a633df5870
Summary:
When running native builds, we experience a lot of
bad file descriptor warnings. This diff is suppressing the issue on local builds (on Mac).
Changelog:
[Internal] [Changed] - Suppressed bad file descriptor on native builds
Reviewed By: ShikaSD
Differential Revision: D30487098
fbshipit-source-id: 8199fb8f2f18d19543d2861f1f2f852fff6ae73b
Summary:
The codegen script now takes parameters for any necessary configuration. Now, there are three *required* parameters: JS_SRCS_DIR, LIBRARY_NAME, and OUTPUT_DIR.
By default, all modules and components output will be copied to the OUTPUT_DIR under a single LIBRARY_NAME.
If a fourth argument is provided, this COMPONENT_LIBRARY_NAME will be used for the component library name.
If a fifth argument is provided, this COMPONENT_OUTPUT_DIR will be used as the output directory for the component library.
These last two arguments are used to build the core FBReactNativeSpec modules and rncore components libraries. Eventually, all module and component output will be part of a single library, but for the time being we need to keep these apart for the core modules and components.
The script will output usage instructions if no argument is provided:
```
./scripts/generate-specs.sh
NAME
./scripts/generate-specs.sh -- generate specs
SYNOPSIS
./scripts/generate-specs.sh javascript_sources_directory specs_library_name output_directory
./scripts/generate-specs.sh javascript_sources_directory specs_library_name output_directory component_library_name [component_output_directory]
DESCRIPTION
In the first synopsis form, this script collects native module and native component JavaScript spec definitions in javascript_sources_directory, then uses react-native-codegen to generate the native interface code into a library named specs_library_name, which is copied to the destination output_directory.
In the second synopsis form, the component_library_name will be used as the name of the component native interface code library. If provided, the component output will be copied to the component_output_directory, otherwise it will be copied to the output_directory.
```
With these changes, `codegen.js` became redundant and has been removed.
Changelog:
[Internal] - Codegen script interface changes.
Reviewed By: fkgozali
Differential Revision: D30626294
fbshipit-source-id: 475c29242497db5f93213aa64ca9b7c480140d55
Summary:
Pass nativeTimestamp into PressabilityPerformanceEvent as a way to uniquely identify events.
Changelog: [Internal]
Differential Revision: D30648544
fbshipit-source-id: 7cb0146f6ff1655f1312e5094535e59268fb2a22
Summary:
While investigating an issue hit on a recent sync of [react-native-windows](https://github.com/microsoft/react-native-windows) I noticed that https://github.com/facebook/react-native/commit/e68cf7cee9d36271a1d3899fecff817304bb8bdc appears to have accidently inverted the logic to avoid checking native components.
`!UIManager.getViewManagerConfig(componentName)`
become
`UIManager.hasViewManagerConfig(componentName)`
losing the !
Also adding a check in PaperUIManager's getViewManagerConfig to avoid trying to call a sync method when using Chrome Debugging.
## Changelog
[Internal] [Fixed] - Restored the previous logic of deprecatedPropType
Pull Request resolved: https://github.com/facebook/react-native/pull/31164
Test Plan:
Change tested and being submitted in react-native-windows:
https://github.com/microsoft/react-native-windows/pull/7397
Reviewed By: hramos
Differential Revision: D30624302
Pulled By: fkgozali
fbshipit-source-id: 0f26e750283a1fa5eb5f44ecd2cf90617b6d931f
Summary:
In monorepo environment, prettier-plugin in some editor load from nearest `node_modules`. Older version of eslint-config-react-native-community includes prettier v1 in their dependencies. It cause conflict of code style inside the monorepo.
## 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
-->
[Internal] [Fixed] - move prettier to peerDependencies in eslint-config-react-native-community
Pull Request resolved: https://github.com/facebook/react-native/pull/28637
Test Plan: I think it would be good with no plan to test.
Reviewed By: yungsters
Differential Revision: D30648134
Pulled By: charlesbdudley
fbshipit-source-id: 6c01226d6e4cc37ddbc86be260563deb093758d0
Summary:
While not strictly necessary for rn-demo-app at this point, we do need to provide the `getModuleInstanceFromClass:` implementation to simplify the TurboModule migration process later on.
Also, removed some issues in the Xcode project that must have been introduced during a recent rebase (duplicate Embed Pods build phases).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30618992
fbshipit-source-id: a9b496cfa0cd34fca6389ddf829613aa13ea409d
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
Implements the calculation of measurement and position of Text attachments in Android
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30586616
fbshipit-source-id: e9ecc002f03477e3465d746855e1dff2e5f0b321
Summary:
Following recent metro bumps, the lockfile got a bit dirty so I cleaned it
Changelog:
[Internal] [Fixed] - Bump metro / cleaned lockfile to 0.66.2
Pull Request resolved: https://github.com/facebook/react-native/pull/31885
Reviewed By: ShikaSD
Differential Revision: D29814753
Pulled By: sshic
fbshipit-source-id: 462bbcb0304b051800bb7a9a79bdb317fe3f3e87
Summary:
Android TextView's default for breakStrategy is BREAK_STRATEGY_HIGH_QUALITY (https://developer.android.com/reference/android/widget/TextView#setBreakStrategy(int))
RN docs also states that highQuality is default.
However, on Fabric, the default is 'simple'. This diff fixes the default to be 'highQuality'
Changelog:
[Android][Fixed] - Set textBreakStrategy default to be 'highQuality'
Reviewed By: JoshuaGross
Differential Revision: D30597085
fbshipit-source-id: 3bd7531afdaf980b342cc461dd449c3d3df12cb0
Summary:
Changelog:
[ios][added] - introduce MockSurfaceHandler
following the recommendation in https://fb.workplace.com/groups/474291069286180/posts/6540719469309946
in order to unit test classes that use SurfaceHandler, we need to be able to mock it somehow - since the class is final we aren't able to do that. in this diff, we add the mock class.
Reviewed By: sammy-SC
Differential Revision: D30578927
fbshipit-source-id: 9b39b03ad0b55cecd9b482f9cce9630d7e7d5bda
Summary:
Changelog:
[internal]
following the recommendation in https://fb.workplace.com/groups/474291069286180/posts/6540719469309946
in order to unit test classes that use SurfaceHandler, we need to be able to mock it somehow - since the class is final we aren't able to do that. in this diff, we convert the function that we need to stub / listen to to a virtual function so we can mock it.
the alternative is to keep this class final, and create another abstract interface that this will extend from. however, this class is quite large and that would have a lot more boilerplate and updation of callsites, so this simpler approach seems better.
Reviewed By: sammy-SC
Differential Revision: D30578928
fbshipit-source-id: 4a63396f049c44753986d15f1ac64332b2a8393a
Summary: Changelog: [Internal][Fixed] - Keep repo-config as a workspace for bumping oss release version. Fixes CI jobs not having tooling dependencies
Reviewed By: yungsters
Differential Revision: D30595543
fbshipit-source-id: 1dd2adc6a0363202efb5314b7e8eb44618b50327
Summary:
Expose android_hyphenationFrequency in Fabric as part of ParagraphAttributes
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30583215
fbshipit-source-id: f4e9e9d6ea8efcfc10db29e1fbd651462f442837
Summary:
Currently, the build breaks if we move `react-native-codegen` from the template's dependencies to root. This is due to `scripts/generate-specs-cli.js` using the one installed under `node_modules` instead of the local one.
## 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
-->
[Internal] [Fixed] - `scripts/generate-specs-cli.js` should prefer the local `react-native-codegen` package
Pull Request resolved: https://github.com/facebook/react-native/pull/32096
Test Plan:
1. Make the following changes
```diff
diff --git a/package.json b/package.json
index 847c726a69b..78da8232988 100644
--- a/package.json
+++ b/package.json
@@ -107,6 +107,7 @@
"promise": "^8.0.3",
"prop-types": "^15.7.2",
"react-devtools-core": "^4.13.0",
+ "react-native-codegen": "^0.0.7",
"react-refresh": "^0.4.0",
"regenerator-runtime": "^0.13.2",
"scheduler": "^0.20.2",
diff --git a/template/package.json b/template/package.json
index 715614112ac..5e0762b1b25 100644
--- a/template/package.json
+++ b/template/package.json
@@ -21,7 +21,6 @@
"eslint": "7.14.0",
"jest": "^26.6.3",
"metro-react-native-babel-preset": "^0.66.2",
- "react-native-codegen": "^0.0.7",
"react-test-renderer": "17.0.2"
},
"jest": {
```
2. Run `scripts/test-manual-e2e.sh`
## Expected Behavior
Task `:ReactAndroid:buildReactNdkLib` succeeds.
## Actual Behavior
```
> Task :ReactAndroid:buildReactNdkLib FAILED
make: Entering directory '~/Source/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
make: Leaving directory '~/Source/react-native/ReactAndroid/src/main/jni/react/jni'
~/Library/Android/sdk/ndk/21.4.7075529/build/core/build-binary.mk:651: Android NDK: Module react_codegen_rncore depends on undefined modules: react_render_components_view
~/Library/Android/sdk/ndk/21.4.7075529/build/core/build-binary.mk:664: *** Android NDK: Note that old versions of ndk-build silently ignored this error case. If your project worked on those versions, the missing libraries were not needed and you can remove those dependencies from the module to fix your build. Alternatively, set APP_ALLOW_MISSING_DEPS=true to allow missing dependencies. . Stop.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':ReactAndroid:buildReactNdkLib'.
> Process 'command '~/Library/Android/sdk/ndk/21.4.7075529/ndk-build'' finished with non-zero exit value 2
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.9/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 19s
20 actionable tasks: 20 executed
Couldn't generate artifacts
```
Reviewed By: ShikaSD
Differential Revision: D30581194
Pulled By: hramos
fbshipit-source-id: 3f7a707b33377042502e50887856ff5641fdd52c
Summary:
hyphenationStrategy must be one of one of Layout#HYPHENATION_FREQUENCY_NONE, Layout#HYPHENATION_FREQUENCY_NORMAL, Layout#HYPHENATION_FREQUENCY_FULL: (https://developer.android.com/reference/android/widget/TextView#setHyphenationFrequency(int))
Thus "high" and "balanced" are not only redundant, but actually don't do what the value indicates - Layout#BREAK_STRATEGY_BALANCED (constant value: 2) and Layout#BREAK_STRATEGY_HIGH_QUALITY (constant value: 1) are only meant to be used for android:breakStrategy
Changelog:
[Android][Changed] - Remove `"high"` and `"balanced"` as values for `android_hyphenationFrequency` on `Text`
Reviewed By: JoshuaGross
Differential Revision: D30531096
fbshipit-source-id: 1a0b6e733bb21ce6b2f104a2025a79c16de3cfea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32095
Found by running `yarn run prettier` and including relevant files
Changelog:
[Internal] Fix formatting of `global.js`
Reviewed By: cortinico
Differential Revision: D30573273
fbshipit-source-id: 94854d3d3178533ad8a6323006eaca279a931fa7
Summary:
This diff is hooking up cxx error with redbox. Before this diff, cxx errors were only shown in log and there was no visible user feedback.
Changelog:
[Android] [Added] - Show Redbox for C++ errors.
Reviewed By: JoshuaGross
Differential Revision: D30421355
fbshipit-source-id: ad473337ba301feb08ba31ee8d82ebaa771ecaeb
Summary:
Changelog: [iOS] [Fixed]
TextTransform is applied when constructing NSAttributedString from C++ AttributedString in Fabric.
Reviewed By: sammy-SC
Differential Revision: D30515821
fbshipit-source-id: 8a824ff89919832f79ace693dfe3cf7ed35c3beb
Summary:
Changelog: [Internal]
This diff
- add `queueMicrotask` to eslint and metro so it's globally available.
- add `queueMicrotask` to the global libdef of react native so the type
is available to `global.queueMicrotask` (which is common) as well.
Reviewed By: yungsters
Differential Revision: D30158144
fbshipit-source-id: 00a62193b838745c91179ff1e983636200560690
Summary:
Changelog: [Internal]
This diff add types to some of the common globals so uses of
them through `global` are now typed.
All the globals are marked as read-only for their intented uses.
However, some of them do have write cites (mostly are in tests to
deliberately set up a special test environment). Those write cites
are considered as "necessary evil" and annotated as `FlowFixMe`.
Reviewed By: yungsters
Differential Revision: D30158145
fbshipit-source-id: 93a99063361a4b7a1e33d9fc97a661be30a4d8f9
Summary:
This diff refactors the Image component in order to log the component hierarchy stacktraces for images rendering non-fb sources
Changelog: [Internal] internal
Reviewed By: fkgozali
Differential Revision: D30504483
fbshipit-source-id: 1e41a67d5b9643730360bce7e787ee3427d931e8
Summary:
Currently there isn't any way to test if the Accessibility Display Options or the event listeners for them were working properly within RNTester. It turns out that because of changes to the accessibility API Apple made when they added Smart Invert AccessibilityInfo.isInvertColorsEnabled() and the associated event listener are working incorrectly. You can see this if you take a look at how RNTester (with this PR incorporated) responds to toggling Invert Colors. I've submitted a bug report to Apple, but this might have been caught earlier if this had been implemented.
## Changelog
[General] [Added] - Adding Accessibility Display Options Enabled to RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/29231
Test Plan:
1. Build iOS app
2. Navigate to the Accessibility page
3. Switch over to settings and change any of the settings at
- Settings>Accessibility>Display and Text Size>Bold Text
- Settings>Accessibility>Display and Text Size>Color Filters>Grayscale
- Settings>Accessibility>Display and Text Size>Smart Invert (or Classic Invert)
- Settings>Accessibility>Motion>Reduce Motion
- Settings>Accessibility>VoiceOver>VoiceOver
4. Switch back to the app and see the results
Modified it a bit to only show relevant statuses for the Platform
| {F656951547} | {F656951643} |
Reviewed By: TheSavior
Differential Revision: D29531642
Pulled By: lunaleaps
fbshipit-source-id: f54fb3216ef663428c23b613f0a3b10b01d7f24d
Summary:
LLD, our new iOS linker, is an ongoing effort to migrate our old outdated ld64 linker. As part of our effort to rollout LLD to all apps, we are making sure LLD reaches parity with ld64.
Due to Identical Code Folding (ICF), LLD and ld64 handles strings differently. LLD treats each string as a separate object in memory even if the values of the strings are the same. ld64 happens to aggregate these values across files. This behavior creates a subtle difference on our codebase when we start comparing by value or by reference.
`char * ` fields from `RawPropsKey.h` are using `==` which compares by its address. Here, we cast the buffer to a string to make the comparison, while avoiding the cast if one happens to be null.
Changelog: [Internal]
Reviewed By: int3, JoshuaGross
Differential Revision: D30444176
fbshipit-source-id: 74216926803adbece05206ddd8478cc3c8e6812e
Summary:
Closes issue https://github.com/facebook/react-native/issues/31605.
This is part of a bigger issue that plans to remove defaultProps from class components in order to provide a smoother transition to functional components.
## Changelog
[General] [Changed] - Remove defaultProps from the DatePickerIOS Component.
[General] [Test] - Added snapshot test for the new component
Pull Request resolved: https://github.com/facebook/react-native/pull/32064
Test Plan: Compiled the rn-tester folder to check if the behavior is consistent with the previous versions.
Reviewed By: lunaleaps
Differential Revision: D30492515
Pulled By: yungsters
fbshipit-source-id: ed2c5f3211742d528ff3f8e406a53cd7ea43d7e7
Summary:
https://github.com/facebook/react-native/commit/8a62583f794875e6dc5d1e4a24889b3b702d9f86 did some renaming inside of the react-native/polyfills project, with the jest preset updated to use the new name. The new package for polyfills has not yet been published, so the jest preset in the main branch will be looking for the new name, while the old name is provided by the currently published react-native/polyfills@1.0.0. This is not hit inside the repo, since the dependency is linked instead of using the published one.
Bump react-native/polyfills to 2.0 (breaking change), in preparation for publish.
## Changelog
[Internal][Fixed] - Bump react-native/polyfills version
Pull Request resolved: https://github.com/facebook/react-native/pull/32074
Reviewed By: lunaleaps, cortinico
Differential Revision: D30498104
Pulled By: yungsters
fbshipit-source-id: 92dcb159d76bd74cd93cfa09e2155c9c1b2c0a86
Summary:
Changelog:
Add UIAccessibilityTraitUpdatesFrequently when the AccessibilityRole is set to progressBar. This trait tells the accessibility system where content may change with every percentage point, but without annoying the user with constant announcements.
Reviewed By: ikenwoo
Differential Revision: D30510587
fbshipit-source-id: e75690a2a56ce42476dc999383cf58c0811fcbdf
Summary:
I'm not sure if we'll ever need to do more than this (probably!) but I want to have a specific option for Activity-less usage, so
that our logic in ReactInstanceManager and elsewhere is more clear. I want to be able to confidently assert that the Activity is present
and correct, or never present, depending on if this `requireActivity` flag is set; instead of adding else statements that imply "well, the Activity should be here, hope everything is okay" which feels hacky.
Doesn't change much for now, but it's an additional constraint in the RN Android codebase that we need to explicitly embed in code so that
we can point to it, and so that the logic is more clear.
Changelog: [Internal]
Reviewed By: javache, motiz88
Differential Revision: D30504616
fbshipit-source-id: d2abdb7c4765a16113c9517406cdbb8cf42822ff
Summary:
This PR fixes https://github.com/facebook/react-native/issues/30717, a bug in `<Text adjustsFontSizeToFit={true}>` implementation that prevents it from adjusting text size dynamically on Android.
The way `adjustsFontSizeToFit` was implemented in https://github.com/facebook/react-native/issues/26389 (and the design of ReactTextShadowNode) implies that Yoga will call `onMeasure` on every size change of a `<Text>` component, which is actually not the case (Yoga can cache the results of the measures, call the function multiple times or do not call at all inferring the size from the size constraints). The implementation of `adjustsFontSizeToFit` computes the adjusted string inside the measure function and then eventually passes that to the view layer where it's being rendered.
The proper fix of this issue requires the full redesign of the measure and rendering pipelines and separating them, and that... would be too invasive. And, I believe, this issue is already fixed in Fabric where this part is already designed this way.
Instead, this diff implements a small workaround: if `adjustsFontSizeToFit` is enabled, we manually dirty the Yoga node and mark the shadow node updated to force remeasuring.
## Changelog
[Android] [Fixed] - Fixed dynamic behavior of <Text adjustsFontSizeToFit={true}> on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31538
Test Plan: https://user-images.githubusercontent.com/22032/118508162-8c79cc80-b6f4-11eb-853f-a1a09f82935f.mov
Reviewed By: mdvacca
Differential Revision: D28631465
Pulled By: yungsters
fbshipit-source-id: 7db1d22e2a5a464c7bf941d1d3df8e3fe8df66a2
Summary:
This diff is part of a bigger effort to remove the RTTI flags.
To do so we need to remove occurrences of `dynamic_cast` and other functions that rely on runtime
type informations.
Changelog:
[Internal][Changed] - Removed extra asserts relying on dynamic_cast
Reviewed By: JoshuaGross
Differential Revision: D30483554
fbshipit-source-id: 92b31281841a92c7b43e918938248431265dd654
Summary:
`window` exists in the React Native runtime, but not inside the test environment. Many libraries use `typeof window === 'undefined'` to check if code is running in SSR. Because of the difference in the real environment and test environment, tests can behave different than the real app, which is an unwanted behavior.
## Background
I'm using https://github.com/tannerlinsley/react-query in my React Native Project, which works really well. When writing tests, they wouldn't work: jest started and then seemingly did nothing. While debugging I noticed the render was stuck in an infinite loop. Then I noticed the following line inside `react-query`:
```js
const isServer = typeof window === 'undefined'
```
I didn't know that the React Native runtime has a global `window`, and thought it's a bug inside react-query. But it does have a `window`, which is not defined inside the test environment.
The infinite loop was caused by react-query thinking it is running on the server, which doesn't fetch any data. If the react-query hook mounts, it re-executes because then it should be mounted inside the client. But `isServer` was still `true`. This repeats forever.
## Changelog
[General] [Fixed] - Fix `window` not existing in jest setup
Pull Request resolved: https://github.com/facebook/react-native/pull/28067
Test Plan: Are there tests to check if the test environment is setup correctly? �
Reviewed By: yungsters
Differential Revision: D30317021
Pulled By: charlesbdudley
fbshipit-source-id: 837ed952833ef8e70c5132c9b4152b0e0f28b4dd
Summary:
Changelog:
Add the capability to set tabbar accessibilityRole which maps to the iOS's UIAccessibilityTraitsTabBar
Reviewed By: yungsters
Differential Revision: D30490752
fbshipit-source-id: f7561a8932306e133d2f65a5ab40ba0be3899ec3
Summary:
Changelog: [Internal]
This diff add a flow libdefs for the `HermesInternalType` to type
`HermesInternal` as the first accurately typed `global` property,
and filled all the type holes.
Reviewed By: yungsters
Differential Revision: D29986749
fbshipit-source-id: a94be7919f989b5085f6b264e55145a85020fea9
Summary:
Fixes https://github.com/facebook/react-native/issues/29577 and https://github.com/react-native-community/upgrade-support/issues/93, when building an android library the package task has a different name, which was not handled correctly in the react.gradle file. The fix uses the existing `packageTask` variable which is correctly set for applications and libraries. This PR also copies the bundled js file into the correct assets directory, which is different from the assets directory of applications.
## 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] - Fixed Android library builds with react.gradle file
Pull Request resolved: https://github.com/facebook/react-native/pull/32026
Test Plan: Tested with my android library build which includes the `react.gradle` file and the build succeeded.
Reviewed By: sshic, ShikaSD
Differential Revision: D30368771
Pulled By: cortinico
fbshipit-source-id: 8f0df8c4d0fa38d85f7c0b9af56d88799571191d
Summary:
Changelog: [Internal]
TextInput's predefined "selection" prop is now applied when view did move to window, and when attributed string is set.
Reviewed By: sammy-SC
Differential Revision: D30045271
fbshipit-source-id: e5495171b07a25e1e822421ff1627a8686cd0904
Summary:
Changelog: [iOS][Added]
1. Added new primitive type "Selection" to C++
2. Added property "selection" to TextInputProps
3. Added parser for that
Reviewed By: sammy-SC
Differential Revision: D30043256
fbshipit-source-id: eefa67ca23759761901cba1d2ab3052877a153a7
Summary:
> Always leave the campground cleaner than you found it.
Fixing:
* typo in _dismissed_
* make the subject agree with the verb
## Changelog
[Internal] [Fixed] - A typo in a comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31916
Test Plan: Grammarly says it's better now.
Reviewed By: lunaleaps
Differential Revision: D29967403
Pulled By: yungsters
fbshipit-source-id: 6cb33328e99e3fceba5f19f4baaa9446340fbbcc
Summary:
Currently ImageBackGround component has optional style props, but if you don't pass it as prop, it still "thinks" you pass style and crushes.
In this pr, I made width and height inside component to be optional so it won't crush.
## Changelog
[General] [Fix] - Changed ImageBackground's style so it won't crush.
[Screen Shot 2021-08-20 at 15 05 45](https://user-images.githubusercontent.com/62840630/130230568-be02b1a2-52ec-4f9d-b3d3-212552d3882b.png)
As you can see in this component, I tried to use ImageBackground without any style props, and my app crushes. Then I added style with empty object and the app didn't crush anymore, as you can see here:
.
In conclusion, if we make width and height styles optionals inside ImageBackground component, it won't crush anymore.
Thoughts:
Maybe consider to make style props for this component none-optional because it isn't make any sense that image won't have any style at all.
Thanks ahead, that was my first pr, Eden Binyamin.
Pull Request resolved: https://github.com/facebook/react-native/pull/32055
Reviewed By: charlesbdudley
Differential Revision: D30452297
Pulled By: sshic
fbshipit-source-id: b7071aa457dba443ed2f627c2458ea84fd24b36d
Summary: Bridge can get invalidated during tear down. If a JS error is thrown then, don't display a LogBox so we don't hit the invalid bridge assert in RCTSurface.
Reviewed By: fkgozali
Differential Revision: D30464848
fbshipit-source-id: 87a8daa95fd06342d194a4805ecfa97279820f2e
Summary:
Changelog: [internal]
There is a possibility of race between JavaScript sending "completeRoot" and maximum size set on surface. To prevent this race, we set the initial maximum size to be equal to the viewport size.
Alternative solution is to set maximumSize to {0, 0} initially instead of infinity. This is what old architecture does, even though not explicitly.
Reviewed By: fkgozali
Differential Revision: D30402207
fbshipit-source-id: 44427404eaf060a81de257797823edf971ffc1bb
Summary:
Changelog: [internal]
Logger needs to be supplied to YGConfig, otherwise the app crashes when Yoga tries to log.
Reviewed By: fkgozali
Differential Revision: D30394676
fbshipit-source-id: bda464a4e43cb815c00650e1fedf43fe0a06f973
Summary:
It is assumed that there will always be an activity associated on enabling the dev support which is not the case. Hence adding that null check.
Changelog:
[Android][Fixed] - Added null check for activity in onHostResume()
Reviewed By: javache
Differential Revision: D30411311
fbshipit-source-id: 8936be2df7f16c355693163347d5e1d94c5ce2e1
Summary:
Changelog: [Internal]
Disables implicit `babel.config.js` lookup in a `parse()` call that does not need any user-specified config.
Reviewed By: javache
Differential Revision: D30396331
fbshipit-source-id: 9b07c361eae53cdffc6a76ba30f1146a7af65a10
Summary:
This diff adds a default behavior for the unified logger on Android.
Added the call site in the CXXNativeModule.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30377767
fbshipit-source-id: 000014828f2f245dc9492e3617218895d9a33536
Summary:
The impact of this has proven impressive, and safe. Ship in code and remove feature-flag.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D30269561
fbshipit-source-id: 9bb72567cfd881928d14d9bee43cf32b390664fb
Summary:
We want to resolve `NODE_BINARY` **after** `find-node.sh` runs and sets up any node version manager that we need to setup, otherwise `NODE_BINARY` is always undefined.
## Changelog
[Internal] [Fixed] - Resolve NODE_BINARY after finding the right path to node
Pull Request resolved: https://github.com/facebook/react-native/pull/32029
Reviewed By: TheSavior
Differential Revision: D30401213
Pulled By: yungsters
fbshipit-source-id: 386ffeff15b5f371a452488ed078d3adebe0f211
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32042
This diff moves react_native_log out of utils to make it easier/possible to import from modules.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30411247
fbshipit-source-id: 5482761b259600df051a88c6eff1834c882e7230
Summary:
This change allows native activities and fragments to also handle onActivityResult callbacks, in addition to sending the result to React Native.
Changelog:
[Android][Changed] - Call super.onActivityResult in ReactActivity's onActivityResult()
Reviewed By: JoshuaGross
Differential Revision: D30232449
fbshipit-source-id: cb080d6f2eff57dcf839660ee715cb4068ffcdd5
Summary:
Fabric core uses a lot of traits - I am reserving a few more for core usage, and also exposing a few "unreserved" traits.
It is recommended that all custom components that do use traits rely on these constants instead of hard-coding any trait values. That way, in the unlikely event that these values change in the future, it will not break components.
Changelog: [Internal]
Reviewed By: cortinico, RSNara
Differential Revision: D30401743
fbshipit-source-id: fb2e8f5cf33c94e31a0c25a89055acfc4eccf066
Summary:
Update FabricUIManager methods for `SurfaceHandler` to start usual rendering or prerendering based on presence of the view instead of using two methods with same logic.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30346502
fbshipit-source-id: 297f2b4a16dc7af7c36379252bd73e6dc953ff59
Summary:
Android Gradle Plugin 7 removed dependency configurations, and it includes compile. Below is a snipped from release notes https://developer.android.com/studio/releases/gradle-plugin
I can confirm that RN 0.65.0 app is running as expected on Android with the patch.
> **compile**
Depending on use case, this has been replaced by api or implementation.
Also applies to *Compile variants, for example: debugCompile.
## Changelog
[Android] [Changed] - Android Gradle Plugin 7 compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/32030
Test Plan: Create a project with RN 0.65.0 and upgrade Android Gradle Plugin to 7.0.0, and Gradle to 7.0.2. It'll fail to sync. Then apply the change, and it'll sync as normal, and build the app.
Reviewed By: passy, ShikaSD
Differential Revision: D30394238
Pulled By: cortinico
fbshipit-source-id: cabc25754b9cd176a7d6c119d009728f2e5a93d9
Summary:
When retrieving the device dimensions through the JS `Dimensions` utility, the result of `Dimensions.get` can be incorrect on Android.
### Related issues
- https://github.com/facebook/react-native/issues/29105
- https://github.com/facebook/react-native/issues/29451
- https://github.com/facebook/react-native/issues/29323
The issue is caused by the Android `DeviceInfoModule` that provides initial screen dimensions and then subsequently updates those by emitting `didUpdateDimensions` events. The assumption in that implementation is that the initial display metrics will not have changed prior to the first check for updated metrics. However that is not the case as the device may be rotated (as shown in the attached video).
The solution in this PR is to keep track of the initial dimensions for comparison at the first check for updated metrics.
## Changelog
[Android] [Fixed] - Fix Dimensions not updating
Pull Request resolved: https://github.com/facebook/react-native/pull/31973
Test Plan:
### Steps to reproduce
1. Install the RNTester app on Android from the `main` branch.
2. Set the device auto-rotation to ON
3. Start the RNTester app
4. While the app is loading, rotate the device
5. Navigate to the `Dimensions` screen
6. Either
a. Observe the screen width and height are reversed, or
b. Quit the app and return to step 3.
### Verifying the fix
#### Manually
Using the above steps, the issue should no longer be reproducible.
#### Automatically
See unit tests in `ReactAndroid/src/test/java/com/facebook/react/modules/deviceinfo/DeviceInfoModuleTest.java`
### Video
https://user-images.githubusercontent.com/4940864/128485453-2ae04724-4ac5-4267-a59a-140cc3af626b.mp4
Reviewed By: JoshuaGross
Differential Revision: D30319919
Pulled By: lunaleaps
fbshipit-source-id: 52a2faeafc522b1c2a196ca40357027eafa1a84b
Summary:
Fix the CSS on the main Modal test
Move the warning message for the "Transparent" switch to below the switch, since warnings messages are usually under the field they're warning.
Move Presentation Style to be before Transparent, since Transparent is a modifier of "overFullScreen" Presentation Style.
Reviewed By: lunaleaps
Differential Revision: D30323087
fbshipit-source-id: b13d6c958145096da95c9888181ff457b093fb49
Summary:
In this diff:
1. Convert the ReactNativeLogger to c function for the future compatibility.
2. Bind the log function from Catalyst app
3. Update the call site
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30271863
fbshipit-source-id: 4c0ea704cf19f53468a3b72631353959ea999884
Summary:
This PR fixes the border-style that is not respected when drawing a border with 0 border-radius on Android. This would cause the faster `drawRectangularBackgroundWithBorders` path to be used, but that uses rectangular drawing and doesn't support dashed/dotted stroke patterns.
This PR changes the behavior to use the generic `drawRoundedBackgroundWithBorders` code-path which does support dashed/dotted border-styles.
## Changelog
`[Android] [Fixed] - Fix dashed/dotted border-drawing when border-radius is 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28359
Test Plan:
**Faulty situation:**
**After the fix:**
Reviewed By: lunaleaps
Differential Revision: D20590739
Pulled By: charlesbdudley
fbshipit-source-id: 18657ea21e54f763e22c623bf979b3500c1bdcbd
Summary:
This PR aims to resolve iOS can't dismiss Modal on swipe gesture.
https://github.com/facebook/react-native/issues/29319
When modal presentationStyle is pageSheet, iOS allows to dismiss the modal using swipe gesture. This PR adds support for that feature
## 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] [Added] - Support for onRequestClose for iOS Modal component.
Pull Request resolved: https://github.com/facebook/react-native/pull/31500
Test Plan:
- If onRequestClose updates the visibility state, modal will be closed.
```
<Modal
visible={visible}
animationType="slide"
presentationStyle="pageSheet"
onRequestClose={dismiss}>
</Modal>
```
https://user-images.githubusercontent.com/23293248/117590263-36cd7f00-b14c-11eb-940c-86e700c0b8e7.mov
## Notes
- In this PR, only support for partial drag is added. i.e. user can't drag the modal up and down completely. I added full user dragging but reverted in this [commit](https://github.com/facebook/react-native/commit/bb65b9a60d54b61652d608661eba876b49be3b17) to support controllable onRequestClose. If someone has any suggestion to have full draggable support + controllable onRequestClose, please let me know.
<!--
the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
Reviewed By: p-sun
Differential Revision: D30041625
Pulled By: sammy-SC
fbshipit-source-id: 9675da760bd5c070c4f0e1d30271c8af5c50b998
Summary: Changelog: [Internal] - Annotated the MessageCallback and ConnectionCallback params of the ReconnectingWebSocket with Nullable
Reviewed By: makovkastar
Differential Revision: D30298832
fbshipit-source-id: 4e0a6ea339d1d8b25fb7bb24dfbada93d5cebc96
Summary:
On Android, when a hardware keyboard is connected pressing the escape key will partially dismiss an active `<Modal>` without calling the `onRequestClose` callback. The modal will disappear, but I beleive the underlying activity may still be present, blocking interaction with the main app below and leaving things in a partially broken state.
This code change allows the escape key to be handled in the same way as the hardware back button, calling the `onRequestClose` and allowing the developer to decide the behaviour.
This issue isn't present on iOS, so no change is required there.
## 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] - Fix Modal being dismissed incorrectly when pressing escape on a hardware keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/31564
Test Plan: I've tested this manually locally, but unsure if it's possible to test in an automated way as the emulator didn't respond to a hardware escape key in the same way as a physical device.
Reviewed By: ShikaSD
Differential Revision: D28953718
Pulled By: lunaleaps
fbshipit-source-id: 5547bc5d894da0d3d9daf4515b1af9c2407815db
Summary:
seperated -> separated
## 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
-->
[Internal] [Fixed] - Fixed typo in comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31067
Test Plan: NONE
Reviewed By: sammy-SC
Differential Revision: D30176244
Pulled By: sota000
fbshipit-source-id: 617607aaa7eb5f613344773c4bbbc09a8c5096c1
Summary:
After this diff, when ReactFeatureFlags.warnOnLegacyNativeModuleSystemUse is enabled, the legacy NativeModule infra will log soft exceptions whenever legacy NativeModules are accessed/used.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30272695
fbshipit-source-id: 7111402c1d8b883a600dcb4559e9ff1d56447070
Summary:
When the TurboModule system is enabled, C++ NativeModules shouldn't be used in production. We'll use this JReactSoftExceptionLogger to log soft exceptions from C++ NativeModules this scenario.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30272694
fbshipit-source-id: 8dadcfe51bcbc353d438d1a403e74da5e2cb9546
Summary:
When ReactFeatureFlags.warnOnLegacyNativeModuleSystemUse is true, we will log a SoftException, whenever:
1. A Java/Cxx NativeModule is created by the legacy system.
2. Any method on the Java NativeModule is executed, including getConstants().
NOTE: Logs to CXXModule use incoming.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30252953
fbshipit-source-id: 570929624d0114bb298c593ba909e5cdbd54bd6c
Summary:
When true, this flag will cause React Native to start logging soft exceptions, whenever the legacy NativeModule system is used. This flag is independent of useTurboModules. In practice, it's only enabled when TurboModules is enabled.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30250363
fbshipit-source-id: f610567c5b99a4fbf8252c3962908668f483d028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32007
This Diff simplifies the codegen Gradle build.
Previously the build used to have a 2-level nesting of included build.
Turns out that the `react-native-codegen/android/build.gradle` build
is just providing a task and including an inner build that contains the codegen
Gradle plugin. I've moved such plugin to the outer build.
This will also make sure that the Gradle plugin files are properly index by the
IDE when opening the build (as nested included build are not yet supported).
Changelog:
Internal - Flatten the `react-native-codegen` Gradle included build
Reviewed By: fkgozali, ShikaSD
Differential Revision: D30227784
fbshipit-source-id: af304afeeba1926f8b7b5b47cf69889d3f808f5f
Summary:
This is just a minor bump in the Android Gradle plugin.
Changelog:
[Android][Changed] - Bumped AGP to 4.2.2
allow-large-files
Reviewed By: ShikaSD
Differential Revision: D30220591
fbshipit-source-id: 217a21e4935bcd258ac3bcd45c7fb1ff5c0a1ead
Summary:
Globbing is case sensitive only when eden is enabled. This causes Android cold builds to regress by 2 minutes because a large number of react native targets have to be built and fetched.
This change causes srcs to match with and without eden.
Changelog: [Internal]
Reviewed By: cute-jumper
Differential Revision: D30266076
fbshipit-source-id: 39ac2cbfa146fcdda1d8d3a6f40b0ec41bfb3c2f
Summary:
ReactSoftException makes it seem like the class is an Exception, when it's actually a logger. This rename I think is more appropriate.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251735
fbshipit-source-id: 550bd543388e698774ec31753200bd3f722d8c17
Summary:
After creating and using this utility, we learned that (1) it's really useful, and (2) its interface is good enough. So, let's un-deprecate this utility.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251651
fbshipit-source-id: d1ecf81484f865587a5552d5ddf0e68da86397d9
Summary:
We had some confusion lately, where errorName was used to dump "error message". This caused problems in Scuba.
This doc should add some clarity on what is expected from endFailure users.
Changelog:
[Internal][Added] - Documentation for method in UserFlow.js class
Reviewed By: mityal
Differential Revision: D30192127
fbshipit-source-id: d057668aab714a9342131c83daf41cbe9372cb39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31998
Overall Context: We want to add a way to log errors (e.g. mustfix, warn, etc on the server with stack trace) without crashing the app (e.g. react_native_assert crashes the app).
This diff: I am writing very simple logger functions which will get resolved at build time depending on the platforms/apps.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30174404
fbshipit-source-id: 2e5bc865dd8576c5a758c56e080a1e582a8c3ada
Summary:
Changelog: [Internal]
when we try to write a `SharedColor` type prop in the renderer, the template function we match to is the following:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactCommon/react/renderer/core/propsConversions.h?commit=28dacb972cda702d37dedd4612bc67c212d4d9eb&lines=108-132
this is because `SharedColor` is an alias of `better::optional<Color>`. ultimately, this causes a crash in L130 - the template deduction in L130 interprets the T as an `int`, rather than `SharedColor`, but our `rawValue` is pointing to `SharedColor`.
there was a number of options i considered, but didn't feel the most correct:
- wrapping `SharedColor` in another `better::optional` - this felt like a hack and didn't really provide any real benefits of the `optional` wrapper.
- writing a template specialization on SharedColor - this didn't seem future proof because we could introduce another type that could potentially wrap an integer, which doesn't seem impossible in the future - then we would get some conflict with our `SharedColor` conversion, which is custom to the behavior of colors.
- coercing the template during the function call - from an engineering perspective, this didn't seem like a great idea since it isn't clear to the engineer that this would be necessary and they would most likely only find out to do this after seeing a crash on their builds.
i ultimately decided to convert `SharedColor` to a simple class wrapper, similar to the implementation already used in Android. this alleviates all of the concerns with the other options above.
Reviewed By: sammy-SC
Differential Revision: D30149880
fbshipit-source-id: 7e8abafcd9fd7465b13ef227d140e859f8df6ecd
Summary:
Changelog: [Internal]
in this diff, we iterate through the list of color passed down in the props, and write the RGBA value of the first valid UIColor
Reviewed By: sammy-SC
Differential Revision: D30110297
fbshipit-source-id: c6730110129d0fe1f784fa89cd26b46d3dda7f28
Summary:
Changelog: [Internal]
in this diff, we add the logic to handle converting PlatformColor strings to their corresponding RGBA values, using `UIColor`'s API as the source of truth of these colors.
functionality not covered yet:
- customColor
- iOS Dynamic Colors
- Variant Colors
Reviewed By: sammy-SC
Differential Revision: D30103451
fbshipit-source-id: 7d7be0f08dc2fb95b606b8f5d73784766787a574
Summary:
This diff is cleaning up some configurations in the `Android.mk` files
of the native build. Specifically I simplified some of the rules and removed
a duplicate file specification.
Changelog:
Internal - Cleanup warnings in the NDK build
Reviewed By: ShikaSD
Differential Revision: D30220715
fbshipit-source-id: a100953fe977879a6d28cb0a2ef4b3358fb7c774
Summary:
Changelog: [Internal]
Currently, `global` is typed as `any` and any `global` properties
accesses are untyped. This diff add a flow libdefs for the `global`
object as a start point.
Reviewed By: yungsters
Differential Revision: D30000895
fbshipit-source-id: ab6988d01921a3c2a3434b534b2f69083570fb6d
Summary:
changelog: [internal]
If nodesManager has the information if animated node is managed by Fabric, we can't decide if the operation queue should be flushed before it is flushed. Therefore, keep the information about animated nodes inside a set instead of nodesManager.
For simplicity, I will refer to class `RCTNativeAnimatedTurboModule` as *NativeAnimated* and to `RCTNativeAnimatedNodesManager` as *NodesManager*
Notice that each call to *NativeAnimated* is queued up in `_operations` or `_preOperations`. When the queues are flushed, only then methods are called on `RCTNativeAnimatedNodesManager`.
There are two mechanisms that flush operations.
One is triggered by `RCTMountingManager` before mounting operations are applied and after they are applied. This works fine but is important to paint the picture.
The second mechanism is inside `[RCTNativeAnimatedTurboModule startAnimatingNode]`. It flushes the queues for Fabric nodes only (not sure why Fabric nodes only, I couldn't find any explanation in old diffs). It checks with *NativeAnimated* if a node is managed by Fabric. Keep in mind, *NodesManager* only knows about the nodes when the queues have been flushed.
Exampe:
JavaScript calls methods on *NativeAnimated*.
For example:
1. `createNode`
2. `connectAnimatedNodeToView`
3. `startAnimatingNode`. (here, the queues should be flushed, since we are in Fabric)
All of these operations are queued up and for as long as `RCTMountingManager` executes mounting, all proceeds as expected.
But if those operations happen after mounting phase, `startAnimatingNode` will not flush the operations queues, because it can't tell if nodeTag is managed by fabric or it isn't. This is because *NodesManager* hasn't been notified about any new nodes.
Reviewed By: RSNara
Differential Revision: D30099010
fbshipit-source-id: d3fc021dd4346d1cbbda3b49ecd9d982c543e705
Summary:
Recent change in https://github.com/facebook/react-native/pull/31865 made it so if `ReactSliderManager` is created on the react context creation thread it will crash with the following error. This happens because `ReactAccessibilityDelegate` tries to create a handler on a thread without a looper.
This seems to happen because react-native-reanimated tries to get the UIManager module during its initialization which will cause view managers to be created and explains why the crash probably does not happens in RNTester or using only RN bundled modules.
```
08-03 14:44:56.318 21206 21360 E AndroidRuntime: FATAL EXCEPTION: create_react_context
08-03 14:44:56.318 21206 21360 E AndroidRuntime: Process: com.th3rdwave, PID: 21206
08-03 14:44:56.318 21206 21360 E AndroidRuntime: java.lang.ExceptionInInitializerError
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.shell.MainReactPackage.createViewManagers(MainReactPackage.java:166)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.getOrCreateViewManagers(ReactInstanceManager.java:882)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.CoreModulesPackage.createUIManager(CoreModulesPackage.java:137)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.CoreModulesPackage.getModule(CoreModulesPackage.java:102)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.TurboReactPackage$ModuleHolderProvider.get(TurboReactPackage.java:159)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.TurboReactPackage$ModuleHolderProvider.get(TurboReactPackage.java:147)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ModuleHolder.create(ModuleHolder.java:191)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ModuleHolder.getModule(ModuleHolder.java:156)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:153)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:486)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:462)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ReactContext.getNativeModule(ReactContext.java:176)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.NodesManager.<init>(NodesManager.java:153)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.ReanimatedModule.getNodesManager(ReanimatedModule.java:101)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.ReanimatedJSIModulePackage.getJSIModules(ReanimatedJSIModulePackage.java:17)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.th3rdwave.MainApplication$1$1.getJSIModules(MainApplication.java:135)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.createReactContext(ReactInstanceManager.java:1329)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.access$1100(ReactInstanceManager.java:136)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1058)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at java.lang.Thread.run(Thread.java:923)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: Caused by: java.lang.RuntimeException: Can't create handler inside thread Thread[create_react_context,5,main] that has not called Looper.prepare()
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at android.os.Handler.<init>(Handler.java:227)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at android.os.Handler.<init>(Handler.java:129)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.uimanager.ReactAccessibilityDelegate$1.<init>(ReactAccessibilityDelegate.java:185)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.uimanager.ReactAccessibilityDelegate.<init>(ReactAccessibilityDelegate.java:184)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.views.slider.ReactSliderManager$ReactSliderAccessibilityDelegate.<init>(ReactSliderManager.java:281)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.views.slider.ReactSliderManager.<clinit>(ReactSliderManager.java:301)
```
To fix it I changed the delegate creation to be done in `createViewInstance` which will be called on main thread. This is also more in line with how other accessibility delegates are created for other view managers. Since Slider is probably not used a lot, creating more delegate instance won't be an issue.
Another alternative could be to initialize a Looper on the thread that creates the react context, but it seems more involved and probably not needed.
## Changelog
[Android] [Fixed] - Create slider accessibility delegate in createViewInstance
Pull Request resolved: https://github.com/facebook/react-native/pull/31942
Test Plan: Reproduced the crash in an app and made sure this patch fixes it.
Reviewed By: JoshuaGross
Differential Revision: D30167451
Pulled By: p-sun
fbshipit-source-id: 5327130064db52ac0086e1ae5541a1b3e3954f15
Summary:
For any Pod that uses the codegen, create references to code-gen'd files in local filesystem regardless of Pod install status by invoking the same command used by `prepare_command` whenever `pod install` is run.
This works around the issue where CocoaPods may decide to skip running `prepare_command`. While this is expected CocoaPods behavior, external factors may result in the deletion of the original code-gen'd files in which case we need to make sure that running `pod install` will bring these files back.
See Test Plan for more details on how to reproduce the issue being fixed.
Fixes T97404254.
Changelog:
[Internal] Codegen invoked with every `pod install` regardless of pod install status
Differential Revision: D30116640
fbshipit-source-id: 81db5dff1d4c4f8ae22b5dbe822609c770789ac8
Summary:
Note: PR to react-native-macos here https://github.com/microsoft/react-native-macos/pull/733
Internally in Microsoft code, we ran into a deadlock where the main queue and the UIManager queue were both trying to access `[RCTI18nUtil sharedInstance]`, and were blocked on each other. This is similar to an earlier issue with RCTScreenScale decsribed [here](https://github.com/facebook/react-native/issues/18096).
To summarize:
1- RCTShadowView (on the UIManager queue) and RCTView (on the main queue) both try to access `[RCTI18nUtil sharedInstance]`
2- The UIManager thread gets there first, and lazily initializes the sharedInstance. Meanwhile, the main thread is waiting on a lock possessed by the UIManager thread
3- As part of the initialization, we set an NSUserDefault, which seems to require the (blocked) main thread.
4- Deadlock.
For whatever reason, this only happens on debug. I did not figure out why, but I do know based on [this comment](https://github.com/facebook/react-native/issues/18096#issuecomment-368718081), that the UIManagerQueue should never block the main queue.
The fix is to not use NSUserDefaults, and simpy use atomic properties instead. We get the thread safety for free, and it also simplifies the code somewhat without changing the public API. The downside is values aren't persisted anymore, but I do not think that was necessary / intended.
## 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] - Fix deadlock on RCTi18nUtil
Pull Request resolved: https://github.com/facebook/react-native/pull/31032
Test Plan:
Ran the RTLExample in RNTester, and ensured switching to RTL still worked, and that setting forceRTL would still work after reloading the bundle.
https://user-images.githubusercontent.com/6722175/108775429-aefdae80-7526-11eb-9a89-3114f7ddc2af.mov
Reviewed By: javache
Differential Revision: D29522152
Pulled By: RSNara
fbshipit-source-id: 160840f63a7b1d6721b0fd8294fb11990a4509fa
Summary:
EZ diff that adds a few TODOs to unify component names between JS - Android - iOS - C++
see task: T97384889
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D30139942
fbshipit-source-id: 91f51d04e7e7ecba7f059f94a121be43d820647d
Summary:
## Rationale
Inlining the maybeLoadSoLibrary private static method makes following the So load chain from TurboModuleManagerDelegate through ReactPackageTurboModuleManagerDelegate to each app's TurboModuleManagerDelegate much easier to understand.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30082675
fbshipit-source-id: ff467d6ac8c792317dd9bdcd91844d3b480cbb60
Summary:
Updates previous variant that was crashing a surface to the non-crashing variant.
Now it prints error in console and modifies value to be 0.
Changelog: [General][Fixed] Clamp negative values for `numberOfLines` in <Text> component
Reviewed By: yungsters
Differential Revision: D30129658
fbshipit-source-id: fda47a262365573514d3e1e4bf8a26f6d30cdae0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31957
Changelog: [Internal]
Some fixes for the GitHub shims for FB-internal Buck macros. Should fix the Buck-related breakages in the `test_android` and `test_docker` CI jobs.
Also adds license headers to some recently-added files that didn't have them.
Reviewed By: mdvacca
Differential Revision: D30114177
fbshipit-source-id: 88a24fa7130bd98dd60568566bde51fcfc89df60
Summary:
Removed FlowFixMe that has been fixed
## 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] - Removed FlowFixMe that has been fixed
Pull Request resolved: https://github.com/facebook/react-native/pull/29468
Test Plan: flow check passes
Reviewed By: JoshuaGross
Differential Revision: D29967702
Pulled By: lunaleaps
fbshipit-source-id: 541279287ba6f21c5c7290bcba7c282f092126ff
Summary:
This diff extends the FabricUIManager.getInspectorDataForInstance to return the props of the React Native component associated to the view passed as a parameter.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D30095406
fbshipit-source-id: 50fdba6636a1f5042dbc113e341c3cb2534a1b04
Summary:
This diff fixes a NullPointer that was being thorwn when hierarchy values are null
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D30095407
fbshipit-source-id: b0a13661b4506cf94eeb5d99923d4c12cba0f972
Summary:
Negative `numberOfLines` prop is not supported by Android and causes a crash during layout measurement. This change adds a check in JS to catch the error earlier.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D30047103
fbshipit-source-id: 4248a0f573c3b6facd25c7ae6ce007a357a1469b
Summary:
changelog: [internal]
If nodesManager has the information if animated node is managed by Fabric, we can't decide if the operation queue should be flushed before it is flushed. Therefore, keep the information about animated nodes inside a set instead of nodesManager.
For simplicity, I will refer to class `RCTNativeAnimatedTurboModule` as *NativeAnimated* and to `RCTNativeAnimatedNodesManager` as *NodesManager*
Notice that each call to *NativeAnimated* is queued up in `_operations` or `_preOperations`. When the queues are flushed, only then methods are called on `RCTNativeAnimatedNodesManager`.
There are two mechanisms that flush operations.
One is triggered by `RCTMountingManager` before mounting operations are applied and after they are applied. This works fine but is important to paint the picture.
The second mechanism is inside `[RCTNativeAnimatedTurboModule startAnimatingNode]`. It flushes the queues for Fabric nodes only (not sure why Fabric nodes only, I couldn't find any explanation in old diffs). It checks with *NativeAnimated* if a node is managed by Fabric. Keep in mind, *NodesManager* only knows about the nodes when the queues have been flushed.
Exampe:
JavaScript calls methods on *NativeAnimated*.
For example:
1. `createNode`
2. `connectAnimatedNodeToView`
3. `startAnimatingNode`. (here, the queues should be flushed, since we are in Fabric)
All of these operations are queued up and for as long as `RCTMountingManager` executes mounting, all proceeds as expected.
But if those operations happen after mounting phase, `startAnimatingNode` will not flush the operations queues, because it can't tell if nodeTag is managed by fabric or it isn't. This is because *NodesManager* hasn't been notified about any new nodes.
Reviewed By: JoshuaGross, p-sun
Differential Revision: D30053890
fbshipit-source-id: b7fe24861d5300f9cfefa813a53df8330fa56d86
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Changelog: [internal]
Make sure the order of call is preserved for `NativeAnimatedModule`. The order of calls to NativeAnimatedModule needs to be preserved because its internals depend on it. For example, if you `getValue` is called before `createAnimatedNode`, it causes a crash.
To resolve it, we need to enqueue `getValue` onto operationQueue.
Reviewed By: JoshuaGross
Differential Revision: D30035911
fbshipit-source-id: bbd698a96cada5d2b1312a1a689ca99b04a07cdc
Summary:
This small PR updates the Flow types used in Dimensions. The following changes has been made:
* generic types has been replaced with types from `NativeDeviceInfo` (which already were used in event subscription update)
* ~simplification of `DisplayMetricsAndroid` by spreading via intersection with `DisplayMetrics` type and removing shared properties~
> I have tried both notations, but according to the lint, it looks like a Native Modules typing limitation which requires redundancy / code duplication in cases like this.
## 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
-->
[Internal] [Changed] - update Dimensions API Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/31898
Test Plan: Running `yarn flow` in the workspace yields no errors.
Reviewed By: yungsters
Differential Revision: D29932940
Pulled By: GijsWeterings
fbshipit-source-id: bf97bb972964c585207e2450ccf71d932555e291
Summary:
It seems that, possibly due to optimizations and refactoring elsewhere in the event system, some TouchEvents are being over-disposed.
This doesn't really pose a problem besides performance; and could even indicate that an Event was in a pool but never properly initialized. In these
cases it seems perfectly reasonable to silently continue, and to log a soft exception. This WILL still crash in debug mode, so we can gather more information
if we find a good repro; otherwise we will continue to get production data from this soft exception if it's an issue and we can investigate further.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D30061178
fbshipit-source-id: 05d1f60afc382ce0a202ac8f3de34770cf9a760d
Summary:
Changelog: [Internal]
If generators are provided natively, that should suggest that the JS source
code did not go through the regenerator-transform (e.g. in Metro Hermes profile),
then there is no need to set up the regenerator runtime.
This should save some work during the Core initialization.
Reviewed By: motiz88
Differential Revision: D29986751
fbshipit-source-id: 129f5122e8e4c05535ee2aa5da6970a66843e8cd
Summary:
Changelog: [Internal]
This diff only extracted the `isNativeFunction` used in `setUpTimers`
into the `FeatureDetection` utility, but later we will add more functions
in it and reuse them in other places.
Reviewed By: RSNara
Differential Revision: D29986750
fbshipit-source-id: 6e48e38d92ceccb35eead3c52e00e1eecb81b5b0
Summary:
Moves the Facebook-internal Buck target definition for React Native closer to the actual JS source files. This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27942687
fbshipit-source-id: 328febb661ed6597feafdfd8efb2a95365325348
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31435
Moves the Facebook-internal Buck target definition for RNTester closer to the actual source files. This does not affect how RNTester is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27942209
fbshipit-source-id: 66c970a5464a9329597d155ceeca78fb7f4834e8
Summary:
This is the Android analogue to D30019833.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30029295
fbshipit-source-id: 13df0dfb915697eeedcc527dcdb6c246e89afb0c
Summary:
Remove unused import
## 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] [performance] - Remove unused import
Pull Request resolved: https://github.com/facebook/react-native/pull/30544
Test Plan: Should build on CI
Reviewed By: lunaleaps
Differential Revision: D30000901
Pulled By: charlesbdudley
fbshipit-source-id: 3d3310917823b7af57564ca1ea397cd32cd0c4d5
Summary:
This diff updates the xplat flowconfigs to make existential types an error.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D29967838
fbshipit-source-id: f08bbafe2a0269adb2c9afa4572b7a34fd254a4d
Summary:
preferred instead of preffered
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/29858
Reviewed By: charlesbdudley
Differential Revision: D29998754
Pulled By: sota000
fbshipit-source-id: f13fef58e9154ddf8087944d53e022fb9afa6b1b
Summary:
See previous diffs for context. This updates all of the relevant props structs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29855426
fbshipit-source-id: 30177c3380ef82ecf8f2a4321f128cfbe8a576e0
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
occured -> occurred
## 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
-->
[Internal] [Fixed] - Fixed typo in VirtualizedList-test.js
Pull Request resolved: https://github.com/facebook/react-native/pull/31756
Test Plan: NONE
Reviewed By: lunaleaps
Differential Revision: D29975153
Pulled By: charlesbdudley
fbshipit-source-id: 966d90df0bf015b4a6a2e3b1bf88c66b61161a7a
Summary:
Fixes https://github.com/facebook/react-native/issues/31779
For more detailed explanation, see issue https://github.com/facebook/react-native/issues/31779
React Native touch handler events (onTouchStart, onTouchMoved, etc..) are intended to have "force" properties when used on devices which support pressure input (3D Touch & Apple Pencil events). However, due to a check in RCTForceTouchAvailable() function which checks for UITraitCollection's "forceTouchCapability" to be equal to UIForceTouchCapabilityAvailable, the check returns NO on iPad-based devices, due to iPad devices returning UIForceTouchCapabilityUnavailable at all times. This causes "force" values of Apple Pencils to never be passed on to React Native.
Since simply passing 0 as a value for force across the RN bridge for every touch event seemed like a change that might seem jarring to some, I decided that a simple additional boolean check if the touch event's type is UITouchTypePencil (this is the same as UITouchTypeStylus) should also suffice.
## 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 "force" property of touch events for Apple Pencil/Stylus devices.
[iOS] [Feature] - Added "altitudeAngle" property to touch events from Apple Pencil/Stylus devices.
Pull Request resolved: https://github.com/facebook/react-native/pull/31780
Test Plan:
The code compiles and runs, and trying a simple handler for a View like
````
touchMove = (e: GestureResponderEvent) => {
console.log(`pressure, altitude (${e.nativeEvent.force}, ${e.nativeEvent.altitudeAngle})`);
````
results in
<img width="424" alt="Screen Shot 2564-06-28 at 17 13 22" src="https://user-images.githubusercontent.com/5000572/123621055-0b563f00-d835-11eb-9eff-526ba27fdf7b.png">
and when pencil is oriented perpendicular to the screen and pressed with full force shows
<img width="412" alt="Screen Shot 2564-06-28 at 17 13 58" src="https://user-images.githubusercontent.com/5000572/123621139-1c06b500-d835-11eb-8207-68a49720d708.png">
Reviewed By: sammy-SC
Differential Revision: D29964102
Pulled By: sota000
fbshipit-source-id: 5a1f41d64c6fe325afbd2b9579eaf20a522e92dc
Summary:
changelog: [internal]
Completion block can retain `_eventEmitter` beyond existence of the component. To fix this, do not retain `_eventEmitter` by block but try to acquire it inside it.
Reviewed By: JoshuaGross
Differential Revision: D29969189
fbshipit-source-id: 456c42f816acc160f9d6bbd3f9c8c55d611940b2
Summary:
Changelog: [Internal]
Historically, Immediate API is implemented upon the React Native's
internal microtask-y queue (known as "immediate queue"), which
is the same queue Promise polyfill is operating on.
To make React Native suitable of using the built-in Promises from JSVMs,
which usually enqueues to the JSVM internal microtask queue and has no
access to React Native microtask-y queue, we need to migrate the
Immediate API to use the JSVM microtask queue as well to preserve the
semantics of code relies on the interleaving of promises and immediates.
To do that, this diff implement a shim layer for immediate APIs via the
new `global.queueMicrotask` API (which enqueues to JSVM) in JS, by wrapping
the immediate callback into a "microtask callback", which validate the
`immediate ID` against `clearedImmediate` Set before invoking it.
Reviewed By: RSNara
Differential Revision: D29845305
fbshipit-source-id: c2ed3fed426a5316b1e0dfbfaad51706d1765d4d
Summary:
Changelog:
[General][Added] - Add global.queueMicrotask
`queueMicrotask` is a relatively recent API defined in the WHATWG HTML spec
and it's been widely adopted by all web browsers and Node.js.
This diff introduced it to React Native by polyfilling it via a lazily-allocated
resolved Promise, or calling directly into a fast path provided by Hermes.
Reviewed By: RSNara
Differential Revision: D29838852
fbshipit-source-id: 8c4378b1b713fb8b0da5e67f92ba2ea9838766f7
Summary:
Changelog: [Internal]
Separate the functionality of the isPackagerRunning() function into a new class PackagerStatusCheck with the intention of being able to use this without needing a DevServerHelper
Reviewed By: makovkastar, ShikaSD
Differential Revision: D29933318
fbshipit-source-id: d708bb987b08634015d6ee6b6c8989faba416c5a
Summary:
This diff fixes the Android View dimensions in VR
PixelUtil.toSPFromPixel and PixelUtil.getDisplayMetricDensity() are both using getScreenDisplayMetrics() to perform conversion of dimensions. This is not correct because we should take into consideration the density of the Context / Activity instead of the Screen. This problem didn't raise before in Fabric Android because it seems that android OS on phones usually share the scale between the screen and the Activity?
These two methods are only used in Fabric and they were introduced by D9583972 (https://github.com/facebook/react-native/commit/5c0da011cbaa788c52519f8091157ca6d87d8abb) and D9173758 (https://github.com/facebook/react-native/commit/8b5e3fc16b1e58441318b6ada629dcff572dd120)
As part of this diff I'm also deleting the method toSPFromPixel in favor of toDIPFromPixel because I noticed the usages of these methods are meant to use toDIPFromPixel()
changelog: [Internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29864944
fbshipit-source-id: a0a093c120bde21a6cf9e1043a83c31e870d4368
Summary:
Currently, React Native throws an invariant violation error when a text string or number is supplied as a child. This is undesirable because core library components should be fault-tolerant and degrade gracefully (with soft errors, if relevant).
This change will work when a change in the host configs are landed (https://github.com/facebook/react/pull/21953).
Changelog: [internal]
Reviewed By: yungsters, sammy-SC
Differential Revision: D29894182
fbshipit-source-id: 827ff299991a476b57981382d196c7ee1396ec28
Summary:
Some of the links in `CONTRIBUTING.md` redirects you to a different page.
I've fixed the links so each link would directly send users to the appropriate page.
## 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
-->
[INTERNAL] [Changed] - update links in CONTRIBUTING.md
Pull Request resolved: https://github.com/facebook/react-native/pull/31903
Test Plan: - [ ] Change links shows the appropriate content
Reviewed By: lunaleaps
Differential Revision: D29933105
Pulled By: GijsWeterings
fbshipit-source-id: b5be74181f8a8e88d8f43e44c469337b7393dedf
Summary:
Part of https://github.com/facebook/react-native/issues/31788
~Updated link in README that was pointing to master branch to main branch~
Realized that link in rn-tester README and ReactAndroid README leads to a dead link, so I've fixed the links
## 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
-->
[INTERNAL] [FIXED] - Fix dead links in README
Pull Request resolved: https://github.com/facebook/react-native/pull/31901
Test Plan: - [ ] Updated link directs you to appropriate page
Reviewed By: PeteTheHeat
Differential Revision: D29933044
Pulled By: GijsWeterings
fbshipit-source-id: c1f301626acbb2995d74f78d8bc19214c70e9319
Summary:
Changelog: [internal]
Fabric didn't have prop [removeClippedSubviews](https://reactnative.dev/docs/view#removeclippedsubviews) implemented. This diff adds it. It is
Reviewed By: JoshuaGross
Differential Revision: D29906458
fbshipit-source-id: 5851fa41d7facea9aab73ca131b4a0d23a2411ea
Summary:
Changelog: [Internal]
This diff replaced all the internal occurrences of "Immediate" with
"ReactNativeMicrotask" in the legacy bridge and then polyfilled the
original immediate APIs during the timer setup phases as aliases of them.
Note that this diff is part of a larger refactoring.
Reviewed By: RSNara
Differential Revision: D29785430
fbshipit-source-id: 7325d2a7358a6c9baa3e9abb8acf90414de5072f
Summary: Changelog: [Internal] - Add an example to demo all the transform properties.
Reviewed By: charlesbdudley
Differential Revision: D29865790
fbshipit-source-id: 79174457071de8fca9b0aab8bf8dcc543ea9a0a3
Summary:
- Update `RNTesterNavBar` to be positioned relatively to allow for scroll views to not be clipped
- Add EasingExample with example animations taken from https://reactnative.dev/docs/easing
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29744160
fbshipit-source-id: d0e2112769d74dd34e11477f1d3b1f8f0ffebc03
Summary:
Fixed a link in a comment that lead to dead link
whatwg-url changed the source directory from `lib` to `src`
## 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
-->
[INTERNAL] [FIXED] - fix dead link in a comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31902
Test Plan: - [ ] Changed URL opens properly
Reviewed By: charlesbdudley
Differential Revision: D29915170
Pulled By: lunaleaps
fbshipit-source-id: 00b69db82f51d16cf887cd4540a159132ad7d771
Summary:
There was an unused example in ScrollView example, so I've added the example to RNTester App
## 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
-->
[Internal] [Added] - Added persistentScrollbar option example for ScrollView in RNTester App
Pull Request resolved: https://github.com/facebook/react-native/pull/31895
Test Plan: - RNTester App builds and shows example properly on Android
Reviewed By: sshic
Differential Revision: D29881126
Pulled By: mdvacca
fbshipit-source-id: 9e7e61c9d3f712cb767a78e729469fc95cb9953e
Summary:
Changelog: [internal]
Original commit changeset: 390e773283a7
Original diff didn't resolve crash T82119127. Let's back this out and investigate again.
Reviewed By: mdvacca
Differential Revision: D29909878
fbshipit-source-id: 54b054f4a5c97b8f6369f8790c2cf32a56c4fbd2
Summary:
**Context:**
Issue:
```java.lang.IllegalStateException: Message queue threads already initialized
at com.facebook.react.bridge.ReactContext.initializeMessageQueueThreads(ReactContext.java:100)
```
Possible root cause:
1, ReactContext.initializeMessageQueueThreads() can be called from different threads, so it's not thread safe
2, ReactContext.initializeMessageQueueThreads() is called again without detroying the threads.
**Fix:**
Make initializeMessageQueueThreads() thread safe. If this won't fix T93983690, I'll continue investigating with possible root cause 2.
Changelog:
[Android][Changed] - Make initializeMessageQueueThreads() thread safe
Reviewed By: GijsWeterings
Differential Revision: D29877386
fbshipit-source-id: 11b32c7184e9e8d6f882474fd607538df12276b7
Summary:
In T94154173, when calling ```EventEmitterWrapper->invoke()```, hybrid function ```invokeEvent``` is null, even if we checked that ```mHybridData``` is valid before calling ```invokeEvent```.
**Theory:**
```invoke()``` is called from ```mqt_js``` thread, ```desotry()``` is called from ```main``` thread, which cause multi-thread access of```mHybridData```.
So if ```desotry()``` is called after ```isValid()``` check and before calling ```invokeEvent()```, ```invokeEvent``` could be destroyed and is null.
I can reproduce with above theory:
{F633411001}
**Fix:**
Make functions synchronized so ```mHybridData``` can be thread safe.
Changelog:
[Android][Fixed] - Make mHybridData thread safe
Reviewed By: RSNara
Differential Revision: D29792453
fbshipit-source-id: 8b4c754d53ece933be7b2cf99c6cd026b39e24ad
Summary:
Changelog: [internal]
If task that is being executed schedules a new task with higher priority, the new task will be dropped from the queue. To fix this, we always check if the top of the queue is what was executed and only then remove it.
Example:
Let's say there is task A with priority "normal".
When we execute task A (which is not removed from the queue until later), it adds a task B with "immediate" priority.
So priority queue now has two tasks: [1: B, 2: A]
After task A finishes, inside workLoop, it will pop from top of the priority queue. But task A is no longer top of the priority queue (this is the bug) and it pops B. B is never executed and A is executed twice.
Reviewed By: ShikaSD
Differential Revision: D29841433
fbshipit-source-id: b2f1474fdfc7b3e2d42bae5b7f4ac7e6c3a37b54
Summary:
This diff exposes a new API in FabricUIManager called getInspectorDataForInstance. The goal of this method is to return React metadata for a Native view.
This data will be used from partner teams to build tools that uses React metadata in RN
Data returned from React: P429701924
changelog: [internal] internal
allow-large-files
Reviewed By: JoshuaGross
Differential Revision: D29747864
fbshipit-source-id: 8cb55573be08cb530f7e3c83eed8b4fcf43e7781
Summary:
This diff exposes a new struct InspectorData that will be used by FabricUIManager.getInspectorDataForInstance to return metadata of stacktraces.
See next diffs of the stack
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29764995
fbshipit-source-id: 6a2ab819623e379795e59002be0e4d40ac73b9a6
Summary:
This diff exposes a new API Expose new API RuntimeExecutor.executeSynchronouslyOnSameThread_CAN_DEADLOCK. This API will be used by the next diffs of the stack
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29764996
fbshipit-source-id: e6cd6799e16f2e47a353b7504d58d80aa49447d8
Summary:
Similar to D29786190 (https://github.com/facebook/react-native/commit/b0e39b2ed9b66b378eb75bee9e692fc801431ddd) on iOS, keeps cursor position constant to the end of the text whenever text changes without selection updates.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29879663
fbshipit-source-id: da1b50a99ae3b9ef796423146ba49e4172e286df
Summary:
With the advent of https://github.com/facebook/react-native/issues/29610, we are now able to use the `testID` view prop on Android in black-box testing framework through the view's `resource-id`.
But after testing it, I noticed that on the `TextInput`, `Slider` and `ScrollView` components, the `testID` prop was not exposed as the `resource-id` properly. The main issue was that those component was using the `AccessibilityDelegateCompat` instead of the `ReactAccessibilityDelegate`.
## Changelog
[Android] [Fixed] - Fix `testID` prop for `TextInput`, `Slider` and `ScrollView` components
Pull Request resolved: https://github.com/facebook/react-native/pull/31865
Test Plan: 
Reviewed By: mdvacca
Differential Revision: D29765333
Pulled By: yungsters
fbshipit-source-id: 2b8e362257e3e5fdcd20330280c588dabb44f28a
Summary:
Add INFO, and MENU key event support to Android TV
## Changelog
[Android] [Added] - Add INFO, and MENU key event support to Android TV
Pull Request resolved: https://github.com/facebook/react-native/pull/31884
Test Plan: We develop application that utilizes aforementioned events, we've made a build against react-native fork with these changes and it was working as expected. These changes just add 2 more button mappings, so I don't think it requires some extensive testing.
Reviewed By: mdvacca
Differential Revision: D29821996
Pulled By: yungsters
fbshipit-source-id: 5f97c29c9c29d6e3bafed352b8b65f0cb02f3f1d
Summary: - This is crashing too much in debug, which is good signal but making it harder to test, and test unrelated features.
Reviewed By: JoshuaGross
Differential Revision: D29857626
fbshipit-source-id: c52cfb6131747ae420b27de0591620fe79f47359
Summary:
Changelog: [Internal] - Update Animation examples to toggle useNativeDriver
There are issues when we toggle the native driver on and off. Where once off, the animations don't seem to update anymore, until we turn nativeDriver back on. See videos in testplan
Reviewed By: yungsters
Differential Revision: D29774939
fbshipit-source-id: cf6d70c1b574a87bb803510196dfb273b36de5e1
Summary:
* it says focusTextInput but the function name is blurTextInput
* probably the message was copy-pasted from `focusTextInput` where is the same error message.
Changelog: [Internal]
Reviewed By: arhelmus
Differential Revision: D29845922
fbshipit-source-id: 21fd3e572c32779c13f6909556153d07dc7a416f
Summary:
Tests like `CatalystSubviewsClippingTestCase` are intermittently failing due to registered callable modules not yet being registered.
Increasing the timeout to wait for the bundle execution to mitigate these intermittent failures.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D29835227
fbshipit-source-id: c9fe03202ad4028d3785216d50c6c173a56c6d84
Summary:
Added to C++ props, but realized this is already implemented using C++ state in Android, so added to C++ state to keep this diff simpler. Keeping the C++ props change for future use.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29805267
fbshipit-source-id: c1fe2dc34af8bc69352ee48a5d60ba998194e3f7
Summary:
Fix for https://github.com/facebook/react-native/issues/27952.
Noticed more than just `AUTOFILL_HINT_NEW_PASSWORD` were missing, this PR will support every `AUTOFILL_HINT_*` type.
## Changelog
[Android] [Added] - Added all autofill types to TextEdit
Pull Request resolved: https://github.com/facebook/react-native/pull/28008
Reviewed By: sturmen
Differential Revision: D29766235
Pulled By: mdvacca
fbshipit-source-id: d5171aef8092d37716fddcb6f3443637a4af8481
Summary:
Changelog:
[General][Added] - Added data field to markerPoint to allow callers to add additional arbitrary string data to logged points
Reviewed By: dmitry-voronkevich
Differential Revision: D29764274
fbshipit-source-id: b0d21e3b20a5353351424afb10c950f3e8689887
Summary:
This diff refactors the AndroidTextInput.AndroidTextInput.color prop to use SharedColor instead of int
The purpose of this change is avoid a crash when using PlatformColor on TextInput
changelog: [intenral] internal
Reviewed By: JoshuaGross
Differential Revision: D29810595
fbshipit-source-id: 2a5a9c5ae66e8d5de8adb1c89ea62489190a91ee
Summary:
I'm hunting down the source of a perf regression on a screen and think that having these systrace sections could be handy for this and future investigations.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29802969
fbshipit-source-id: f4030261da8888ddeb32ae41b9cf2b25af6a5583
Summary:
This change adds a series of snapshot tests to validate the render output of VirtualizedList in mixed scenarios. Jest timer mocks are used to measure rendering at different ticks. These test cases mostly center around realization logic, to help prevent regressions when chaning internal state representation.
## 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
-->
[Internal] [Added] - Add unit tests for VirtualizedList render quirks
Pull Request resolved: https://github.com/facebook/react-native/pull/31401
Test Plan: Ran the added UTs locally.
Reviewed By: lunaleaps
Differential Revision: D28017750
Pulled By: rozele
fbshipit-source-id: df9684c4ac80a8732f3e88e7496815127213832e
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769275
fbshipit-source-id: 7ac04f8a8f7e41ce8d43a81b25ebd063b3a9f3de
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769271
fbshipit-source-id: a20b4f99f00613c092461979b4afe61bdca9fe37
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Android react-native `TextInput` component does nothing if prop `keyboardType` is `url` value. This PR solves that problem.
## Changelog
[Android] [Added] - Add support to URI keyboard type in Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31781
Test Plan:
Before change:
{F630980679}
After Change:
{F630986399}
Reviewed By: lunaleaps
Differential Revision: D29517822
Pulled By: sshic
fbshipit-source-id: 1bda29584a3799570f34e772b5589b59ac80c524
Summary: Changelog: [Internal] RNTester to only show the module description. Example descriptions to follow
Reviewed By: yungsters
Differential Revision: D29571326
fbshipit-source-id: 973e0031fedee805e75c010fbf59833205801640
Summary:
In Fabric, we currently incur the cost of (frequently!) flushing non-Fabric UI updates, even if there are no non-Fabric views.
For now it is still possible to run both renderers at the same time, so we still largely continue to use the non-Fabric path, but only use UIImplementation if there is actually a RootView being managed outside of Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29724538
fbshipit-source-id: 0f1148870c04ca9aaed0edfd6b5c55a3756a2bd7
Summary:
Always create a new EventEmitter specifically for Fabric when initializing the Fabric JSI module.
Previously, we were (sometimes!) reusing the EventEmitter being used for the old renderer and they were shared. There doesn't seem to be a compelling reason to continue doing this, and Fabric has optimized EventEmitters that we can use instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29724537
fbshipit-source-id: 1b2c7a7d656e3fb86ddf98a6cf0f2e67dcbf8aef
Summary:
Updates CI and bot configurations to use `main` instead of `master`.
I will land this after I conver the repository to `main`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D29717337
fbshipit-source-id: 9aa9711df921cd7d3d94fbc3d8bb9d6e22abf5c1
Summary:
Updates documentation in React Native to reference `main` (or `HEAD` for URLs) instead of `master`.
Part of https://github.com/facebook/react-native/issues/31788.
Changelog:
[General][Changed] - Update documentation reference from `master` to `main` or `HEAD`.
Reviewed By: JoshuaGross
Differential Revision: D29717128
fbshipit-source-id: 0b0babd8407c6fd3d0e5431f6eaf976059731d6f
Summary:
This is crashing too much in debug, which is good signal but making it harder to test, and test unrelated features.
We have some good data about this internally and validated that it's useful; we can follow up on the logged soft exceptions without actually crashing now.
Changelog: [Internal]
Differential Revision: D29698447
fbshipit-source-id: 61387c18f17f76e5de60baa1fd3c94028229c0f6
Summary:
Fixes https://github.com/facebook/react-native/issues/31774.
This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.
This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.
The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.
https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95
This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.
## 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] - Fix support for blobs larger than 64 KB
Pull Request resolved: https://github.com/facebook/react-native/pull/31789
Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.
<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />
Reviewed By: ShikaSD
Differential Revision: D29674273
Pulled By: yungsters
fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
Extend the codegen script to allow arbitrary library name to be passed along as an argument, as well as the desired output directory for TurboModules and Fabric output.
New arguments:
- `:library_name`
- `:modules_output_dir`
- `:components_output_dir`
These arguments remain optional, and in their absence, the codegen will generate output that should work for the FBReactNativeSpec core native modules use case.
Internally, the script has been updated to use the correct path for the core modules use case as well as third party modules.
Changelog:
[Internal] - Extend the codegen script to take additional parameters
Reviewed By: RSNara
Differential Revision: D29243707
fbshipit-source-id: 1921bd3e5fd62d7cbf4c8b5089acfdd112f4b014
Summary:
This changeset is limited to whitespace and reordering changes that have no effect on the output or execution of the script. The sole purpose of this changeset is to apply these trivial changes prior to making some larger adjustments to the script in a followup.
With these changes, the ordering of statements more closely matches the order they are executed in (e.g. prepare_command before the script_phase).
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29527804
fbshipit-source-id: d161ed31321d68baf420457c7aa0aa23a6fc98d2
Summary:
Refactors how `Typeface` style and weight are applied in React Native on Android.
- Unifies all style and weight normalization logic into a new `TypefaceStyle` class.
- Fixes font weight support for the Fabric renderer.
- De-duplicates code with `TextAttributeProps`.
- Simplified normalization logic.
- Fixes a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
- Adds a new example to test font weights in `TextInput`.
- Adds missing `Nullsafe` and `Nullable` annotations.
- Clean up a bunch of obsolete inline comments.
Changelog:
[Android][Fixed] - Fixed a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
[Android][Fixed] - Fixed font weight support for the Fabric renderer.
[Android][Added] - Added a new example to test font weights in `TextInput`.
Reviewed By: JoshuaGross
Differential Revision: D29631134
fbshipit-source-id: 3f227d84253104fa828a5561b77ba7a9cbc030c4
Summary:
Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV (TVEventHandler)
## Changelog
[Android] [Added] - Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV
Pull Request resolved: https://github.com/facebook/react-native/pull/31837
Test Plan: We develop application that utilizes aforementioned events, we've made a build against react-native fork with these changes and it was working as expected. These changes just add 3 more button mappings, so I don't think it requires some extensive testing.
Reviewed By: TheSavior
Differential Revision: D29668706
Pulled By: yungsters
fbshipit-source-id: e4bd8dcf7de6b094ffdbbca12d875b85e468d49a
Summary:
Building from source in debug takes a very long time because native builds need to run for all supported architectures. It is possible to check which architecture the devices for which we are about to launch the app on are and build only for those. For most cases we can reduce the number of architectures we build for to 1 instead of 4, resulting in a large speedup of the build.
This is inspired by iOS which has a "Build for active architecture only" option. Since android doesn't really support this natively we can implement it here and also in react-native by reading the build properties that we pass and alter the abi we build for.
With fabric / codegen coming up I suspect that we might want to default to building c++ soon. This should ease the transition as builds won't be orders of magnitude slower.
See https://github.com/react-native-community/cli/pull/1388 for more context and how we use this new config to automatically detect running emulator architectures.
## Changelog
[Android] [Added] - Allow configuring ndk build architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/31232
Test Plan:
Tested by setting reactNativeDebugArchitectures with different values in gradle.properties. Checked the build logs to see which architectures are being built. Also made sure release builds are not affected by this value.
Clean build
reactNativeDebugArchitectures not set
824.41s
reactNativeDebugArchitectures=x86
299.77s
Reviewed By: mdvacca
Differential Revision: D29613939
Pulled By: ShikaSD
fbshipit-source-id: d20a23d1d9bbf33f5afaaf3475f208a2e48c0e1a
Summary:
Could not repro myself, but logview shows steady low number of crashes coming from this mid. Current fix returns early if the layout is not defined, relying on the following layout passes to position view correctly.
Changelog: [Android][Fixed] Exit early from layout in textview if text layout is null
Reviewed By: JoshuaGross
Differential Revision: D29636040
fbshipit-source-id: 876ce80222cbc5ff09450224f6808f9f6433c62a
Summary:
This is a followup to D29514800.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D29647688
fbshipit-source-id: d6b7be96f4e0ec6ae97c11685be7e44a558116f2
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary:
Gradle cannot find the property, because it is defined conditionally depending on env variable.
We want the default for it to be null instead, so the variable exists but doesn't change default NDK location.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D29634984
fbshipit-source-id: 4cf40a1c8d20b2f9008a637456bf9d228d2959d3
Summary:
Latest Android Gradle plugin doesn't respond to ANDROID_NDK env variable, so I propagated it explicitly and included with recommended `ndkPath` clause.
Changelog: [Internal]
allow-large-files
Reviewed By: fkgozali
Differential Revision: D29593132
fbshipit-source-id: 0785fe92385037d2d4cf290c2462b299800b6928
Summary:
Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack:
```
java.lang.NullPointerException: bio == null
at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java)
at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660)
at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566)
at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584)
at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480)
at okhttp3.internal.Util.closeQuietly(Util.kt:501)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74)
at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32)
...
```
This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized.
**The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1.
Related discussion:
[https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597)
[https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/)
cc dulmandakh fkgozali
## Changelog
[Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1.
Pull Request resolved: https://github.com/facebook/react-native/pull/31822
Test Plan: Manual & Automated from CI
Reviewed By: fkgozali
Differential Revision: D29590198
Pulled By: ShikaSD
fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d
Summary:
At risk of hiding errors, given the low volume, I think it's safe to cause this to crash in debug and continue gracefully in release-mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29618047
fbshipit-source-id: 19b19d8f6e27703227de4947ed01f7f2177f463b
Summary:
This diff fixes a NullPointerException that is caused when the method ReactInstanceManager.getViewManagerNames is called at the same time ReactInstanceManager is being destroyed.
Following the stacktrace I noticed that this crash can only happen when RN was destroyed by another thread while this method was being executed
This diff fixes the NullPointerException, but it doesn't fix the root cause race condition that cuases this bug
changelog: [Android][Fixed] Fix NullPointerException caused by race condition in ReactInstanceManager.getViewManagerNames method
Reviewed By: JoshuaGross
Differential Revision: D29616401
fbshipit-source-id: 6ae8ecdd765d2fe3529fef3237f08b182d8ed243
Summary:
It is possible for receiveEvent to be called concurrently with/after destruction of FabricUIManager. Drop events if we are able to detect that case.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29596271
fbshipit-source-id: 1fa50d9c3cff0bf578316d905966e1bdfffe94d1
Summary:
Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent.
T93269035 for details on why this is needed.
# How does this work?
In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render.
In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are:
1. `useLayoutEffect` with `setWaiting`
2. `useLayoutEffect`s in `useAnimatedProps`
3. `useEffect`s in `useAnimatedProps`
4. `useEffect` with `unsetWaiting`.
There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked.
## **Main concerns:**
1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?).
2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D29467458
fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
As a followup to T91209139, ship "state update scroll race" in code. This also ships it for HorizontalScrollView since it's been validated for vertical scroll views.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29595601
fbshipit-source-id: 64b6a23e2dab2c13123e132d9d899fb769d03172
Summary:
I suspect that T94864568 is caused by TouchEvents being dispatched after they've been recycled. This needs further analysis, but to stop the bleeding, we can drop events at the point they'd be dispatched before the crash, and log a soft error.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594749
fbshipit-source-id: f50df8df2125b83126616ceaf4e529127d154c7c
Summary:
Changelog: [Internal] Fix things in RNTester
* Make SectionList-contentInset example iOS only and update styling
* Fix a typo in SectionList-onEndReached example
* Fix module example styling and pressed state styling for Android
Reviewed By: kacieb
Differential Revision: D29571327
fbshipit-source-id: 5cbb68781536e21ca73ca22b01343379306babd4
Summary: Changelog: [Internal] Update title when navigating to an example
Reviewed By: kacieb
Differential Revision: D29545092
fbshipit-source-id: 7ce2f7d978601a5e11e2d60a8fd17be0249ce122
Summary: Changelog: [Internal] - iOS title jumps currently due to SafeAreaView re-mounting because of the layout structure we use. Simplified the layout tree
Reviewed By: kacieb
Differential Revision: D29545113
fbshipit-source-id: 9ed764c1c9f3da7c58baf8028454859bd50ded60
Summary:
It is unlikely but possible that the crash T94864568 is caused by a TouchEvent being initialized with a null MotionEvent. Regardless, we should guard against this case.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594750
fbshipit-source-id: 3a409b716a9f1eec8017002ae7e23273677e53ba
Summary:
Changelog: [internal]
Make sure correct text attributes are used inside of view command.
Reviewed By: sshic
Differential Revision: D29585943
fbshipit-source-id: 4748c843ff586f1dd42f3a89460afb624f9b371a
Summary:
Upgrade folly for the https://github.com/facebook/folly/pull/1593 fix for NDK 21 failure
## 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] [Changed] - Upgrade folly to 2021.06.28.00
Pull Request resolved: https://github.com/facebook/react-native/pull/31802
Test Plan:
`./gradlew :ReactAndroid:installArchives`
`./gradlew packages:rn-tester:android:app:installJscRelease`
`./gradlew packages:rn-tester:android:app:installHermesRelease`
Reviewed By: RSNara
Differential Revision: D29547027
Pulled By: ShikaSD
fbshipit-source-id: a10c7c65f459091bd0e7cca750a9b9e067189b73
Summary:
#import is common in Objective C, but is a vendor-specific extension of C++, which breaks MSVC compat. Fix an #import that made its way into C++ 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
-->
[Internal] [Fixed] - Replace #import in C++ Header with #include
Pull Request resolved: https://github.com/facebook/react-native/pull/31805
Reviewed By: sammy-SC
Differential Revision: D29553429
Pulled By: javache
fbshipit-source-id: d609981f0c6a756eafb58d50e98975625d08de21
Summary: Changelog: [Internal] - Move SectionList examples together. An interim state for next diff to add a 3rd level of navigation so each example is rendered in separate surface.
Reviewed By: kacieb
Differential Revision: D29480143
fbshipit-source-id: f7f10920bd4ab938665f17f0a80debaff55b9788
Summary:
Changelog:
[Internal] - Rename some types and components in RNTester to support work for tertiary levels of navigation.
module = component | api
moduleExample = an example of a certain feature a module
Reviewed By: kacieb
Differential Revision: D29381875
fbshipit-source-id: c348bcbb73aaf95e85928bb14080a097e685cc78
Summary:
Add a test case showing off a pressable sticky header to RNTester.
Note that this test case does not follow the styling of the other ScrollView Examples. I chose not to make it follow the styling because the existing examples need to be refactored later to not use custom buttons.
Changelog:
[General][Added] Add Pressable Sticky Header example to ScrollViewExamples in RNTester
Reviewed By: lunaleaps
Differential Revision: D29437827
fbshipit-source-id: 3ccee5df99bc6f00a04e1ecbd47fbe86b1eda4dc
Summary:
See comments in ReactClippingProhibitedView for details and motivation behind this new feature.
You may have a View class inherit from the ReactClippingProhibitedView interface in order to enable this feature for instances of that View type.
This can be added to Views that should /never/ be clipped from the View hierarchy - namely, TTRC components or other telemetry components that always need to be rendered in order for some feature to function.
Changelog: [Added] Opt-in mechanism to allow native Android Views to be marked as "not clippable", soft exceptions will be logged if these Views are clipped from the View hierarchy
Reviewed By: sshic
Differential Revision: D29472439
fbshipit-source-id: b3be53df836b452aed5dc40514ff585ce0ad812b
Summary:
@public
When PlatformColor is used with backgroundColor, this line would throw, as the object type is not convertible to int.
Changelog:
[Android][Fixed] - Fix Crash in ViewProps.isLayoutOnly
Reviewed By: JoshuaGross
Differential Revision: D29430151
fbshipit-source-id: a1fe801925430dad3a17871bdebb79d942775280
Summary:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
The Facebook app can have both bridge and bridgeless surface. Each type of surface has its own DevMenu. It's important to specify which DevMenu is being rendered, because not doing so can make for some confusing/frustrating devx (e.g: the bridgeless dev menu shows up for bridge surfaces: https://pxl.cl/1L1m7).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29439980
fbshipit-source-id: 24de1e6b44e5315c0cee0684d0db5df31514d3e2
Summary:
When using lock-holder objects, it is typically required to conduct all unlocking and relocking through them. That way, the RAII lock-holder does not attempt to unlock an unlocked mutex should the code throw after unlocking but before relocking.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D29238721
fbshipit-source-id: 2403ce8c9e86f96b56a35a456e017486a2854c74
Summary:
A future version of Flow will make the `indexed_access` option on by default. Turn it off explicitly in xplat until we're ready to deploy.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D29468755
fbshipit-source-id: 1ae5bb5f57315a2dab3072cc25689c3fc72ef871
Summary:
Immediately destroy EventEmitterWrapper on update instead of waiting for Java GC. This can resolve JSI::~Pointer deallocation crashes by clearing out EventEmitter and therefore EventTarget sooner, before RN teardown.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29415386
fbshipit-source-id: 05517bfd9e2cc2bd1b8c58d4f84c84f6f547268a
Summary:
This prevents us from leaking things via this static field.
Changelog: [Android][Changed] Native ScrollView listeners list maintains weak references to listeners to avoid memory leaks
Reviewed By: JoshuaGross
Differential Revision: D29317937
fbshipit-source-id: 4daeb8b5533cccaebcb03acf3d595dfa58de7883
Summary:
A CellRenderMask helps track regions of cells/spacers to render. It's API allows adding ranges of cells, where its otput be an ordered list of contiguous spacer/non-spacer ranges.
The implementation keeps this region list internally, splitting or merging regions when cells are added. This output will be used by the render function of a refactored VirtualizedList.
## 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
-->
[Internal] [Added] - Add "CellRenderMask" Region Tracking Structure
Pull Request resolved: https://github.com/facebook/react-native/pull/31420
Test Plan: Validated via UTs.
Reviewed By: lunaleaps
Differential Revision: D28293161
Pulled By: rozele
fbshipit-source-id: a5e4e2144a90387aabe0974650429018440abf67
Summary:
# See PR
https://github.com/facebook/react-native/pull/29728
# From PR Author
Using `PlatformColor` with border colors doesn't work currently when switching dark mode as the information is lost when converting to `CGColor`. This change keeps the border colors around as `UIColor` so switching to dark mode works.
```ts
<View
style={{
borderColor: DynamicColorIOS({ dark: "yellow", light: "red" }),
borderWidth: 1,
}}
>
...
</View>
```
This view will start with a red border (assuming light mode when started), but will not change to a yellow border when switching to dark mode. With this PR, the border color will be correctly set to yellow.
## Changelog
[iOS] [Fixed] - Allow PlatformColor to work with border colors
Pull Request resolved: https://github.com/facebook/react-native/pull/29728
Test Plan:
1. Assign a `PlatformColor` or `DynamicColorIOS` to a view border color.
2. Toggle between dark / light mode. See the colors change.
Reviewed By: lunaleaps
Differential Revision: D29268376
Pulled By: p-sun
fbshipit-source-id: 586545b05be0beb0e6e5ace6e3f74b304620ad94
Summary:
Changes the `ImageURISource` Flow type into an interface.
- This enables both objects and class instances to be subtypes of `ImageURISource`.
- This makes it invalid to spread `ImageURISource` as a type, so `interface X extends ImageURISource` can instead be used.
- This makes it invalid to spread `ImageURISource` as a value, so `getImageSourceProperties(x)` can instead be used.
- This makes it invalid to use `$Exact` with `ImageURISource`.
Changelog:
[General][Changed] - `ImageURISource` Flow type is now an interface instead of an object.
Reviewed By: timrc
Differential Revision: D29323508
fbshipit-source-id: 647c2f9b0bfead6d7e56bdb7108e623cbf8b6c89
Summary:
Changelog: [internal]
Original commit changeset: fa4d8944ad6b
Not sending onScroll events events to Paper has no effect.
Reviewed By: mdvacca
Differential Revision: D29229662
fbshipit-source-id: b84a2614bfd42c64ca67ca6a1cd9d0a815c11ad0
Summary:
This was causing an upload error in FB Dating, will need to re-land with the fix.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29320144
fbshipit-source-id: 5d09dd2171b5696afe89cffa064947f0a0bb413d
Summary:
String type seems to be already supported by codegen, but it was not included in the list for command methods.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29306740
fbshipit-source-id: 44b267c09f471dc601759ed2f7211a9e0fc1bb90
Summary:
Previously, RCTRootView added support for minimumSize as a workaround for some initial layout use cases. Going forward, we don't need this anymore. So let's add a proxy property but log an error if anyone calls it.
Changelog: [iOS][Changed] - Proxy minimumSize to RCTSurface as a noop
Reviewed By: JoshuaGross
Differential Revision: D29284227
fbshipit-source-id: 98b2dfc905c6c7e1adc03216e3a1cc3fda0a4133
Summary: Changelog: [Internal] - Animated.event from my limited understanding attaches Animated.Values to native views. In terms of animation, Animated.Values are already handled by AnimatedMock to skip interpolation.
Reviewed By: GijsWeterings
Differential Revision: D29241590
fbshipit-source-id: 98650883dad53d6f77dbc398ba0cac903194deca
Summary:
This diff refactors the Image component in order to log the component hierarchy stacktraces for images rendering non-fb sources
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29266451
fbshipit-source-id: 826230b1a18a5809b340ef0767d80a281e20477a
Summary:
Changelog: [internal]
Reland of D29131766 (https://github.com/facebook/react-native/commit/18165367b0347fc46cd52a6ac00afcf62d05cb30) which had to reverted because it caused binary size regression in instagram.
Size check for `automation_instagram_stablesize_release` and `automation_igtv_release`
{F626711916}
Reviewed By: JoshuaGross
Differential Revision: D29263302
fbshipit-source-id: cc8f5609ebaed9ddf666f7c57cdbf3dbf77a8f78
Summary: Changelog: [Internal] - Update expectations on RNTester's Animated Moving Box example. We don't restore defaults for the animated value on unmount. Also adds a Reset option to the example.
Reviewed By: kacieb
Differential Revision: D29143505
fbshipit-source-id: abb1e87530313cfbfe9c4985e651667d28589a67
Summary:
Because of T92179998, T93607943, and T93394807, we are still seeking resolution to tricky crashes wrt the use of EventEmitters.
I believe the recent spike is because of two recent changes: we pass in EventEmitters earlier, during PreAllocation; and we clean them up earlier, during stopSurface, to avoid jsi::~Pointer crashes.
Additionally, the gating previously added around the PreAllocation path was incorrect and led to more nullptrs being passed around as EventEmitters.
To mitigate these issues:
1) I am adding/fixing gating to preallocation and early cleanup paths
2) I am making EventEmitterWrapper more resilient by ensuring EventEmitter is non-null before invoking it.
3) I am making sure that in more cases, we pass a non-null EventEmitter pointer to Java.
4) I am backing out the synchronization in EventEmitterWrapper (java side) as that did not resolve the issue and is a pessimisation
There are older, unchanged paths that could still be passing in nullptr as the EventEmitter (Update and Create). As those have not changed recently, I'm not going to fix those cases and instead, we can now rely on the caller to ensure that the EventEmitter is non-null before calling.
Changelog: [internal]
Differential Revision: D29252806
fbshipit-source-id: 5c68d95fa2465afe45e0083a0685c8c1abf31619
Summary:
Changelog: [internal]
[This assumption](https://fburl.com/diffusion/yeqtvxru) in `~Scheduler` might not be completely correct. There can be a race between JS thread and main thread. With main thread settings animationDelegate_ to nullptr and JS thread reading the value. Even though they always happen one after the other, JS thread can have the value of animationDelegate_ in its cache line and changing it from main thread might not invalidate it right away.
Reviewed By: JoshuaGross
Differential Revision: D29237290
fbshipit-source-id: 6cb898caf7c225cf8162e7560921b563dec514b1
Summary:
Changelog: [internal]
[This assumption](https://fburl.com/diffusion/yeqtvxru) in `~Scheduler` might not be completely correct. There can be a race between JS thread and main thread. With main thread settings delegate_ to nullptr and JS thread reading the value. Even though they always happen one after the other, JS thread can have the value of delegate_ in its cache line and changing it from main thread might not invalidate it right away.
Reviewed By: mdvacca
Differential Revision: D29233092
fbshipit-source-id: 390e773283a745742d78152b9921c9ce21148a4c
Summary:
Custom tags made with `VM_MAKE_TAG` are meant to be used to tag
anonymous mappings, and should be passed in as the file descriptor.
We can't use them for file backed mappings.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D29038256
fbshipit-source-id: 11324a3e798e695709d7d340e84e5fe6f7ffaad3
Summary:
This PR bumps react-native-android docker image to version 4.0, which includes Android NDK 21 and other command line utilities used for CI.
## Changelog
[Internal] [Changes] - bump react-native-android to 4.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31741
Test Plan: CI is green again, especially test_docker
Reviewed By: mdvacca
Differential Revision: D29229964
Pulled By: ShikaSD
fbshipit-source-id: b50d376b94fe6d8f933a550133054b62267d21a7
Summary:
Because of the "disable preallocation of virtual views" experiment, for some reason, some views are being preallocated multiple times instead of not being preallocated at all.
This isn't really a problem for CreateView, and Preallocate is actually more strict here than it needs to be. I'm going to downgrade this to a soft error and will continue to analyze more. This is more of a perf issue than a correctness issue, so this should be fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29206416
fbshipit-source-id: 9490a1a705c2b39def3a3e56086634439543515e
Summary:
This diff adds logging to uncover what are the ReactNative screens that are rendering images using NON-Facebook domains
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29179990
fbshipit-source-id: 85f6380848d1ac1461419bc29c4666be389fb87a
Summary:
The native libraries are compiled outside of the usual Android build flow using separate CLI task. Because of that, shared native libraries may not exist when AAR is bundled, resulting in weird sequencing issues.
This change updates gradle dependency graph, executing RN native build before Android part (as it is done in RNTester already).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29209249
fbshipit-source-id: 36386c78996b1cd9b1731735e36e571199e9e81b
Summary:
Changes `ImageURISource` back to an object type.
It was changed to an interface by D27193522 (https://github.com/facebook/react-native/commit/05418f8fcc566fb9e394e5843f8680aaed35b8fa), but that is not the right direction for this type.
Changelog:
[Internal] - There was no changelog entry for this initially, so the revert can also be omitted.
Reviewed By: lunaleaps
Differential Revision: D29205798
fbshipit-source-id: 727ef70bbf47d14b163ecf5d6f31184da51c894a
Summary:
Adding a minHeight property messed up some screenshot tests. T93437971
I'm honestly not sure why this happened since that ScrollView container has a fixed height set of 300, so it shouldn't have changed heights... It didn't change heights in RNTester.
We should probably take the full example (including title etc.) from RNTester for our E2E tests to avoid these types of weird layout breakages in the future.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29201224
fbshipit-source-id: 30b98fa43d06eec1da345becc473690a3b075fb7
Summary:
Changelog: [internal]
We should be calling invokeUnique if event can be coalesced, not the other way around.
Reviewed By: JoshuaGross
Differential Revision: D29194528
fbshipit-source-id: 36e4ae71254420ef47deea436cad20eec09712fc
Summary:
Changelog: [internal]
Why does the crash happen?
We call method on invalid address. We crash on `std::weak_ptr::lock` because that's the first accessed ivar.
In D29020768 (https://github.com/facebook/react-native/commit/25e8fbe8ffa1c91522e91819a781434093f8b759), eventEmitter may be destroyed before an event is dispatched. Calling destroy on hybrid object destroys only C++ part.
Reviewed By: JoshuaGross
Differential Revision: D29194906
fbshipit-source-id: ae8d9d90aa8d98d69d29884e80d6b930b1e66870
Summary:
Changelog: [internal]
It is recommended to not use `using namespace` in the header file. It changes namespace for anything that imports the header file.
Also keeping imports in header file to minimum is recommended to lower build times.
Reviewed By: JoshuaGross
Differential Revision: D29131371
fbshipit-source-id: ad1868f6200c00023a62a00859d9a05140a12849
Summary:
This PR bumps NDK_VERSION to 21.4.7075529, and patches FileUtil.cpp from folly based on patch from https://github.com/facebook/folly/pull/1593. We can remove the patch once PR lands in Folly and bump Folly version in RN.
FYI, NDK 20 is deprecated and 21 is LTS release.
## Changelog
[Android] [Changed] - Bump NDK to 21.4.7075529
Pull Request resolved: https://github.com/facebook/react-native/pull/31731
Reviewed By: mdvacca
Differential Revision: D29166690
Pulled By: ShikaSD
fbshipit-source-id: 0792691404f718aaf5af1369f66f0cba046b4e20
Summary:
Changelog: [Internal] Upgrade glob-parent to 5.1.2 for vulnerability detection
Ran
```
yarn upgrade glob-parent@5.1.2
```
which then updated the package.json to add `glob-parent` as a direct dependency which I deleted.
then I ran
```
npx yarn-deduplicate yarn.lock; yarn
./scripts/update-oss-yarn-lockfile.sh // Not sure the purpose of this or the ordering
~/fbsource/xplat/third-party/yarn/tests/yarn-validate -d xplat/js/public
```
Reviewed By: GijsWeterings
Differential Revision: D29018576
fbshipit-source-id: b1e4f49a5f9c75ace290ed4f87eefeefdf80e58e
Summary:
## Context
In dev mode, Metro hijacks the JavaScript `console`, and prints all logs into the terminal running the Metro server.
## Problem
We have no way to distinguish between Bridge mode and Bridgeless mode logs. This makes it hard to tell catch warnings and errors are coming from bridgeless mode.
## Changes
- This diff adds a "NOBRIDGE" prefix to all React Native Metro logs coming from Bridgeless mode.
- Bridge mode console logs/warnings/errors are **unaffected**.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29152292
fbshipit-source-id: 257b8140327cfd7a0a10aa229bcb88117231e452
Summary:
Quick fix to fix a few test cases that had very small height buttons. (buttons became like this after flex: 1 was added to them in D29082450 (https://github.com/facebook/react-native/commit/f12f0e679dd6f1cdbd3c993d940a736ea1e952a3))
Added a minHeight to the buttons and added Views around groups of buttons.
Eventually we should update these examples to not use a custom button.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29145288
fbshipit-source-id: 238c298a25b33da662b4897399f82ad0aa29b9cd
Summary:
Changelog: [internal]
ScrollView's `scrollTo` command doesn't work in RTL. It sets the offset from left of the screen instead of right. This diff fixes this for Fabric only.
Reviewed By: JoshuaGross
Differential Revision: D29164056
fbshipit-source-id: f685d3e013f474f9b445112333d8f5ad7ed36ea7
Summary:
Rationale:
- This makes the element inspector button consistent with the Fast Refresh, Perf Monitor and other buttons in the DevMenu
- This makes the button more informative
Changelog: [Android][Changed] Rename the "Toggle Inspector" DevMenu item to "Hide/Show Element Inspector"
Reviewed By: JoshuaGross
Differential Revision: D29146871
fbshipit-source-id: 8e8c19217ea2ff2f1d176521aa22200058e7e643
Summary:
Changelog: [internal]
RuntimeScheduler needs to be created and registered in the runtime before any JS is allowed to run. This diff moves the registration right after the runtime is initialised.
This diff removes funnelling of Fabric events through RuntimeScheduler. This will be added in subsequent diff to keep the complexity low.
Reviewed By: JoshuaGross
Differential Revision: D29131766
fbshipit-source-id: cbc650f6fbce95e4b9c2c9695e8e0aba5beac635
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4
Summary:
I had an issue with the old version of the parser and upgrading it via `yarn resolve` solved it.
Pull Request resolved: https://github.com/facebook/react-native/pull/31490
Reviewed By: kacieb
Differential Revision: D29107863
Pulled By: PeteTheHeat
fbshipit-source-id: f8393dd52c10e6868e626cee75557b17b647bee8
Summary: Changelog: [Internal] - Update XHR upload example to new post test server. Created new toilet here: http://ptsv2.com/t/react-native and configured to return the link to the post data
Reviewed By: kacieb
Differential Revision: D29082824
fbshipit-source-id: 0cb502286addf1de3d5053f73173551ddd180a96
Summary:
Before the DevMenu would just open up as a DialogBox. After this change, the DialogBox will have a title. This should help distinguish between the Bridgeless DevMenu and the Bridge DevMenu.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29071185
fbshipit-source-id: 72533f10b73b36cd890fe152c6de901c867159f2
Summary:
With bridgeless mode enabled, there can be two instances of DevSupportManager. Previously, both of them wrote to the same files on disk. After this change, each instance will write the bundle to different files on disk.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29068794
fbshipit-source-id: 67270be17d084cc89ab618ea54f729f9b595b5f7
Summary:
Google Chrome debugging is only supported by the bridge. So, it makes sense to move it to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29031514
fbshipit-source-id: 4d6b6bb3bc298be5fe4d9f96c0d019676fe256db
Summary:
This diff prevents a NullPointerException caused by a race condition in the tear down of React Native.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29135942
fbshipit-source-id: 76d5a1f16c2ca63a146b56c761f5f9595dcfe2a5
Summary:
The mount items executed before the view attach can fail with the RetryableMountingLayerException, which we should either retry or skip the item. This change updates logic for such items to catch these exceptions.
Instead of passing `MountingManager` to execute the items, this change now passes a reference to the `MountItemDispatcher` (abstracted through interface to resolve cycle between the manager and dispatcher). The dispatcher executes the queue directly and schedules retry together with the next batch.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29068063
fbshipit-source-id: 04030b21db188d5617c3448322d25ba77d5fbb9f
Summary:
Fixes https://github.com/facebook/react-native/issues/27099
When you upload a local file using XHR + the `FormData` API, RN uses `RCTNetworkTask` to retrieve the image file data from the local filesystem (request URL is a file:// URL) ([code pointer](https://github.com/facebook/react-native/blob/master/Libraries/Network/RCTNetworking.mm#L398)). As a result, if you are uploading a local image file that is in the app's directory `RCTNetworkTask` will end up using `RCTLocalAssetImageLoader` to load the image, which reads the image into a `UIImage` and then re-encodes it using `UIImageJPEGRepresentation` with a compression quality of 1.0, which is the higest ([code pointer](https://github.com/facebook/react-native/blob/4c5182c1cc8bafb15490adf602c87cb5bf289ffd/Libraries/Image/RCTImageLoader.mm#L1114)). Not only is this unnecessary, it ends up inflating the size of the jpg if it had been previously compressed to a lower quality.
With this PR, this issue is fixed by forcing the `RCTFileRequestHandler` to be used when retrieving local files for upload, regardless of whether they are images or not. As a result, any file to be uploaded gets read into `NSData` which is the format needed when appending to the multipart body.
I considered fixing this by modifying the behavior of how the handlers were chosen, but this felt like a safer fix since it will be scoped to just uploads and wont affect image fetching.
## Changelog
[iOS] [Fixed] - Avoid re-encoding images when uploading local files
Pull Request resolved: https://github.com/facebook/react-native/pull/31457
Test Plan:
The repro for this is a bit troublesome, especially because this issue doesn't repro in RNTester. There is [some code](https://github.com/facebook/react-native/blob/master/packages/rn-tester/RNTester/AppDelegate.mm#L220) that is to be overriding the handlers that will be used, excluding the `RCTImageLoader`. I had to repro this in a fresh new RN app.
1. Create a blank RN app
2. Put an image in the folder of the app's install location. This would be similar to where files might be placed after an app downloads or captures an image.
3. Set up a quick express server that accepts multipart form uploads and stores the files
4. Trigger an upload via react native
```
const data = new FormData();
data.append('image', {
uri:
'/Users/arthur.lee/Library/Developer/CoreSimulator/Devices/46CDD981 (https://github.com/facebook/react-native/commit/d0c8cb12f21604fd9730e275a52816d7fd00a826)-9164-4925-9025-1A76C0D9 (https://github.com/facebook/react-native/commit/1946aee3d9696384d38890269ea705cafd472827)F0F5/data/Containers/Bundle/Application/B1E8A764-6221-4EA9-BE9A-2CB1699FD218 (https://github.com/facebook/react-native/commit/1c92b1cff623ea3f3b78238b146ab001626ef305)/test.app/test.bundle/compressed.jpg',
type: 'image/jpeg',
name: 'image.jpeg',
});
fetch(`http://localhost:3000/upload`, {
method: 'POST',
headers: {'Content-Type': 'multipart/form-data'},
body: data,
}).then(console.log);
```
5. Trigger the upload with and without this patch
Original file:
```
$ ls -lh
total 448
-rw-r--r-- 1 arthur.lee staff 223K Apr 29 17:08 compressed.jpg
```
Uploaded file (with and without patch):
```
$ ls -lh
total 1624
-rw-r--r--@ 1 arthur.lee staff 584K Apr 29 17:11 image-nopatch.jpeg
-rw-r--r--@ 1 arthur.lee staff 223K Apr 29 17:20 image-withpatch.jpeg
```
Would appreciate pointers on whether this needs to be tested more extensively
Reviewed By: yungsters
Differential Revision: D28630805
Pulled By: PeteTheHeat
fbshipit-source-id: 606a6091fa3e817966548c5eb84b19cb8b9abb1c
Summary: Changelog: [Internal] - Remove picker from Modal example in RNTester in prep for deprecating Picker from RN
Reviewed By: kacieb
Differential Revision: D29082452
fbshipit-source-id: 01ee5ae2d0978721f7229d824f23cfbccfaf2813
Summary: Changelog: [Internal] - Remove Picker from accessibility example as a first step to deprecate Picker from react-native
Reviewed By: kacieb
Differential Revision: D29082453
fbshipit-source-id: d1d6eb0514453126351b41c2ca5d72d2c81f5dc9
Summary:
This feature is still causing some number of crashes, though prod impact is not yet determined. For safety I'm adding a feature flag so we can disable this if necessary.
Changelog: [internal]
Reviewed By: kacieb
Differential Revision: D29117957
fbshipit-source-id: 3b19bac9dd00735f51f5c9cba606378b2a62975e
Summary:
In the refactor in D28933824 (https://github.com/facebook/react-native/commit/6b601db8b83337415113a123d780fb64aa67af42), an early return was accidentally deleted. This causes incorrect measurements to be returned, which can break a few things including Text Inline Views.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29122235
fbshipit-source-id: 76c8991132e22cd4e0fc1c277447c4dba751adfb
Summary:
Changelog: [internal]
RuntimeScheduler can be accessed before any Fabric surface is rendered. Therefore, it needs to be created and installed in the runtime at the start up of the runtime.
Reviewed By: JoshuaGross
Differential Revision: D29091848
fbshipit-source-id: ff75ef8c4882550795e5d4a258355b651cb0e637
Summary:
If function name is an empty string then it would fail to parse the line. And not only that, it would cause the entire stack to be lost. This fixes the issue by replacing `.+?` with `.*?`.
For example this line fails to parse:
```
at global (:2:4)
```
Changelog:
[General][Fixed] - Fixed bug parsing hermes call stacks when the file name is empty
Reviewed By: yungsters
Differential Revision: D29063192
fbshipit-source-id: 604e457af51f852fe547e6424283631ae148897d
Summary:
Changelog: [internal]
Using keyboard's autocomplete did not insert space at the end of the word.
Reviewed By: fkgozali
Differential Revision: D29085654
fbshipit-source-id: 35fee726ea7d2030fdfa64300e045a303ea98ce9
Summary:
Changelog: [internal]
To prevent wrong TextInput becoming first responder, force a resign when preparing for a reuse.
Reviewed By: JoshuaGross
Differential Revision: D29085923
fbshipit-source-id: 246cdf0628f914c3928cc9c7499d029b77684f2c
Summary:
Rewrites `ReactNativeStyleAttributes` so that it is statically defined.
This means it will no longer require a handful of modules that defines `prop-types` only to use their keys.
Functionally, this should be equivalent to what was there before.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019308
fbshipit-source-id: 47f85a8c7703a133c68c20c7f3e14e1026ce4ff2
Summary:
Simplifies the Flow type for `ReactNativeStyleAttributes`, an internal module.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019311
fbshipit-source-id: cf95dac4b8c2261812cc1d753255dfb905540759
Summary:
Deletes `StyleSheetValidation` because it is `prop-types` in disguise.
Changelog:
[General][Removed] - `StyleSheet.create` will no longer do DEV-time validation.
Reviewed By: TheSavior
Differential Revision: D29019310
fbshipit-source-id: bfe886d8dc09a1aa8dac4a73bfd62f481e3eb9e9
Summary:
Removes the unnecessary dependency from `DeprecatedTextInputPropTypes` on `Text`. Just use `DeprecatedTextPropTypes` directly.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017596
fbshipit-source-id: b816c2261bf473e02473d84984cfb3d5a63ec8c1
Summary:
Moves `ImagePropTypes` out of `Image.android.js` in preparation for some cleanup.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017076
fbshipit-source-id: e7d3d6533f69dc2c54e7c25e215648d7c7ff1840
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Adding runtime type information adds greatly to the binary size, so react-native-windows builds without it. But some parts of the fabric code currently uses dynamic_cast, which means to use fabric we have to build with RTTI turned on. This PR removes the usages of dynamic_cast that are hit in release builds, which should allow react-native-windows to turn off RTTI in release builds.
Required for: https://github.com/microsoft/react-native-windows/issues/7981
One thing to note, the comment in ShadowNodeTraits indicates that core was reserving the first 16 bits. I'm adding two more. Is that ok? Should core be reserving more for future use?
## 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
-->
[Internal] [Fixed] - Remove uses of dynamic_cast in release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31694
Test Plan:
Verified that I can build react-native-windows with Fabric in release, without RTTI.
Boot / clicked around in RNW RNTester
Reviewed By: sammy-SC
Differential Revision: D29040383
Pulled By: JoshuaGross
fbshipit-source-id: e49286e59c4ba54faf0b4de5e244dfa1f7c3f193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement.
## Changelog
[Android] [Changed] - Bump Fresco to 2.5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31699
Test Plan: CI is green
Reviewed By: TheSavior
Differential Revision: D29031847
Pulled By: passy
fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344
Summary:
In the CONTRIBUTING.md file, when a user clicks on the hyperlink for either issues(line 33) or pull requests(line 34), they are directed to a filler page which has them click on an additional hyperlink to take them to the page they are looking for. The only thing present on the filler page is a hyperlink. So, in terms of usability, it does not make sense to have users go through an extra click to get to the page they want. I have changed the hyperlinks of Issues(line 33) and Pull Requests(line 34) to takes users directly to Triaging GitHub Issues and Managing-Pull-Requests
## Changelog
[GENERAL][CHANGED]-See lines 33 and 34 of https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md
Pull Request resolved: https://github.com/facebook/react-native/pull/31696
Test Plan: First, I ensured that the code lints and the test suite passes. For testing the links, I opened my fork in GitHub and opened the CONTRIBUTING.md file. I clicked on both hyperlinks to ensure that they both worked properly. No tests were added for this code.
Reviewed By: lunaleaps
Differential Revision: D29046728
Pulled By: TheSavior
fbshipit-source-id: 99ec989938660102aefa07862542dc9a007359ce
Summary:
As title
Changelog:
[General][Changed] Update Image.[android|ios].js to use import from instead of require
Reviewed By: TheSavior, yungsters
Differential Revision: D29003824
fbshipit-source-id: 0f98c730b1bd9cb581d2fcf6f4c0e911bb8c24b5
Summary:
added .hprof file is generated when building a release apk and it's size is > 300 MB, and we don't want it to be in the repo
## Changelog
[General] [Changed] - Remove .hprof
Pull Request resolved: https://github.com/facebook/react-native/pull/31679
Reviewed By: yungsters
Differential Revision: D28967470
Pulled By: PeteTheHeat
fbshipit-source-id: 521f653428ebdd2a33fb251ce18c4faada53bf27
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
https://github.com/facebook/react-native/issues/31345
The issue to` android/app/src/main/res/values/styles.xml.`
In the base application theme, there is an explicitly added item
`<item name="android:textColor">#000000</item>`
This leads the `textColor` of the app to be black even though the theme is actually DayNight.
A permanent fix would be to not have this item added by default when creating a new project, as it is buggy behavior
## Changelog
[General] [removed] - line `<item name="android:textColor">#000000</item>` in this file `android/app/src/main/res/values/styles.xml `for the inital setup
Pull Request resolved: https://github.com/facebook/react-native/pull/31487
Test Plan: Removing this has fixed the issue for me.
Reviewed By: yungsters
Differential Revision: D28966678
Pulled By: ShikaSD
fbshipit-source-id: 57c6b4b7b5f11847ea6e611c7567c0c03133c79d
Summary:
This PR sets project wide Kotlin version to 1.4.21, supported in Buck https://github.com/facebook/buck/tree/dev/third-party/java/kotlin.
We had to specify version for both kotlin-dsl and kotlin('jvm') plugins to remove version mismatch warnings in **react-native-gradle-plugin**. Also I expect more Kotlin code in RN, so instead of specifying version for each sub-project it's better to have project wide setting.
We don't need to load Kotlin in react-native-gradle-plugin because Kotlin is available RN project wide.
## Changelog
[Internal] [Changed] - Project wide Kotlin version set to 1.4.21
Pull Request resolved: https://github.com/facebook/react-native/pull/31645
Test Plan: Everything works as expected, no visible change for developers.
Reviewed By: yungsters
Differential Revision: D28991440
Pulled By: ShikaSD
fbshipit-source-id: 971fa6f50c12d916a56d0dcde7c65299496fb68a
Summary:
In T92179998, there is a crash when an EventEmitterWrapper is deallocated after the JS VM is torn down, and the EventEmitterWrapper tries to free its JSI::Pointer reference (double-free).
To make sure this happens less/not at all, free EventEmitterWrappers on ViewState when a view is deleted, instead of waiting for all of RN to be torn down.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29020768
fbshipit-source-id: 9d72a23bc9966992ef56c1e3ee523405d4333194
Summary:
Changes React Native CI (both Sandcastle and Circle CI) to use `OS=latest` instead of a hardcoded version number.
This reduces the number of hardcoded configurations needed to be updated for new Xcode versions by one.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D29013193
fbshipit-source-id: 3c081de1b74a130867b2a599d3e7333846c96cf7
Summary:
Fixes https://github.com/facebook/react-native/issues/30502.
This PR fixes a crash caused by a `NullPointerException` when updating the `snapToOffsets` property.
I noticed this crash on production, you'll find the stack trace below.
Cause: `snapToOffsets` is annotated `Nullable` but there are no nullability check before calling `snapToOffsets.size()`.
## Changelog
[Android] [Fixed] - Fixed a crash when updating `snapToOffsets` to a null value
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/31681
Test Plan:
Passing `snapToOffsets={undefined}` to a `FlatList` used to crash on Android. Not anymore.
## Stacktrace
```
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'snapToOffsets' of a view managed by: RCTScrollView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:102)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int com.facebook.react.bridge.ReadableArray.size()' on a null object reference
at com.facebook.react.views.scroll.ReactScrollViewManager.setSnapToOffsets(ReactScrollViewManager.java:107)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
```
Reviewed By: ShikaSD
Differential Revision: D28965864
Pulled By: JoshuaGross
fbshipit-source-id: f08f1df371c1892935e1290806cc67d34394203b
Summary:
Changelog:
[Internal] - Replace `useImperativeHandle` usage with new `useMergeRef` which will keep both the forwarded and internal ref handle up to date (in case the instance ever changes). That being said, this change was not motivated in fear of a stale ref but more an intention to show that `useImperativeHandle`'s use case is more about creating a selective API and `useMergeRef` is better suited for publishing ref updates.
Reviewed By: yungsters
Differential Revision: D28950632
fbshipit-source-id: 594afda02693545aab77f24566180c338b58bb8b
Summary:
`jest/create-cache-key-function` should be installed as part of the react-native package since it is used by the jest config. Running jest currently errors unless this package is somehow transitively installed.
## Changelog
[General] [Fixed] - Add missing jest/create-cache-key-function dep root package.json
Pull Request resolved: https://github.com/facebook/react-native/pull/31668
Test Plan: Run jest in a RN app.
Reviewed By: rubennorte
Differential Revision: D28953697
Pulled By: lunaleaps
fbshipit-source-id: a0862ea3b2bc93a72bb4a0f976ef486a66112ec5
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## 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] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
Adds homebrew on m1 to path before evaluating `command -v brew` to support nvm on m1 via homebrew.
## Changelog
[General] [Changed] - Find node on m1 via homebrew node managers
Pull Request resolved: https://github.com/facebook/react-native/pull/31678
Test Plan:
On M1, use nvm via homebrew. Create a RN project and it'll fail to build iOS app. Apply the patch, and build will succeed.
cc: dulmandakh as discussed in https://github.com/facebook/react-native/pull/31622
Reviewed By: ShikaSD
Differential Revision: D28967386
Pulled By: PeteTheHeat
fbshipit-source-id: 3d4a41dd3cc25fbf77778b16468a236b141d1259
Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
This PR aims to enable support for foreground ripple in Pressable. This makes it possible to show ripple on top of custom child components like Image as shown in the below example.
## 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] [Added] - Support for foreground ripple in Pressable
Pull Request resolved: https://github.com/facebook/react-native/pull/31632
Test Plan:
- Pass property useForeground: true in android_ripple config to verify the changes.
https://user-images.githubusercontent.com/23293248/120111371-4cecbf00-c18f-11eb-8acb-d10718d5483c.mov
Reviewed By: kacieb
Differential Revision: D28926493
Pulled By: yungsters
fbshipit-source-id: 12a6ba71a7dc6ed60fbaeb651f015cace38e03b1
Summary:
Completes example with the swipeable card with swipe-out animation.
The example also tries to reuse the underlying views by ensuring the card reuses the same React node and changes position based on zIndex.
Changelog:
[General][Added] - Added swipeable cards example to RNTester to validate JSResponderHandler
Reviewed By: lunaleaps
Differential Revision: D28492604
fbshipit-source-id: c9fe757100bea9dc787cd754af81e37dc4f084d4
Summary:
Changelog: [internal]
Add an option to make all measure calls asynchronous.
Reviewed By: JoshuaGross
Differential Revision: D28934444
fbshipit-source-id: 57a320b03add0182b4646b13ed4b692b899ddea3
Summary:
Changelog: [internal]
Move call of getRelativeLayoutMetrics to lambda.
The reason for this is so we can make all of "measure" calls asynchronous.
Reviewed By: JoshuaGross
Differential Revision: D28933824
fbshipit-source-id: f77fc1d06d5cd4706d52a02253a3e754e8e8fa44
Summary:
This is a re-land of D28810022 (https://github.com/facebook/react-native/commit/7e9c741146e1b3aa542ecfe138765e95ddddac3f), which was reverted due to T92179998. The fix is in D28938530. This issue could also be resolved by preventing more view preallocations (D28811419 (https://github.com/facebook/react-native/commit/8ca18f0b602a08cd9a5c9f6681bb5dc74e0d34f7)).
---
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued.
Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28938637
fbshipit-source-id: c9e290a24ed15c28881e3eead4a5f580f66b288f
Summary:
allow-large-files
This bumps the flipper dependencies to 0.91.
Fresco deps are not in mavenCentral jet, so picked those from bintray, but pinged the team and they'll follow up on it. See also: https://github.com/facebook/fresco/issues/2603
This primarily bumps to the latest pods we have everywhere, which solves several build issues, like reported in https://github.com/facebook/react-native/issues/31480
After this change it should no longer be needed to pass custom version overrides to `use_flipper`, as the defaults will be up to date.
In the template project, I changed the version rangers to exact numbers, so that results of `react-native init` are more consistent / predictable over time, as suggested in the discord channel by Brent
In the long term we are investigating whether we can remove most of the transitive deps by not using RSocket, which is a bigger project plan that should help reduce build issues and times, especially on iOS.
cc priteshrnandgaonkar passy kelset
## Changelog
[general][changed] - [iOS] Update Flipper to 0.91.1, fixed iOS build support for i386, `use_flipper!()` will no longer need custom overrides to build with XCode 12.5
Pull Request resolved: https://github.com/facebook/react-native/pull/31562
Test Plan:
_N.B. Locally tested in XCode 12.4 only, but bumped versions have been confirmed to work on 12.5 before by others_
* React Native CI
* Flipper CI with same versions of deps: https://github.com/facebook/flipper/actions/runs/863607686
* Was able to connect from both Android and iOS to Flipper. Couldn't really test further due to a bundling error I didn't understand, suggestions welcome
Reviewed By: fkgozali
Differential Revision: D28623601
Pulled By: mweststrate
fbshipit-source-id: 22130d07821569851956453c4ee6a594b6b83928
Summary:
Creates a `useAnimatedProps` hook that is compatible with concurrent mode, and uses this in `createAnimatedComponent_EXPERIMENTAL`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28390393
fbshipit-source-id: d8aa471507a5d096832b93caf63a24f71733deda
Summary:
Creates `useRefEffect` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862440
fbshipit-source-id: 50e0099c1a3e0a0f506bf82e68984fc5a032f101
Summary:
Creates `useMergeRefs` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862439
fbshipit-source-id: 60eac7bcd6cceb06ee82181386b4712d642f5404
Summary:
Adds the `react-test-renderer` Flow definition (via `flow-typed`) so it can be used from tests with Flow enabled.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D28922375
fbshipit-source-id: 9b1be69f1b281bb3c248ca272cf2527baf154e2a
Summary:
Remove `defaultProps` from `Picker` of components, replace it with destructuring assignment.
## 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
-->
[JavaScript] [Changed] - Remove defaultProps from picker
close https://github.com/facebook/react-native/issues/31603
Pull Request resolved: https://github.com/facebook/react-native/pull/31644
Test Plan: all test suite and CI passes.
Reviewed By: TheSavior
Differential Revision: D28886320
Pulled By: lunaleaps
fbshipit-source-id: d88a922dffeebe2bce019250d460b5e43a0af562
Summary:
When maxLength is defined in <TextInput>, if the last character at max length is an emoji, the content of the input is cleared:
{F620865178} {F620865237}
Related Github issues:
https://github.com/facebook/react-native/issues/10929https://github.com/facebook/react-native/issues/10964
## Root cause:
When NSString was created, unicode characters were 16-bit long, so Objective-C considers every unicode character as 16-bit. However, unicode was later extended to more than 16bit, for example, emojis, which causes NSString substring method cuts off at the wrong position.
Example:
```
NSString *s = @"abc{emoji:1f601}";
NSInteger len = s.length; //length is 5 (as {emoji:1f601} occupies two 16-bit characters)
NSString *s3 = [s substringToIndex: 3]; //s3 is "abc"
NSString *s4 = [s substringToIndex: 4]; //s4 is null!
```
If string s, "abc{emoji:1f601}", is entered in <TextInput>, which has max length 4, it will truncate the string to the first 4 characters, "cutting" the emoji in half which causes encoding error and returns null. The text input is cleared.
## Solution:
If the character at max length is longer than 16-bit, truncate the character BEFORE it instead. In the previous example, truncate till index 3 instead of 4. The end result will be "abc" and the emoji is dropped.
## Changelog:
[iOS] [Fixed] - <TextInput> content is reset when emoji is entered at the max length
Reviewed By: p-sun
Differential Revision: D28821909
fbshipit-source-id: 4720d864970b554160ed5388f65b352ce95a6199
Summary:
The RN OSS release process includes manual testing that a new template app can be started under various platforms, JS engines, etc. This should ideally be automated, to help reduce wasted engineer-time, and to allow reliably increasing release velocity.
`react-native-windows` does already have tests to create and build template projects across our matrix, but they do not do any runtime validation on the newly created app. Adding a `testID` to the new app screen header gives us something to search for in black-box testing to validate that the app started successfully. This should help catch cases where a sample project in repo has changes not reflected in a newly created template app.
## 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
-->
[Internal] [Added] - Add testID to NewAppScreen Header Component
Pull Request resolved: https://github.com/facebook/react-native/pull/31652
Test Plan: Did not manually validate the change, though did check that `ImageBackground` forwards props to `Image`, and that `Image` is aware of `testID` and will forward to the native component.
Reviewed By: kacieb
Differential Revision: D28907197
Pulled By: p-sun
fbshipit-source-id: db3974294afba25878383f1955cad37b69d95da3
Summary:
This fixes how ES modules are handled in Jest tests in the react-native codebase.
They caused some problems before because `import` statements weren't inlined as `require` calls were, so there were some errors in tests when migrating from CommonJS to ESM.
This changes the transform that Jest uses to inline import statements the same way, so we can migrate everything without issues in tests.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D28899692
fbshipit-source-id: 027690f57ca3b5613c261a1089c0635af76662b2
Summary:
Changelog: [internal]
Add a feature flag to enable yielding in RuntimeScheduler
Reviewed By: JoshuaGross
Differential Revision: D28903226
fbshipit-source-id: c361ca144a2d531e8aa671bc8875bce075e13a2c
Summary:
setJSResponder/clearJSResponder have been in use in prod for a while and are stable. Ship them in code.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28889894
fbshipit-source-id: 1c42526cd890d528062eeb50761fc49cc6109d76
Summary:
Changelog: [internal]
This is a life cycle issue where LayoutManager outlives the runtime. To fix this, we need to destroy `_accessibilityProvider` before the runtime. The way to do it is to destroy it inside `prepareForReuse` which is guaranteed to be called before runtime is destroyed.
Reviewed By: JoshuaGross
Differential Revision: D28898257
fbshipit-source-id: 9d2c0b9cebd9889caa4328f9ee7f005928bbf55a
Summary:
Root nodes doesn't have a ComponentDescriptor that can be looked up via this mechanism, and we probably shouldn't be animating Root nodes anyway (?). This is a debug-only assert but could be causing issues in production.
The fix is simple - just don't animate any changes to a root node.
Changelog: [Internal]
Reviewed By: Nick177
Differential Revision: D28856396
fbshipit-source-id: 43fa0aa723b03b031fee22e0563eb63cc86239b3
Summary:
Verifies interaction between PanResponder and ScrollView with JSResponderHandler.
Also showcases how to create a swipeable card with scrollable content.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28093313
fbshipit-source-id: 8ffbe734119912326c471412f4f5e096f64e87cc
Summary:
Several accessibilityRole strings are hardcoded to only English on Android. Swap them to just use the platform constants. This way, TalkBack will handle translations.
This change swaps roles "search", "button", and "togglebutton" roles to use the platform description.
Changelog:
[Android][Changed] Localize "search", "button", and "togglebutton" accessibility roles by using the platform roles
Reviewed By: lunaleaps
Differential Revision: D28077246
fbshipit-source-id: 5b88a6fd7e78b3426506f253b823ecca0608c4bc
Summary:
Gradle has been showing below warning for a while, and this PR fixes the warning using maven-publish plugin, thus taking us one step closer to Gradle 7.x.
> The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.9/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins
Configured maven-publish plugin according to https://developer.android.com/studio/build/maven-publish-plugin, also added **installArchives** task for backwards compatibility.
## Changelog
[Internal] [Changed] - use maven-publish plugin to build and publish Android artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/31611
Test Plan: ./gradlew :ReactAndroid:installArchives will create **android** directory for local maven repository with **react-native** package.
Reviewed By: yungsters
Differential Revision: D28802435
Pulled By: ShikaSD
fbshipit-source-id: 7bc7650a700e1a61213c5ec238bcb24fdca954db
Summary:
A few places in RNTester where using hard coded color values, which meant the UI looks broken in dark themes.
The area behind the bookmark button was using a solid color png file, which I've replaced with a color from the theme object.
## Changelog
[Internal] [Fixed] - Fix a couple of places RNTester is using non-theme values
Pull Request resolved: https://github.com/facebook/react-native/pull/31479
Test Plan: Verified in RNTester in react-native-windows in light+dark theme.
Reviewed By: TheSavior
Differential Revision: D28290192
Pulled By: rozele
fbshipit-source-id: 78192200ac2dc8629759c10f8e8b3ec2f6699acd
Summary:
Don't allocate large arrays on stack when copying native pointers, use heap based array.
Today the code copies the native pointers on the stack, since it may be too big, lets make sure to use heap based allocating using std::vector.
This array is afterwards converted into a reversed map from index to pointer, so it is heap based anyhow.
Changelog: [Internal] Don't allocate large arrays on stack when copying native pointers, use heap based array
Reviewed By: Andrey-Mishanin
Differential Revision: D28747213
fbshipit-source-id: da69b4b2d0960fdade9f07f44654b30d6dacc43a
Summary:
Removes an extra amount of 10dp margin on the top of each example.
Changelog:
[General][Fixed] - Remove excess spacing in RNTester examples.
Reviewed By: kacieb
Differential Revision: D28799736
fbshipit-source-id: 40c8db203f8119359ccc8c40fc0a6424de5afc5e
Summary:
Minor changes to the `Animated` examples index module to make the static typing a bit more intuitive.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799742
fbshipit-source-id: f798631081538e79fc58377105db4e47b9728843
Summary:
Minor reorganization of `AnimatedGratuitousApp` to be a separate top-level directory in `examples/`, like `Animated`.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799737
fbshipit-source-id: b0329e420d6eae912e91d0d74b68ac299c9bd9f3
Summary:
Creates an experimental stub implementation of `createAnimatedComponent` to be implemented in future commits.
Changelog:
[Internal]
Reviewed By: lunaleaps, kacieb
Differential Revision: D28799738
fbshipit-source-id: dc3fbee557db353de6807bd87561f8f372d7cab5
Summary:
Sets up an injection mechanism for experimenting in production with an alternate implementation of `createAnimatedComponent`.
This will be used to implement and refine a new `createAnimatedComponent` that is compatible with concurrent rendering.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28799739
fbshipit-source-id: 46ba2dd6137f7bf73ce8a659698533ed3985516f
Summary:
While it is possible in the React Native implementation for Android to provide a custom configuration for HTTP requests, the iOS implementation does not allow for the same customization. As the NSURLSession used for HTTP requests on iOS is configured internally, one may for instance not supply an ephemeral configuration for HTTP requests. Other concerns related to the given problem have been addressed in the community: https://github.com/react-native-community/discussions-and-proposals/issues/166. I did make a PR with an RFC in the community repo, but after some discussion in the said repo, I figured I might as well make a PR with a suggestion :)
## Changelog
[iOS] [Added] - Allow for configuring the NSURLSessionConfiguration
Implement a C function `RCTSetCustomNSURLSessionConfigurationProvider` which gives the app programmer the ability to provide a block which provides an NSURLSessionConfiguration that will be used for all HTTP requests instead of the default configuration. The provided block will be called when the session configuration is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/27701
Test Plan: Unsure if this can be tested in any other way than uncommenting the example code in `RNTester/RNTester/AppDelegate.mm`.
Reviewed By: yungsters
Differential Revision: D28680384
Pulled By: JoshuaGross
fbshipit-source-id: ae24399955581a1cc9f4202f0f6f497bfe067a5c
Summary:
Bumped react-native-community/cli to v6 to update metro to 0.66 to fix fast-refresh issues
Also updated the manual test e2e script for easier testing. (using npm install would create a package-lock.json and conflict with yarn.lock)
## 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] [UPDATE] - updated react-native-community/cli to v6 (hence updating metro to 0.66)
Pull Request resolved: https://github.com/facebook/react-native/pull/31597
Test Plan: I've tested fast-refresh works with / without hermes
Reviewed By: TheSavior
Differential Revision: D28852660
Pulled By: yungsters
fbshipit-source-id: af338e4dd1d52c62949d71f42773963d89bca9db
Summary:
The RuntimeExecutor that Fabric gets from the bridge doesn't call JSIExecutor::flush(). In the legacy NativeModule system, we're supposed to flush the queue of NativeModule calls after every call into JavaScript. The lack of this flushing means that we execute NativeModule calls less frequently with Fabric enabled, and TurboModules disabled. It also means that [the microtask checkpoints we placed inside JSIExecutor::flush()](https://www.internalfb.com/code/fbsource/[62f69606ae81530f7d6f0cba8466ac604934c901]/xplat/js/react-native-github/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp?lines=427%2C445) won't be executed as frequently, with Fabric enabled.
Changelog: [Android][Fixed] - Flush NativeModule calls with Fabric on Android, on every Native -> JS call.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D28620982
fbshipit-source-id: ae4d1c16c62b6d4a5089e63104ad97f4ed44c440
Summary:
Since moving Switch to a function component it is no longer possible to get the native switch ref. This adds forwardRef so it is possible again.
## Changelog
[General] [Fixed] - Fix Switch ref forwarding
Pull Request resolved: https://github.com/facebook/react-native/pull/31629
Test Plan: Tested the change in an app using react-native-gesture-handler, which tries to set a ref on Switch. Also made sure flow still passes.
Reviewed By: TheSavior
Differential Revision: D28839605
Pulled By: lunaleaps
fbshipit-source-id: 1fee86145caeabb60c0010bb9062dddca419f7ca
Summary:
Virtual views that are flattened and don't "FormsView" on-screen should not be preallocated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28811419
fbshipit-source-id: 949dcbf4cf3791355c58af785603b35fa50f3f02
Summary:
This hack should not be necessary. It should be fixed at Differ or LayoutAnimations level if there are existing issues there.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810021
fbshipit-source-id: 98b8d2ae9991ad527a3b3e90943d75063b2a4496
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
As suggested by motiz88 on D28421692 (https://github.com/facebook/react-native/commit/883e0d5752b952c829c8d45504d3532f52bb272f), make sure to still report fatal "warnings".
Changelog:
[General][Fixed] Report fatal errors even if its `type` is "warn".
Reviewed By: motiz88
Differential Revision: D28815228
fbshipit-source-id: 8d3b77958ef687a4ce64bdfccbf6ce2dc5557eaf
Summary:
API of Jest transformers is changing in Jest 27. The new version of `jest/create-cache-key-function` handles both current versions of the API and the upcoming 27 API.
Ref: https://github.com/facebook/jest/pull/10834
## 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
-->
[Internal] [Changed] - Use version of `jest/create-cache-key-function` compatible with upcoming Jest v27 release
Pull Request resolved: https://github.com/facebook/react-native/pull/30637
Test Plan: I've tested locally that it works with both a `jest@latest` and `jest@next` release.
Reviewed By: yungsters
Differential Revision: D28807361
Pulled By: hramos
fbshipit-source-id: 9d9ccb4d7f91b30bcbf3d28202bb74ce7499a91b
Summary:
Creates a new RNTester example to verify facebook/react-native#31538 (D28631465).
Changelog:
[Android][Added] - RNTester example for adjusting text with dynamic layout.
Reviewed By: kacieb
Differential Revision: D28779870
fbshipit-source-id: 5297a823645d1e9e35d4c86b491f3c225ecc9543
Summary:
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued. Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810022
fbshipit-source-id: ae4c8b4eefe619d9a99fa5f90f612d6dd4880da5
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Removes stale feature flag that was in production for a couple of months. Fix helped to decrease number of crashes significantly, so we can remove it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28757995
fbshipit-source-id: 375da09c11f265e8bbe03cd99de1b83f168420ce
Summary:
Touch event logic has been recently modified to contain surfaceId only in the new renderer. This change aligns OSS tests that have been failing for them.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28749961
fbshipit-source-id: 483ab3ac97bbdc4f1fbdb2a8c699ef060cca9f77
Summary:
Adds logs to indicate that MountItem was queued instead of executed.
Also moves logging of preMount items to dispatcher for consistent logging with other items.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28690203
fbshipit-source-id: 14d24f0bebb97a810127f5187b4d46f66b6c836f
Summary:
Add more detail about requesting review in the contribution guide.
In the GAAD initiative it's particularly useful to know when certain PRs need our attention so wanted to highlight the code review process to remind contributors to request reviewers.
## Changelog
[General] [Added] - Added more detail about the review process
Pull Request resolved: https://github.com/facebook/react-native/pull/31590
Test Plan: Grammar, clarity review
Reviewed By: TheSavior
Differential Revision: D28719869
Pulled By: lunaleaps
fbshipit-source-id: 9213fefbe602588f9e5cee7ba240b93bc7f291b5
Summary:
Changelog: [internal]
There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells.
To make sure the race doesn't happen, state must be updated before dispatching onScroll event.
Android has implemented a different mechanism to tackle this issue in D28558380 (https://github.com/facebook/react-native/commit/b161241db2ef74d2e4bff36d4972f5f0312dcc44).
Reviewed By: JoshuaGross
Differential Revision: D28642737
fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
Summary:
Changelog: [internal]
collapsable was not passed to Fabric because view configs are built using Paper' ViewManagers.
Reviewed By: p-sun
Differential Revision: D27944688
fbshipit-source-id: 73a5646e25b3dd7a1a9dfc1079406047ab483d88
Summary:
Changelog: [internal]
Use getter function instead of accessing ivar. This makes for clearer APIs.
React part is implemented in https://github.com/facebook/react/pull/21553
Reviewed By: JoshuaGross
Differential Revision: D28675372
fbshipit-source-id: cf99f8482067bfc0fd57d39fda9656abd665bb69
Summary:
Replaces deprecated `translateX` and `translateY` props with `transform` prop in PanResponderExample. This fixes the RNTester example for react-native-windows, which doesn't support the deprecated props.
Changelog:
[General][Fixed] - [RNTester] Use transform prop in PanResponderExample
Reviewed By: kacieb
Differential Revision: D28676164
fbshipit-source-id: 437912b5abf6ca74f0043ded7a902a5938bcf93a
Summary:
Changelog: [internal]
Introduces synchronous access to the runtime from RuntimeScheduler.
At the moment, this is not used anywhere.
In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor.
Reviewed By: mdvacca
Differential Revision: D28024380
fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary:
Changelog: [internal]
This is a mechanism that will guess event's React priority based on other events ongoing on the platform.
If an event happens within span of ContinuousStart -> ContinuousEnd and its category is unspecified, we deduce it's React priority to be default. All other events are discrete.
Special case: `onScroll`, which is always treated as "Default".
Reviewed By: JoshuaGross
Differential Revision: D28485060
fbshipit-source-id: d2eae63dbcf03271dfed97128a1590dd165a3ce2
Summary:
Changelog: [internal]
Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes.
Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`.
Reviewed By: JoshuaGross
Differential Revision: D28572283
fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
Upgrade jsc-android to latest stable version. Hopefully this should finally fix https://github.com/facebook/react-native/issues/25494.
Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable
## Changelog
[Android] [Changed] - Upgrade jsc-android to 250230.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31304
Test Plan: Launch app with new jsc-android and see everything works fine.
Reviewed By: TheSavior
Differential Revision: D28630503
Pulled By: yungsters
fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary:
JS side expects the property name to be "actionName", and this change updates it to that.
Changelog:
[iOS][Fixed] - Use actionName in accessibility event callback
Reviewed By: JoshuaGross
Differential Revision: D28645999
fbshipit-source-id: 0e7a6c3e6c1b6c998f4b53fd89c744c84083dfb1
Summary:
Android was using rawProps received from JS, so no updates needed.
Updated iOS callsite to use the name of the action.
Changelog:
[General][Fixed] - Parse accessibilityAction props into object instead of string
Reviewed By: mdvacca
Differential Revision: D28614407
fbshipit-source-id: 209134f8fac65ca8516039e10ea502e57d52a7a7
Summary:
`isColorMeaningful` is the only place in xplat code that currently uses `colorComponentsFromColor`, which assumes that a color is an RGBA value. When implementing `PlatformColor` for windows, where colors might be complex patterns or effects, I'd like to keep the details of `SharedColor` isolated within `SharedColor`. This change moves `isColorMeaningful` into `color.cpp`, where each platform can provide an implementation that takes into account its platform specific color capabilities.
See https://github.com/microsoft/react-native-windows/pull/7801 for an example of window's SharedColor which can be either an RGBA value, or a name of a native color/brush.
## 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
-->
[Internal] [Changed] - Move isColorMeaningful to platform specific code
Pull Request resolved: https://github.com/facebook/react-native/pull/31557
Test Plan: This shouldn't change any of the code, its just moving the existing function - normal CI/automation should be plenty of validation.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D28557698
Pulled By: mdvacca
fbshipit-source-id: 2a94850fe9c5037598107e1307f4153cee6491fb
Summary:
Changelog: [internal]
My suggestion is to simplify event dispatching to only two options, synchronous and asynchronous.
Why?
- Fabric has only been using one queue, `AsynchronousBatched`.
- Batching happens even on `AsynchronousUnbatched`. It just batches events until JS thread starts processing them instead of waiting for the main run loop.
- It will make it easier to reason about the code in the future once we start utilising different priorities for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D28603472
fbshipit-source-id: 14e3a9c15a012c550dc16a044c31d722051a2bdc
Summary:
Changelog: [internal]
Originally added in D17814260 (https://github.com/facebook/react-native/commit/ffc7ec992c66417039b0fa14f1afd54a9cd2f882) to make parallax effect work in Dating.
This diff hides it behind a flag so we can properly evaluate what's the cost of sending scroll events to Paper.
Reviewed By: JoshuaGross
Differential Revision: D28608283
fbshipit-source-id: fa4d8944ad6b5e767363e231942f13fec9d18cb5
Summary:
EventDispatcherImpl uses synchronized blocks all over to make it thread-safe. I'm concerned about the perf implications of this and creating contention between JS and UI threads.
This is locked behind a feature flag.
Enabled only for Fabric in StaticViewConfig mode, and a feature flag, for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28591331
fbshipit-source-id: ea8f93a2e1343ce37fa78690dcb62fe03594120f
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Accessibility service does not announce "selected" on accessibilityState = {selected: true} of the Button Component.
Issue link - https://github.com/facebook/react-native/issues/30956
## 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] [Added] - Add accessibilityState prop to Slider component
Pull Request resolved: https://github.com/facebook/react-native/pull/31145
Test Plan:
Verified accessibility states are read by voiceover and talkback. Some state values aren't handled by iOS and have been identified.
Added snapshot tests to test accessibilityState.disabled = disabled values
`js1 test Slider-test`
Reviewed By: yungsters
Differential Revision: D28337723
Pulled By: lunaleaps
fbshipit-source-id: 72a54d8d9dcf1fafb9785c81da99f32a21f3df00
Summary:
Changelog: [internal]
Extend LeakChecker so it is available on Android (or any other platform as it is completely in C++ now).
Reviewed By: JoshuaGross
Differential Revision: D28600243
fbshipit-source-id: c77a003e3ffc6171e61c998508c9f34f10bb65ca
Summary:
After D28435078, TurboModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the TurboModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435429
fbshipit-source-id: fe945d616b97ed89f48b914b064e518b122a7b7b
Summary:
After D28435078, NativeModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the NativeModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435430
fbshipit-source-id: 1ce00c3fb3c63b024d7e24895ff96c541a6fa654
Summary:
Changes `ExceptionsManager` in React Native so that errors with a `type` property equal to `'warn'` are not reported.
This change is banking on the fact that `type` is a non-standard and uncommon property on `Error` instances. If this ends up being problematic, we can instead change this to use a `unstable_type` or `unstable_level` property instead.
Changelog:
[General][Changed] - ExceptionsManager will no longer report exceptions with `type === 'warn'`.
Reviewed By: motiz88
Differential Revision: D28421692
fbshipit-source-id: 3ca19e29f32c8c5cad6dac637dcb930944fb24ed
Summary:
While testing 0.65, we noticed issues with hermes on iOS in the template projects
These changes create a subspec to the react-core pod so that it can access hermes header correctly.
## Changelog
Not applicable
Pull Request resolved: https://github.com/facebook/react-native/pull/31559
Test Plan: I've ran e2e manual test. Tested RNTester manually also. Then tested a project inited with hermes and the default template
Reviewed By: mhorowitz
Differential Revision: D28564642
Pulled By: Huxpro
fbshipit-source-id: cfcb3363254f62a0e514ec99159b32f841ee4463
Summary:
FlatList relies heavily on onScroll events + the measure API. In Fabric, usage of `measure` relies on C++ having an accurate view of the current scroll position of the ScrollView.
We already have a mechanism for updating the scroll position in C++ using UpdateState. But, it is only used currently at the /beginning/ and /end/ of scrolling, and UpdateState is not called /during/ scrolling at all.
This means that we will see a series of events like this while scrolling:
```
Scrolling begins
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 0
JS event: onScroll x=0, y=0
JS event: onScroll x=0, y=100
JS event: onScroll x=0, y=200
...
JS event: onScroll x=0, y=1000
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 1000
```
Notably, not many C++ state updates are queued; and the last one is queued AFTER the JS event is sent. The last JS event and UpdateState will race, which means that sometimes the C++ update will /lose/ and C++ will have an inaccurate view of the world when FlatList receives the onScroll event and calls `measure`.
My proposed solution, gated behind a feature flag, is to delay /some/ onScroll events until the C++ UpdateState has made its way back to Java, and send UpdateStates more frequently. The balance here is that UpdateState is a relatively expensive operation, so we probably still want to call it /less/ than we call onScroll. This means that `measure` will still return some incorrect results but will return correct results more frequently. Win?
Changelog: [Internal[
Reviewed By: mdvacca
Differential Revision: D28558380
fbshipit-source-id: 11c7cd714fae67ee5a94c4413be988481413ec03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
While we are still waiting for Android results, we can safely ship this on iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28542478
fbshipit-source-id: 2673cc4bea0edbc7e4211be7bfec9779205d721b
Summary:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Cleans up `reactConsoleErrorHandler` in `ExceptionsManager` using modern language features, and fixes a minor edge case with how warning-like errors are handled.
Changelog:
[General][Fixed] - Avoid downgrading `console.error` when passed warning-like objects.
Reviewed By: GijsWeterings
Differential Revision: D28418488
fbshipit-source-id: 394e8608c2c81c794c9a0fc155142dcfcfe1c661
Summary:
WITH_FBREMAP was an experiment that is no longer needed. Just disabling the flag for now, the code will be deleted in a separate commit.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28467996
fbshipit-source-id: cb7bc00ea0b9d6e82219dda5148ab29978ddc83d
Summary:
Changelog:
[Internal] - In internal e2e testing, json.stringify is unstable and will occasionally re-order keys. Fix so it's consistent across tests
Reviewed By: kacieb
Differential Revision: D28397174
fbshipit-source-id: 0f2db697d245654c88c3dff3d083bc82890d4bc1
Summary:
It's not supported, and building with libc++ using its unstable ABI
exposes the issue. Include the header to get the complete type.
Changelog: [Internal]
Reviewed By: lanza, sammy-SC
Differential Revision: D28405500
fbshipit-source-id: 65e039a465d8d736eaecb89e82895889fd2379ca
Summary:
Bump the cli version as it caused an issue when running the e2e tests for the 0.65 release
It will fix an incorrect template path being generated and fail the test
## Changelog
Bumped react native cli ? Already in the changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/31548
Test Plan: This is just a yarn.lock update targeting the cli
Reviewed By: fkgozali
Differential Revision: D28513554
Pulled By: Huxpro
fbshipit-source-id: 2957cb9e0d994894c3ef10260ee6167f857bdeef
Summary:
FBJNI version have been updated recently and the new version is available on Maven Central, so we can remove this exception.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28355443
fbshipit-source-id: 1b3d88b668fed12deb786d36672f07dc98709aa0
Summary:
When we initialize RCTDevLoadingView, we dispatch_sync to the main thread. There isn't anything in the NativeModule that requires us to initialize it on the main thread. So, this diff toggles requiresMainQueueSetup to NO. This should mitigate this prefetch-related deadlock: T90970812. Please read the task comments for the rationale.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28490715
fbshipit-source-id: 7efceb392ec9e0cabe7f7cd8867cf4b07f8fff19
Summary:
Minor cleanup of `ReactFiberErrorDialog` with no behavior changes.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28423265
fbshipit-source-id: 796777ca2c26d6d7cfae956299786151c74e937f
Summary:
This diff creates a ReactFeatureFlag to initialize MapBufferSo file during Fabric initialization.
This is necessary to be able to compare properly Mapbuffer vs ReadableNativeMap (because ReadableNativeMap c++ files is already included in the bridge so file)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D28436044
fbshipit-source-id: 338e1bb72b5313dc29a309e1b0e979e7c8bd1c18
Summary:
This protocol is no longer necessary, because we introduced the bridgeless-compatible abstraction: RCTCallJSModuleMethod.
Changelog: [iOS][Removed] - Delete RCTCallJSModuleMethod protocol
Reviewed By: fkgozali
Differential Revision: D28395446
fbshipit-source-id: 0ad606ce7935b24bfbd6e0c2f35fbde480a8a6ff
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
This diff has the bridge attach RCTCallableJSModules to our TurboModules.
Changelog: [Internal]
Differential Revision: D28395450
fbshipit-source-id: 6861e56f7fa0c009cded41f80b569de57a383e83
Summary:
This diff has the bridge attach RCTCallableJSModules to our NativeModules.
Changelog: [Internal]
Differential Revision: D28395447
fbshipit-source-id: 01ca62442013826d28ba0f710e28a5963f5efb65
Summary:
This is a Bridgeless-compatible API to allow our NativeModules to call JSModule methods.
Changelog: [iOS][Added] - Introduce RCTCallableJSModules API for NativeModules
Differential Revision: D28395448
fbshipit-source-id: b7929ba8b4cc4410361961b45efa23c76baacd24
Summary:
Changelog: [internal]
Only moves methods around so public and private methods are grouped together.
Reviewed By: JoshuaGross
Differential Revision: D28381588
fbshipit-source-id: dae7f493b99845f66070689270bc7aef958fbecd
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27938536
fbshipit-source-id: 750b0e21e0ecbd7aa5a14885ebc70aae82203bd4
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27937665
fbshipit-source-id: 434d78c95ccf23d8da41186d0dae91bff4eda384
Summary:
Fixes https://github.com/facebook/react-native/issues/28517
Animated.loop needs to reset the animation after each iteration but currently, natively driven animations are not getting reset properly.
## 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] - Fix natively driven animations not getting reset properly
Pull Request resolved: https://github.com/facebook/react-native/pull/29585
Test Plan: Tested within RNTester
Reviewed By: kacieb
Differential Revision: D28383538
Pulled By: yungsters
fbshipit-source-id: 40790ad8f825c402afc3515ef6afc00570704109
Summary:
When RCTDevLoadingView is created, it checks to see if the bridge is loading. If so, displays the loading banner with the bundleURL. This logic is better placed in the bridge, because the bridge is also responsible for updating progress on the DevLoadingView.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28301524
fbshipit-source-id: fb6c259b546d8cd9e08568a88c7046d06c70ed6f
Summary:
Call `onDropViewInstance` on all Views when stopSurface is called.
We used to do this but stopped doing it ~6 months ago. This did not cause any prod issues but is not correct.
This allows product code to do cleanup upon view deletion.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28388929
fbshipit-source-id: a8f06d4b1b12a11a907667e0a837c653db035941
Summary:
react-native-windows runs with a more strict set of warnings as errors. This fixes a bunch of warnings being hit while compiling core react-native code as part of react-native-windows. In particular warnings about mismatched signed/unsigned comparisons, lossy conversions, and variable names that conflict with names in outer scopes (yoga has a global for `leading` and `trailing` that conflicts with some local variable names)
## Changelog
[Internal] [Fixed] - Fix various C++ warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/31399
Test Plan: I've run these changes in react-native-windows. -- Shouldn't have any functionality difference.
Reviewed By: sammy-SC
Differential Revision: D28290188
Pulled By: rozele
fbshipit-source-id: 2f7cf87f58d73a3f43510ac888dbcb9ab177d134
Summary:
See comments inline for motivation. It's not safe to use viewtag of an Event to infer whether or not the view is in a Fabric or non-Fabric RootView.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28365566
fbshipit-source-id: 187ddcc5d5a43a31a71232fdb2f1f5b334bec8c2
Summary:
Changelog: [internal]
Cloning root shadow node didn't always trigger a layout because node was not dirtied. Checking if layoutConstraints are changed when cloning RootShadowNode
Reviewed By: JoshuaGross
Differential Revision: D28352238
fbshipit-source-id: 536afdeddf5d2019950ceb6664c10ee593ab5f02
Summary:
This is a follow up to my diffs from a couple weeks ago bumping folly version to 2021.04.26. Unfortunately, those diffs did not work when Hermes was enabled, and Flipper was disabled, this fixes that.
I've tested the matrix of Hermes enabled/disabled and Flipper enabled/disabled.
Changelog: [iOS] Fix Hermes + no Flipper build on Xcode 12.5
Reviewed By: yungsters
Differential Revision: D28325790
fbshipit-source-id: e58e1ba4730e7989c48dfd2aae06d91c1d3687db
Summary:
This diff is a follow up of D28360679 (https://github.com/facebook/react-native/commit/e3367354cc93f17b830ed8dc601dff5e87748dd1), here we refactor the access of ReactFeatureFlags from C++ to use methods instead of fields
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28362066
fbshipit-source-id: caed5e7fddeb6c0d9846fb037152befa8f1ed5c2
Summary:
Since we are now using ReactFeatureFlag from C++, we need to ensure redex doesn't strip its fields.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28360678
fbshipit-source-id: 74604e2d008a056c161d8b6ab8f5b30807087d9e
Summary:
This diff refactors the way we are populating the 'MapBufferSerializationEnabled' context cointainer key to use ReactFeatureFlags instead of MobileConfig.
This is necessary to make sure we always use a consistent value between C++ and Java. e.g. to prevent SEV like S230730 set different values in java and c++ code
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28360679
fbshipit-source-id: baef9d53f84de25c5671483dcd995674bfa61984
Summary:
Builds on previous diff. Instead of running a single animation to completion, queues up an animation and then spams mutations that could conflict with the animation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28357892
fbshipit-source-id: 6ca83a56dded629d8a1444360f1d02037661a5ef
Summary:
Add unit tests for Layout Animations.
This first batch generates a random mutation, then animates it to completion.
I found one issue with UPDATE+REMOVE+INSERT animation consistency. That shouldn't cause any crashes in production, but is a chance to improve consistency of mutations overall - and could in theory point to memory corruption, though it's somewhat unlikely.
I ran with randomized seeds, found issues, fixed them, re-ran to ensure issues were fixed, rinsed and repeated. At the end I was able to run dozens of times (with random seeds) and found nothing.
The next step is to repeatedly generate mutations that conflict with ongoing animations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28343750
fbshipit-source-id: c1c60d89a31be3ac05d57482f0af3c482b866abe
Summary:
JetBrains [republished](https://youtrack.jetbrains.com/issue/IDEA-261387) trovej to Maven Central, so we can now use that dependency instead
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28355119
fbshipit-source-id: 9dd35b946bf9a09b06d831159be72fa9e5e94837
Summary:
Updates Gradle script to include new version of folly (synced to iOS update)
Adds fmt and libevent as well as some boost ASM sources to enable compilation of folly futures.
Changelog:
[Android] Updated folly to 2021.04.26
Reviewed By: fkgozali
Differential Revision: D28124377
fbshipit-source-id: d44c5a1ded5ee7ad514a9df14ea2ba326d4aa0e3
Summary:
Changelog: [internal]
Fix accessibility when entire text node is a link
Reviewed By: JoshuaGross
Differential Revision: D28325749
fbshipit-source-id: 9ac68b802f13d028b5cdb6cae7bdae5f4924fc07
Summary:
This check will never pass because `this._propsAnimated` contains an instance of `AnimatedProps`, but `nextProps` contains an object literal containing the new props.
Changelog:
[Internal]
Reviewed By: JoshuaGross, TheSavior, kacieb
Differential Revision: D28271627
fbshipit-source-id: c563eec1eeaee5eb84bb01525313b46db502225a
Summary:
Decouples `__attach` from the constructor in `AnimatedProps`.
This change will enable the instantiation of `AnimatedProps` (and subsequent invocation of `__getValue()`) without having to trigger side effects until after mount or update. This is important in order for `Animated` to ever become safe for Concurrent Mode.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28271628
fbshipit-source-id: 6ccfed6de79382cecdfa6939c7dad3134e1ecaaa
Summary:
Changelog: [internal]
Prevent unnecessary copy of `RawEvent::eventTarget` which is `shared_ptr` inside `EventQueue::enqueueEvent` by passing in rvalue.
Reviewed By: JoshuaGross
Differential Revision: D28323219
fbshipit-source-id: 7f62e17df5c4264a15adf58f6142155a76de7aae
Summary:
This diff deletes ReactFeatureFlags.useViewManagerDelegatesForCommands, this has been enabled in prod for 9+ months
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28265338
fbshipit-source-id: 2f07cb83d6ef9191f9ebea52e230490ef98d6e2d
Summary:
Support ScrollAway in ReactScrollView for Fabric/non-Fabric.
Changelog: [Android][Added] Support for ScrollAway native nav bars added to ReactScrollView
Reviewed By: mdvacca
Differential Revision: D28308855
fbshipit-source-id: 9a922159ef50fb7c8e9c484a4b97ca57ab248496
Summary:
Having to import `useContext` every time is annoying, so this just creates a convenience function to get it.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D28258305
fbshipit-source-id: 7293478f9baa11711a541f987225108871688e0e
Summary:
This diff deleted the ReactFeatureFlags.useViewManagerDelegates, this has been enabled for 9+ months
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28265339
fbshipit-source-id: f5c97e77ca4fc72d2e2b8f891e800e362177d67a
Summary:
RCTJSInvokerModule invokeJS can do the work done by setInvokeJSWithModuleDotMethod. Therefore, this diff reduces the surface area of Venice, and gets rid of setInvokeJSWithModuleDotMethod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232947
fbshipit-source-id: aa0d8497a1e0fba29109ca86a39de5d9e5b10c9c
Summary:
This protocol is no longer necessary, because we migrated all our NativeModules to synthesize bundleManager = _bundleManager;
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28232441
fbshipit-source-id: 0bd54fa49299574db8a75247c97b466476037f4f
Summary:
This diff migrated RCTDevSettings to the RCTBundleManager, which works both in bridge/bridgeless mode. RCTDevSettings is the last TurboModule that synthesizes the bundleURL. So, after this diff, we can get rid of the RCTBundleHolderModule protocol.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232320
fbshipit-source-id: ab53278fea0ea7e025cf748be62bc5d610593e7f
Summary:
I added onPressIn & onPressOut props to Text to help implement custom highlighting logic (e.g. when clicking on a Text segment). Since TouchableOpacity can't be nested in Text having custom lineHeights without bugs in some occasions, this modification helps to replicate its behavior.
## Changelog
[General] [Added] - Add onPressIn & onPressOut props to Text
Pull Request resolved: https://github.com/facebook/react-native/pull/31288
Test Plan:
```
const [pressing, setPressing] = useState(false);
<Text
onPressIn={() => setPressing(true)}
onPressOut={() => setPressing(false)}
style={{ opacity: pressing ? 0.5 : 1 }}
/>
```
Thanks in advance!
Reviewed By: yungsters
Differential Revision: D27945133
Pulled By: appden
fbshipit-source-id: 8342ca5f75986b4644a193d2f71eab3bc0ef1a5f
Summary:
this is a quick refactor of the string tags used in UIManagerHelper
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28243264
fbshipit-source-id: c32c9908d40e6184d7e940b14c9782799db3f891
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:
- Fixed iOS codegen script incorrectly splitting root project paths that contain spaces
https://github.com/react-native-community/releases/issues/214#issuecomment-793089063
iOS builds were failing on 0.64.0-rc.4 for projects that contained spaces in the root directory path. The error logs pointed to the codegen script not being able to find a directory. The path was being split at a space in one of the folder names. This PR modifies the codegen script to include the spaces and use the entire project root path.
## Changelog
[Internal] fix: codegen script failing for iOS builds on projects with spaces in root directory path
Pull Request resolved: https://github.com/facebook/react-native/pull/31141
Test Plan:
Failing Test: Upgrade or init a new project and make sure that the project root directory contains a space (ex: /Users/test/cool projects/app/). With a clean install of node_modules and pods, attempt to build the project with Xcode. The build fails with an error running the script in FBReactNativeSpec (no such file or directory).
Passing Test: Include the changes presented in this PR and rerun the failing test (clean node_modules + PR patch/clean pods). The app should build.
Reviewed By: mdvacca
Differential Revision: D28255539
Pulled By: hramos
fbshipit-source-id: d44011985750639bd2fabfd40ed645d4eb661bd7
Summary:
Changelog:
[General][Changed] Refactor ScrollViewStickyHeader to a functional component to remove unsafe lifecycles and mutations during render
Reviewed By: lunaleaps
Differential Revision: D28203776
fbshipit-source-id: 615c8e1cd9e9e26d25c7d02aee7e4a0bfc8ec6c3
Summary:
This diff creates a MC to verify impact of eager initialization of fabric classes, the purpose is to remove this code, but before doing that I would like to verify what's the impact.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D28223943
fbshipit-source-id: 6f7c4701fb730fe1c0629ec13ead592ff619373f
Summary:
This diff deletes the registerGeneratedViewConfig API that is not used anymore.
This API was likely ONLY used internally at facebook, that's why I'm not deprecating it.
changelog: [Delete] Delete registerGeneratedViewConfig API
Reviewed By: fkgozali
Differential Revision: D28207558
fbshipit-source-id: 8598591e7ba1a7b001c87cb8728f2c599b1bbf63
Summary:
This diff ensures that the dispatch of switch events is performed using the proper UIModule
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28204930
fbshipit-source-id: 625b536ab3106efa7dbf583589dfe268b880a6a0
Summary:
After this diff, every NativeModule that has `synthesize bundleManager = _bundleManager`, will get access to an RCTBundleManager, that it can use to read from/write to the bridge's bundle URL.
Changelog: [iOS][Added] - Attach RCTBundleManager to NativeModules
Reviewed By: PeteTheHeat
Differential Revision: D28086319
fbshipit-source-id: 6e4cd815d300e9036957ec8c743e947d2cb3f365
Summary:
Fix Readme link to Testing section
Fix Readme link to Testing section
## 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] - Fixed link to Testing in React Native Android ReadMe file
Pull Request resolved: https://github.com/facebook/react-native/pull/31387
Test Plan: Change has been made to a Readme documentation, no changes in code
Reviewed By: TheSavior
Differential Revision: D28192184
Pulled By: PeteTheHeat
fbshipit-source-id: 6d4503f68398accacead116b43981e03e4c1430a
Summary:
This issue fixes https://github.com/facebook/react-native/issues/30935 screenreader does not announce Image disabled accessibilityState.
As stated in AOSP View.java, the framework will handle routine focus movement, views indicate their willingness to take focus through the `isFocusable` method https://bit.ly/3dCnyHb
```
* <p>The framework will handle routine focus movement in response to user input. This includes
* changing the focus as views are removed or hidden, or as new views become available. Views
* indicate their willingness to take focus through the {link #isFocusable} method. To change
* whether a view can take focus, call {link #setFocusable(boolean)}.
```
The property is updated through its shadow node `ReactImageManager` method `setAccessible` https://bit.ly/3dDuK5L
```java
* <p>Instances of this class receive property updates from JS via @{link UIManagerModule}.
* Subclasses may use {link #updateShadowNode} to persist some of the updated fields in the node
* instance that corresponds to a particular view type.
```
## 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] - adding setAccessible to ReactImageManager to allow screenreader announce Image accessibilityState of "disabled"
Pull Request resolved: https://github.com/facebook/react-native/pull/31252
Test Plan:
**<details><summary>CLICK TO OPEN TESTS RESULTS</summary>**
<p>
Enable audio to hear the screenreader
TEST SCENARIO
- The user moves the screenreader focus to an image and the screenreader reads the Image accessibilityLabel "plain network image"
RESULT
- The screenreader announces the accessibilityState disabled after reading the Image accessibilityLabel "plain network image"
```javascript
<Image
accessible={true}
accessibilityLabel="plain network image"
accessibilityState={{disabled: true}}
source={fullImage}
style={styles.base}
/>
```
<video src="https://user-images.githubusercontent.com/24992535/112670432-2f366d00-8e61-11eb-843f-4b56f4a06a91.mp4" width="700" />
</p>
</details>
Reviewed By: kacieb
Differential Revision: D28194597
Pulled By: lunaleaps
fbshipit-source-id: 5f89ce5c714405506261885ac6fea2c15c2e1f23
Summary:
Our ESLint configuration currently disallows template literals that can be expressed using plain string syntax (with single quotes). Jest's inline snapshots feature sometimes produces such template literals. This not only adds unnecessary friction from the linter, but can break subsequent snapshot updates in a test file (after accepting the ESLint autofix).
This conflict between Jest and ESLint is a known issue (https://github.com/facebook/jest/issues/10164) with no upstream fix. Here we relax the linter's settings to allow all template literals in test files. Ideally we could allow them *only* in inline snapshots, but this is a reasonable approximation.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D28120785
fbshipit-source-id: c6c6c0ab8a3b8aca14df06f430b777cef42cd554
Summary:
Some components are using `LogBoxData` directly, forcing logs to be shown on the screen even when LogBox is uninstalled. This changes all accesses to `LogBoxData` to go through `LogBox` so `uninstall` is used correctly.
It also changes when LogBox is installed, moving it from `AppContainer` to `InitializeCore` (which happens earlier) so we can capture more logs in LogBox.
Changelog: [General][Changed] Initialized LogBox earlier and centralized access in LogBox module
Reviewed By: rickhanlonii
Differential Revision: D27999361
fbshipit-source-id: 1115ef6b71e08cc33743d205da0064fbe9a74a0e
Summary:
In the full bridgeless, the following aren't allowed:
* using legacy view manager interop layer (won't support long term, but still needed today, so just warn)
* initializing any subclass of RCTViewManager (won't support long term, but still used by legacy interop layer)
* initializing RCTUIManager (fabric UIManager should be the only one used)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28111530
fbshipit-source-id: 4f5eab600c6c7896d51861545b7f878c25248e44
Summary:
Changelog:
[General][Added] Add support for "togglebutton" accessibilityRole
# Context
The role for ToggleButton, which is needed on Android to implement toggle buttons correctly, is not currently supported.
# What does this diff do?
Adds support for accessibilityRole `"togglebutton"`.
On Android, this maps to class `"Android.widget.ToggleButton"`.
iOS does not have an equivalent trait for togglebutton, so I set it to be the same as setting `accessibilityRole="button"` for iOS.
# Caveats - checked vs selected
It seems to me like this role currently requires that you set `accessibilityState={{checked: true/false}}`. The behavior is strange when setting `selected` state, I think because on Android ToggleButtons are meant to use `checked` to indicate toggled on/off.
This is tricky because typically on iOS if you have a toggle button, you would use `selected` instead of `checked`, so RN users are likely to mess this up.
Possible solutions:
1. document that you should use `checked` state on Android for toggle buttons (and maybe throw a warning if someone passes in `selected`).
2. have RN ignore it if someone passes in accessibilityState `selected`, if this role is used.
3. Have RN convert passed in `selected` state to `checked` on the Android side.
Reviewed By: nadiia
Differential Revision: D27976046
fbshipit-source-id: 4ce202449cf2371f4bf83c4db2d53120369ee7b0
Summary:
Currently, various CircleCI jobs intermittently fail when trying to fetch dependencies via Maven.
This adds a few retries before failing the CircleCI job to reduce noise from intermittent network fetch failures.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D28153008
fbshipit-source-id: ac944882ff0495f568973a709d6d61ef7b51b318
Summary:
Recent changes to `MapBuffer` have broken the compilation on Windows.
This fix is similar to this recently-merged change: https://github.com/facebook/react-native/pull/31106
Side note - this PR only addresses a build break, but doesn't address the unsafe casting semantics in `MapBuffer`, which can still cause overflows.
## 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] - Fix compilation errors on Windows.
Pull Request resolved: https://github.com/facebook/react-native/pull/31363
Test Plan: RN now builds in Visual Studio on Windows.
Reviewed By: mdvacca
Differential Revision: D28028342
Pulled By: rozele
fbshipit-source-id: 77d8d4870c59b77acfc0ab2f4c3b7df40b59851d
Summary:
Changelog: [iOS] Use visible prop to dismiss Modal on old renderer.
Visible prop is used on Fabric so that onDismiss can be passed with the the bridgeless per-component event emitter, rather than the bridge global event emitter. The old renderer still uses the global event emitter.
I needed to use the visible prop for Paper too because in diff 6/7, Modal.js [no longer uses visible prop to return null](https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Modal/Modal.js#L221-L222), and Modal.js can't distinguish on whether it's a Fabric or Paper component.
Reviewed By: JoshuaGross
Differential Revision: D28137929
fbshipit-source-id: f6ede0019fbe498a10b822ff09fc135a9fff8ec0
Summary:
Changelog:
[Internal][Changed] - Fix Picker's item value in the ModalCustomizable example
This surface was removed a few days ago in D27926745 (https://github.com/facebook/react-native/commit/23ae702d97103105a24d85fc7d26f9fb9f15bb3e). Add it back to be able to test Modals manually.
There's no e2e test associated with this surface at the moment.
Reviewed By: nadiia, kacieb
Differential Revision: D28074150
fbshipit-source-id: dbcceed75e982d211b5c74cdf5f80aee59f54678
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Summary:
This diff migrates RCTMultilineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116333
fbshipit-source-id: b245026ebcd564380d0c74bbd6d9a36c661a8e71
Summary:
This diff migrates RCTSingelineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116332
fbshipit-source-id: d0a1a512a1cd967608512423db3dffa7c68fd2c5
Summary:
This diff reports warning when a method of the LazyUIManager is called when using fabric and StaticViewConfigs enabled
changelog: [Android][changed] Deprecate UIManager methods when using the new architecture enabled
Reviewed By: fkgozali
Differential Revision: D28108804
fbshipit-source-id: 4b430bdefa67914883a595dff97ea6c9ffd93361
Summary:
This diff and stack migratest Migrate UIManager.getViewManagerConfig -> UIManager.hasViewManagerConfig
This is necessary to avoid initializing UIManagerModule to detect if a component is registered into the native platform
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D27983716
fbshipit-source-id: 504180d8883959835e736f8081610b8c49810803
Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
This fixes multiple compile errors when building RNTester with Hermes enabled:
- `Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')`
- `'event2/event-config.h' file not found`
- tons of missing files (all added to RCT-Folly/Futures)
Changelog: [iOS] Fix Hermes build on folly version 2021.04.26.00
allow-large-files
Reviewed By: RSNara
Differential Revision: D28128087
fbshipit-source-id: ee7cb6fda72d00d22f6182d958aa8ba55939f158
Summary:
Implement the API for querying the properties of an object found in a
heap snapshot.
Now when you are debugging and take a heap snapshot, you can hover
over an object and inspect it!
Only works for subclasses of JSObject. Doesn't work for stuff like HiddenClass,
PropertyAccessor, native objects like WeakValueMap, etc. Those internal objects
display "Preview is not available" which matches what Chrome prints for its own
internal stuff.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D27834672
fbshipit-source-id: 607a8984b5a48b76c5ae57f9bd5bf53168f3ec3f
Summary:
Changelog: Fix main thread access to UIKit in RCTRedBox
{F611784226}
Xcode's main thread checker complains about this during reload. it is not needed to set `dataSource` and `delegate` to nil because the table view is about to be destroyed.
Reviewed By: mdvacca
Differential Revision: D28089039
fbshipit-source-id: 13b62cafb4790fc15b5a5dde131d4ae64bd97c82
Summary:
NativeAnimationModule on Android is using batches to combine related updates together. In Fabric, this process is controlled by JS, which schedules starts batching when Animated component props are about to be updated.
In rare cases when there's no prop update (like calls to `setValue` on `AnimatedValue`), changes weren't applied until the next batch was scheduled. This change ensures that such changes get applied directly.
This problem doesn't happen on iOS or non-Fabric surfaces, because they use per-frame scheduling instead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28100641
fbshipit-source-id: 87b3acb3a8de131cdcb2104dc121d40eccfbc29d
Summary:
In development, we can specify a debug name to force the whole React tree to have a meaningful name. This is useful for debugging: React DevTools, component stack traces, etc. More context in D26637787 (https://github.com/facebook/react-native/commit/eeb36f470929c2fdd8e1ed69898a5ba9144b8715).
This worked fine until now because `renderApplication` is never called more than once per React Native root. With pre-rendering, this won't be true as we'll be able to re-render the whole React tree with new props (after navigating to the screen).
The problem with the current implementation is that we generate a new component every time `renderApplication` is called, which makes the React reconciliation consider them different components and discards the whole sub-tree.
This fixes it by caching those components so we always return a component with the same identity (exactly the same function) when we call `renderApplication` repeatedly.
This won't have any effect in production where these components aren't created at all.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D28061384
fbshipit-source-id: 95833a5b74bb622896cb47426f74324d8740e5d7
Summary:
Runs an A:A react sync against the current revision to pick up the updates from the sync script.
Changelog: [Internal]
Reviewed By: yungsters, kacieb
Differential Revision: D28103715
fbshipit-source-id: 3593909e999bdceeb95423dc37dc0ee4282963d9
Summary:
Changelog:
[General] - Reflect Hermes release version from HermesBadge
It was a common footgun that an unexpected version of Hermes
engine is used in a RN app. To help with indicating this from
the runtime, Hermes exposes its OSS release version from
`HermesInternal.getRuntimeProperties()` Starting from 0.8.0.
This diff updates the `HermesBadge` used by `NewAppScreen`
header to reflect the version.
Reviewed By: nadiia
Differential Revision: D24436609
fbshipit-source-id: 8ba45be598a7d5af0e38f5044f9370fc7e1eb9a1
Summary:
React DevTools has gotten pretty outdated in React Native. Let's fix that!
Last time I tried this it caused a lot of churn for tools like Flipper, so I approached this in two steps ([detailed in this post](https://fb.workplace.com/groups/rnsyncsquad/permalink/808063140086959/)).
First was a short term plan (as implemented in [PR 21344](https://github.com/facebook/react/pull/21344)) to:
1. Branch and make a patch release of DevTools 4.10 that adds a protocol check to the frontend (to detect any newer backends).
2. Upgrade Flipper (and recommend upgrade for the OSS React Native Debugger as well) to this new frontend.
3. Wait for the updated frontend to roll out.
The short term plan is now done, at least for the internal build of Flipper, and both GitHub PRs to update Flipper and React Native Debugger have been merged.
So this diff moves forward with the longer term plan (implemented in [PR 21331](https://github.com/facebook/react/pull/21331)):
1. Add an explicit version to the protocol used by the DevTools "backend" and "frontend" components to talk to each other.
2. Check this protocol during initialization to ensure it matches.
3. Show upgrade/downgrade instructions if there's a mismatch (or if the check times out without a response– indicating an older backend).
4. Release this as 4.13.
---
Changelog:
[General][Changed] - Upgrade `react-devtools-core` from ~4.6.0 to ^4.13.0
Reviewed By: yungsters
Differential Revision: D28103394
fbshipit-source-id: 21114294144bde9aede63cb3ba98a240082299bd
Summary:
When REMOVE animations finish, they are hitting asserts in StubViewTree because of UPDATEs and REMOVEs being out-of-order. By simply not forcing REMOVEs to happen before UPDATEs, this problem seems to go away.
Long-term (in a couple weeks, likely) I want to add unit tests to catch all cases like this, but I'm comfortable with this change since it does fix a known assert failure.
Changelog: [Internal]
Differential Revision: D28086223
fbshipit-source-id: eb77ea94d76e996d7b2cb37038ce6f2a9799f8b4
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:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
From looking at other implementations of setJSResponder, we need the MountingManager to have access to "blocksNativeResponder" param, but do not need to pass that through to individual views (see also Android implementation).
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D28066257
fbshipit-source-id: e1420431478fd27d2e1463e291a0bbc600d3f0a6
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
2021-04-28 16:49:05 -07:00
4137 changed files with 132581 additions and 70328 deletions
description:Report a reproducible bug or regression in React Native.
labels:["Needs: Triage :mag:"]
body:
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are likely to stall.
- type:textarea
id:description
attributes:
label:Description
description:Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest React Native release to make sure your issue has not already been fixed - https://reactnative.dev/docs/upgrading.html
validations:
required:true
- type:input
id:version
attributes:
label:Version
description:What react-native version does this appear on?
placeholder:ex. 0.66.0
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
validations:
required:true
- type:textarea
id:extra
attributes:
label:Snack, code example, screenshot, or link to a repository
description:|
Please provide a Snack (https://snack.expo.io/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
Please use this form to file an issue if you have upgarded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
- type:input
id:new-version
attributes:
label:New Version
description:This is the version you are attempting to upgrade to.
placeholder:ex. 0.66.1
validations:
required:true
- type:input
id:old-version
attributes:
label:Old Version
description:This is the version you were on where the behavior was working.
placeholder:ex. 0.65.1
validations:
required:true
- type:input
id:target
attributes:
label:Build Target(s)
description:What target(s) are encountering this issue?
placeholder:iOS simulator in release flavor
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `react-native info`
description:Run `react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Issue and Reproduction Steps
description:Please describe the issue and list out commands run to reproduce.
Please report documentation issues in the [`react-native-website`](https://github.com/facebook/react-native-website/issues) repository.
close:true
"Type: Upgrade Issue":
comment:>
Do you need help upgrading to a newer React Native version? Visit the [Upgrade Support repository](https://github.com/react-native-community/upgrade-support) or use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) to see the changes that need to be made to upgrade your app.
close:true
"Resolution: For Stack Overflow":
comment:>
We are using GitHub issues exclusively to track bugs in the core React Native library. Please try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native) as it is better suited for this type of question.
# Configuration for probot-stale - https://github.com/probot/stale
# Number of days of inactivity before an issue becomes stale
daysUntilStale:90
# Number of days of inactivity before a stale issue is closed
daysUntilClose:7
# Issues with these labels will never be considered stale
exemptLabels:
- Good first issue
- "Type: Discussion"
- Partner
- Core Team
- "Help Wanted :octocat:"
- "Impact: Regression"
- "Resolution: PR Submitted"
- "Resolution: Backlog"
# Label to use when marking an issue as stale
staleLabel:Stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment:>
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs.
You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open.
Thank you for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment:>
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.
stale-issue-message:'This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
### [Code of Conduct](https://github.com/facebook/react/blob/master/CODE_OF_CONDUCT.md)
### [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md)
As a reminder, all contributors are expected to adhere to the [Code of Conduct](https://github.com/facebook/react/blob/master/CODE_OF_CONDUCT.md).
As a reminder, all contributors are expected to adhere to the [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md).
## Ways to Contribute
@@ -18,7 +18,7 @@ If you are eager to start contributing code right away, we have a list of [good
There are other ways you can contribute without writing a single line of code. Here are a few things you can do to help out:
1.**Replying and handling open issues.** We get a lot of issues every day, and some of them may lack necessary information. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem. We cover more about this process in the [Issue Triage wiki](https://github.com/facebook/react-native/wiki/Issues#triage).
1.**Replying and handling open issues.** We get a lot of issues every day, and some of them may lack necessary information. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem. We cover more about this process in the [Issue Triage wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
2.**Reviewing pull requests for the docs.** Reviewing [documentation updates](https://github.com/facebook/react-native-website/pulls) can be as simple as checking for spelling and grammar. If you encounter situations that can be explained better in the docs, click **Edit** at the top of most docs pages to get started with your own contribution.
3.**Help people write test plans.** Some pull requests sent to the main repository may lack a proper test plan. These help reviewers understand how the change was tested, and can speed up the time it takes for a contribution to be accepted.
@@ -30,8 +30,8 @@ We use GitHub issues and pull requests to keep track of bug reports and contribu
You can learn more about the contribution process in the following documents:
We also have a thriving community of contributors who would be happy to help you get set up. You can reach out to us through [@ReactNative](http://twitter.com/reactnative) (the React Native team) and [@ReactNativeComm](http://twitter.com/reactnativecomm) (the React Native Community organization).
@@ -42,7 +42,8 @@ The main repository, <https://github.com/facebook/react-native>, contains the Re
There are a few other repositories you might want to familiarize yourself with:
* **React Native website** which contains the source code for the website, including the documentation, located at <https://github.com/facebook/react-native-website>
* **Releases** are coordinated through the <https://github.com/react-native-community/react-native-releases> repository. This includes important documents such as the Changelog.
* **Releases** Conversations for new releases are happening [in this discussion repo](https://github.com/reactwg/react-native-releases/discussions).
* **Changelog** The changelog can be found [here](https://github.com/facebook/react-native/blob/main/CHANGELOG.md).
* **Discussions** about the future of React Native take place in the <https://github.com/react-native-community/discussions-and-proposals> repository.
* **High-quality plugins** for React Native can be found throughout the [React Native Community GitHub Organization](http://github.com/react-native-community/).
@@ -50,7 +51,7 @@ Browsing through these repositories should provide some insight into how the Rea
## GitHub Issues
We use GitHub issues to track bugs exclusively. We have documented our issue handling processes in the [Issues wiki](https://github.com/facebook/react-native/wiki/Issues).
We use GitHub issues to track bugs exclusively. We have documented our issue handling processes in the [Issues wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
### Security Bugs
@@ -64,11 +65,11 @@ If you are adding new functionality or introducing a change in behavior, we will
### Contributing to the Blog
The React Native blog is generated [from the Markdown sources for the blog](https://github.com/facebook/react-native-website/tree/master/website/blog).
The React Native blog is generated [from the Markdown sources for the blog](https://github.com/facebook/react-native-website/tree/HEAD/website/blog).
Please open an issue in the https://github.com/facebook/react-native-website repository or tag us on [@ReactNative on Twitter](http://twitter.com/reactnative) and get the go-ahead from a maintainer before writing an article intended for the React Native blog. In most cases, you might want to share your article on your own blog or writing medium instead. It's worth asking, though, in case we find your article is a good fit for the blog.
We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-native-website/blob/master/CONTRIBUTING.md) document for the `react-native-website` repository to learn more about contributing to the website in general.
We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-native-website/blob/HEAD/CONTRIBUTING.md) document for the `react-native-website` repository to learn more about contributing to the website in general.
## Contributing Code
@@ -76,7 +77,7 @@ Code-level contributions to React Native generally come in the form of [pull req
The process of proposing a change to React Native can be summarized as follows:
1. Fork the React Native repository and create your branch from `master`.
1. Fork the React Native repository and create your branch from `main`.
2. Make the desired changes to React Native sources. Use the `packages/rn-tester` app to test them out.
3. If you've added code that should be tested, add tests.
4. If you've changed APIs, update the documentation, which lives in [another repo](https://github.com/facebook/react-native-website/).
@@ -86,17 +87,18 @@ The process of proposing a change to React Native can be summarized as follows:
8. Create a pull request to the React Native repository.
9. Review and address comments on your pull request.
1. A bot may comment with suggestions. Generally we ask you to resolve these first before a maintainer will review your code.
2. If changes are requested and addressed, please [request review](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) to notify reviewers to take another look.
10. If you haven't already, please complete the [Contributor License Agreement](https://github.com/facebook/react-native/wiki/Contributor-License-Agreement) ("CLA"). **[Complete your CLA here.](https://code.facebook.com/cla)**
If all goes well, your pull request will be merged. If it is not merged, maintainers will do their best to explain the reason why.
### Step-by-step Guide
Whenever you are ready to contribute code, check out our [step-by-step guide to sending your first pull request](https://github.com/facebook/react-native/wiki/Pull-Requests#getting-ready-to-submit-your-first-pull-request), or read the [How to Contribute Code](https://github.com/facebook/react-native/wiki/How-to-Contribute) wiki for more details.
Whenever you are ready to contribute code, check out our [step-by-step guide to sending your first pull request](https://github.com/facebook/react-native/wiki/How-to-Open-a-Pull-Request), or read the [How to Contribute Code](https://github.com/facebook/react-native/wiki/How-to-Contribute-Code) wiki for more details.
### Tests
Tests help us prevent regressions from being introduced to the codebase. The GitHub repository is continuously tested using Circle and Appveyor, the results of which are available through the Checks functionality on [commits](https://github.com/facebook/react-native/commits/master) and pull requests. You can learn more about running and writing tests in the [Tests wiki](http://github.com/facebook/react-native/wiki/Tests).
Tests help us prevent regressions from being introduced to the codebase. The GitHub repository is continuously tested using Circle and Appveyor, the results of which are available through the Checks functionality on [commits](https://github.com/facebook/react-native/commits/HEAD) and pull requests. You can learn more about running and writing tests in the [Tests wiki](http://github.com/facebook/react-native/wiki/Tests).
@@ -355,7 +358,7 @@ function shouldUseNativeDriver(
'animated module is missing. Falling back to JS-based animation. To '+
'resolve this, add `RCTAnimation` module to this app, or remove '+
'`useNativeDriver`. '+
'Make sure to run `pod install` first. Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md',
'Make sure to run `bundle exec pod install` first. Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md',
@@ -317,9 +319,9 @@ class AnimatedInterpolation extends AnimatedWithChildren {
this._interpolation=createInterpolation(config);
}
__makeNative(){
this._parent.__makeNative();
super.__makeNative();
__makeNative(platformConfig:?PlatformConfig){
this._parent.__makeNative(platformConfig);
super.__makeNative(platformConfig);
}
__getValue():number|string{
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Distiller
Hugo Cuvillier
Lorenzo Sciandra
Nick Gerleman
Marek Fořt
Distiller
Nicola Corti
Distiller
Thibault Malbranche
Distiller
Dmitry Rykun
David
Evan Charlton
Tommy Nguyen
lbaldy
Distiller
Lorenzo Sciandra
Sparsha SahaandSparsha Saha
Kunal Farmah
Olivier Payen
Kunal Farmah
Distiller
Distiller
Danilo Bürger
Krzysztof Magiera
Distiller
Distiller
Riccardo Cipolleschi
Distiller
Andrei Shikov
Mike Hardy
Krisztiaan
Kudo Chien
David Vacca
Danilo Bürger
jonathanmos
Distiller
Muhammad Numan
Alfonso Curbelo
Minsik Kim
Chiara Mooney
Distiller
Elias Nahum
Distiller
Xin Chen
Moti Zilberman
Gabriel Donadel Dall'Agnol
Pieter De Baets
Luna Wei
Genki Kondo
owjsub
Dmytro Voronkevych
AntoineDoubovetzky
joshua
Samuel Susla
Max Thirouin
Brian Vaughn
Evan Yeung
Marshall Roch
Paige Sun
MaeIg
Sota Ogo
Mattéo Martin
AKB48
Tim Yung
Moses DeJong
Michelle Laurenti
Ramanpreet Nara
Oliver Sartun
Eric Rozell
Brad Zacher
Liam Jones
Janic Duplessis
Michaël De Boey
Sam Kline
Asaf Korem
Joshua Gross
grgr-dkrk
Kacie Bawiec
Lulu Wu
Mengke Ding
Krzysztof Piaskowy
Andres Suarez
Richard Howell
Kevin Gozali
Charles Dudley
Ubax
Vojtech Novak
Phillip Pan
Sim Sun
Juan Tejada
Adam Cmiel
Julio C. Rocha
Marshall Mann-Wood
Panagiotis Vekris
Simon Farshid
Gijs Weterings
Amy Huyen
Alex Koller
Ian Grayson
Marc Rousavy
Liron Yahdav
zpd106
Yuan Dai
Tom Spencer
Marc Rousavy
David Ashinsky
Peter Carpenter
Felipe Perez
Neil Dhar
enniel
Nawbc
Christoph Purrer
Dulmandakh
Jeffrey Hyer
Jesse Katsumata
Jimmy Lai
George Zahariev
Marc Horowitz
Saad Najmi
Marcel Lasaj
Nick Fujita
Pieter Vanderwerff
chenmo187
Niklas Mischkulnig
Lucas Bento
Rubén Norte
rayzr522
Mikey
Héctor Ramos
somena1
Rachel Lang
Joel Arvidsson
Ken Tominaga
Moshe Berman
Stefanos Markidis
Geraint White
Andrew Scherkus
Andrew Rahn
Connor Tumbleson
Gustavo Sverzut Barbieri
Tuomas Jaakola
Xuan Huang
luism3861
Rob Hogan
Jordan Becker
Desmond Ng
Joel Arvidsson
svbutko
Aditya Wasan
Oleksandr Melnykov
Kræn Hansen
Wes Johnson
Xiankun Cheng
Manoj Kumar
Brent Kelly
Frieder Bluemle
Rob Hogan
fabriziobertoglio1987
Michael Neeley
Su Min Kim
Cristiano Coelho
James Donald
Adnan Irfan
Anderson Mesquita
PastLeo
Nick Vlug
Alex Malyshev
Amy Nichol
Tong Liu
Jakob Krigovsky
Radek Pietruszewski
Luis Miguel Alvarado
Jimmy Zhang
Gareth Knowles
Kosie van der Merwe
Vitaly Iegorov
Facebook Community BotandFacebook Community Bot
Krzysztof Borowy
Rick Hanlon
Nick Gerleman
Rodolfo
Aaron Grider
Kai Dederichs
Michał Osadnik
Meghnath Pillay
wangqingyang
Ashoat Tevosyan
Aaron (Li Bo) Tao
Utkarsh
Matt Oakes
Andrew Coates
Daiki Ihara
luism3861
Adlai Holler
Valentin Shergin
Keion Anvaripour
Matthew Gray
Joshua Selbo
Andres Riveros Moya
Vincent Lee
alessandro
Timo Mämecke
Steven Bell
Leon Kiefer
pietro909
edenb-moveo
Chatura Atapattu
Nicholas Tinsley
Arushi Kesarwani
Carmi Grushko
pera
Albert Sun
Jonathan Andrew
hank121314
nacam403
Chris Tolliday
Hein Rutjes
Nishan Bende
Levi Buzolic
Ikko Ashimine
jeswinsimon
Harry Yu
Michał Pierzchała
Saad Najmi
Sunny Luo
Luis Miguel Alvarado
Andrew Clark
Moti Zilberman
Test User
Vegas Murphy
Jacob Parker
Michael Chow
swittk
Hubert Gendron
Stefan Wrobel
Tomáš Havlas
Sandeep Raghunandhan
Altaibayar Tseveenbayar
Cody Unger
Yuqing Duan
Chris Shepherd
Jason Safaiyeh
Mark Bridges
Joshua Wiegmann
Dustin Shahidehpour
Sam Goldman
Adrián Cuesta
Tomek Zawadzki
Joshua Wiegmann
Anas Khurshid
Agastya Darma
Justin Huntington
Ruslan Serebriakov
Yedidya Feldblum
David Alves
Peter Argany
Michel Weststrate
William Candillon
Arthur Lee
Martin Sherburn
Daniel Sainati
Rui Ying
Justin
Hamza Jadid
Siddharth Verma
Maxime Bertheau
Birkir Gudjonsson
Michel Weststrate
Kermit
Shuhao Zhang
Amir Shalem
Håkon Knutzen
Thibault Malbranche
Simen Bekkhus
Dennis Urtubia
Evgen Filatov
Sladyn Nunes
Erich Graham
Shoaib Meenai
Subramanya Chakravarthy
Micha Reiser
Tien Pham
Adrien HARNAY
Craig Martin
sangeethaKP
Igor Klemenski
Riley Dulin
Nat Mote
Neal Poole
