Summary:
This fixes two things:
1) Currently it only respects Start and End padding, and if there's a Theme default, it will override Left/Right padding. Whoops.
2) Currently it doesn't respect when a TextInput starts with padding, but then is removed.
This resolves both.
It still does not account for RTL support.
Changelog: [Internal] Fix AndroidTextInput padding
Reviewed By: mdvacca
Differential Revision: D20573151
fbshipit-source-id: e89791641b6699e728cde9dbd661a8c21485fbc8
Summary:
Fixes https://github.com/facebook/react-native/issues/28361.
## Changelog
[Internal] [CI] - Fix test_android
Pull Request resolved: https://github.com/facebook/react-native/pull/28363
Test Plan:
Prior to fix:
```
react-native $ ./scripts/circleci/buck_fetch.sh
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.5 sec
Buck wasn't able to parse /Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK:
IOError: [Errno 2] No such file or directory: '/Users/hramos/git/react-native/tools/build_defs/platform_defs.bzl'
Call stack:
File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
return func(*args, **kwargs)
File "/Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK", line 1
load("//tools/build_defs:platform_defs.bzl", "ANDROID")
File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
return func(*args, **kwargs)
This error happened while trying to get dependency '//ReactAndroid/src/main/java/com/facebook/fbreact/specs:FBReactNativeSpec' of target '//ReactAndroid/src/main/java/com/facebook/react/devsupport:devsupport'
```
After fix:
```
react-native $ ./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.1 sec
Configuration 'ANDROID_SDK' points to an invalid directory '/opt/android_sdk'.
When creating rule //ReactAndroid/src/main/java/com/facebook/hermes/instrumentation:instrumentation.
```
> Note: I don't have the Android SDK configured in this machine.
Verified on Circle CI. `test_android` is now green: https://circleci.com/gh/facebook/react-native/140682?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
Reviewed By: cpojer
Differential Revision: D20564934
Pulled By: hramos
fbshipit-source-id: 5d843b8f113c4db5391ee39addc3ff259d962290
Summary:
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with `ios` and `android` folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.
In order to resolve the project root in the most accurate way, React Native assumed that project root is always `../../` from its location in `node_modules` - this is not true when the installation gets hoisted (e.g. in a monorepo).
To address that, janicduplessis brought support for custom [`PROJECT_ROOT`](9ccde378b6) that allowed overriding the `../../` in case it wasn't true.
Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets `package.json`.
As a result, it doesn't really matter from where we start the CLI anymore as a part of `react-native-xcode.sh`.
By replacing the default value of `$REACT_NATIVE_DIR/../../` with `$PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set `$PROJECT_ROOT` in order to override the incorrect defaults.
By default, all scripts defined in Xcode run from `$PWD` directory, which is the location of the iOS project. In the future, we will be able to remove `cd` entirely.
To better understand this PR, let's look a few hypothetical structures as an example:
#### Monorepo:
> tl;dr works out of the box, no need to mess around with paths
```
- package.json
- packages/
- my-app/
- index.js
- package.json
- ios/
- MyApp.xcodeproj
```
**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no `react-native` dependency at the workspace root.
- Some users turn `no hoist` in an act of troubleshooting the errors, which resolves the problem - `react-native` is moved under `my-app/node_modules` which makes this mechanism resolve properly.
- Some users find out about `PROJECT_ROOT` and set it to overwrite the default value. For example, setting `export PROJECT_ROOT = "$PWD/../` will set the directory to `my-app`, which has a dependency on `react-native` in a `package.json` and makes the CLI happy.
**After this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- The `$PWD` is `packages/my-app/ios/` because that's where the Xcode project is located. CLI will automatically set the root to `../` because that's where it finds `package.json` with `react-native` dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.
- No need to set `PROJECT_ROOT` anymore.
- We don't rely on the location of `node_modules`, which is cleaner and future proof.
#### Standard:
> tl;dr no changes
```
- ios/
- MyApp.xcodeproj
- index.js
- package.json
```
**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- Everything works fine. Path from `react-native` inside `node_modules` is correct - the project root is set right to `/`
**After this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- The root will be set to where Xcode project is located, which is `/ios`. This is the PWD for all Xcode scripts.
CLI will look for the `package.json` going upwards from `ios` folder. Will stop at `/`, find out it has `react-native` dependency, load it and its commands and proceed further.
## Changelog
[iOS] [Feature] - Better monorepo support when building release apk
Pull Request resolved: https://github.com/facebook/react-native/pull/28354
Test Plan:
- All projects (standard/monorepo) run without issues.
- PROJECT_ROOT is not needed.
CC: Titozzz (who wrote monorepo guide), alloy, bartolkaruza
Reviewed By: cpojer
Differential Revision: D20558005
Pulled By: hramos
fbshipit-source-id: 2551120beadcfd4c2f1393ce8a2c2fa6b93c9290
Summary:
Add diffing to app bundle size reports.
## Changelog
[Internal] [Changed] - Add diffing to app bundle size reports
Pull Request resolved: https://github.com/facebook/react-native/pull/28284
Test Plan:
- App bundle size reports should now display a diff where available
- Right now, the database contains only one entry for the last known good iOS build
- Triggering a new build should not create additional comments
Reviewed By: cpojer
Differential Revision: D20450158
Pulled By: hramos
fbshipit-source-id: 720772275f24d3ff0a49705f4dada2efe2e99bd3
Summary:
We initially added the nightly build test to run every hour, in order to more quickly validate it. Now that it has been validated we can run it every night as it is intended to do.
cc hramos
## Changelog
[General] [Changed] - Change nightly build from hourly to nightly
Pull Request resolved: https://github.com/facebook/react-native/pull/28346
Reviewed By: cpojer
Differential Revision: D20550143
Pulled By: hramos
fbshipit-source-id: 9487c6785684ad6ea7e877290d50a33118090a7f
Summary:
Earlier this week I introduced a change in the old, non-Fabric renderer (D20378633 D20427803) that (gated behind a feature-flag) executes ViewCommands before all other types of commands, as a perf optimization and (I think) a potential fix for a category of race conditions.
I've added more details in comments here.
The Fabric renderer uses the same feature-flag that I introduced for the non-Fabric renderer.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D20449186
fbshipit-source-id: bb3649f565f32c417a6247369902333989a043aa
Summary:
Instead of just blindly retrying all ViewCommands if they fail - which could be dangerous, since it's arbitrary imperative commands we'd be executing twice, potentially with bad app state - we only retry if the ViewCommand throws a "RetryableMountingLayerException".
Changelog: [Internal] Optimization to ViewCommands
Reviewed By: mdvacca
Differential Revision: D20529985
fbshipit-source-id: 0217b43f4bf92442bcc7ca48c8ae2b9a9e543dc9
Summary:
Simplifying the dispatchMountItems reentrance and retry logic.
Motivation: cleanup so I can work on dispatching ViewCommands before anything else.
Importantly, this gives us the properties that:
1) Only one function is responsible for calling dispatchMountItems
2) Only one function is responsible for deciding if we shouldn't call dispatchMountItems due to reentrance
3) Only one function is responsible for all cleanup
4) Only one function maintains all of the relevant flags (except dispatchPreMountItems... two total now, instead of 4 before)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20437035
fbshipit-source-id: 5370366790eb25f653bee6c1950e747458374a61
Summary:
Original commit changeset: b594d0e6e9b6
D20319824 introduced a problem in LayoutAnimations, which makes surfaced as the problem in T63911344. This diff reverts D20319824.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D20541918
fbshipit-source-id: ff72b839f57d39051122920a38b2632cbb5ec362
Summary:
This diff fixes an issue where errors in LogBox during tests would cause the tests to crash.
The crash is due to the NativeExceptionsManager module not being mocked (as all native module need to be in tests). The fix is to properly mock the NativeExceptionManger.
This fix exposed an infinite loop issue where failures in LogBox will be logged to the ExceptionManager, which logs to the console, which logs to LogBox, creating a loop. This diff also fixes that look by moving the LogBox internal error check to the top of the monkey patched console methods.
Changelog: [Internal]
Differential Revision: D20428590
fbshipit-source-id: 7289a480c99ba8dee67772178b7629afb40b330a
Summary:
This PR adds the `isFocused` method to the mock of the TextInput component. My understanding some of the latest changes on the TextInput to make it use a forwardRef change the way this method is mock giving an error when trying to use in on a mock.
The change suggested here fixes the issue.
## Changelog
[JavaScript] [Fixed] - Fix the mock for TextInput to support the `isFocused` method
Pull Request resolved: https://github.com/facebook/react-native/pull/28332
Reviewed By: cpojer
Differential Revision: D20538044
Pulled By: TheSavior
fbshipit-source-id: be734af105ab62ffdf9ed4017bd70845e207f8cd
Summary:
The new prop on RCTParagraphComponentView is meant to be used only by external introspection tools, not the RN core.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: nscoding
Differential Revision: D20523078
fbshipit-source-id: 4c457d070fd2c172d681c5aa7f731d2d52bba291
Summary:
Just includes the manual changes to get the perf logger moved to the ObjCTurboModule constructor.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20498443
fbshipit-source-id: e607588f47ccc8ae199cd97043b09dfaff7a72dd
Summary:
Previously, I had logic inside `RCTTurboModuleManager` to attach the `id<RCTTurboModulePerformanceLogger>` to the `ObjCTurboModule` object
```
/**
* By default, all TurboModules are long-lived.
* Additionally, if a TurboModule with the name `name` isn't found, then we
* trigger an assertion failure.
*/
auto turboModule = [strongSelf provideTurboModule:moduleName];
/**
* TODO(T63718299): Move this setter into the ObjCTurboModule constructor
*/
if (performanceLogger) {
if (auto objCTurboModule = std::dynamic_pointer_cast<facebook::react::ObjCTurboModule>(turboModule)) {
objCTurboModule->setRCTTurboModulePerformanceLogger(performanceLogger);
};
}
```
This diff removes that logic in `RCTTurboModuleManager`, and it also removes `ObjCTurboModule::setRCTTurboModulePerformanceLogger`. Henceforth, we'll instead pass the `id<RCTTurboModulePerformanceLogger>` into `ObjCTurboModule`'s constructor. I've made all the necessary changes to the codegen scripts in this diff as well.
This should also resolve T63903079 by simply eliminating the code that's crashing production FB apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20480971
fbshipit-source-id: c3899981f880aa5d1354b5c3f4018c8fd57c3bae
Summary:
The ['Needs Attention'](https://github.com/hramos/needs-attention) action will remove the "Needs: Author Feedback" label and replace it with "Needs: Attention" whenever the original author of an issue adds a comment.
Removes the `no-response` GitHub integration. The 'close after 21 days' functionality from `no-response` is not present in the 'Needs Attention' action. We'll need to add this back some other way. Considering we were not closing issues that were in the Needs Response state until recently, I think it's OK to proceed here.
## Changelog
[Internal] [CI] - Enable 'Needs Attention' action
Pull Request resolved: https://github.com/facebook/react-native/pull/28338
Test Plan: https://github.com/hramos/needs-attention/issues/1
Reviewed By: cpojer
Differential Revision: D20506380
Pulled By: hramos
fbshipit-source-id: a5a0a7fc330821b7c51aabc0905f520d5caa829a
Summary:
## Description
In T63516227, we're seeing a crash that occurs because `networking.methodQueue` is `nil`, and we try to `dispatch_async` to it.
## Hypothesis
This looks like a problem with NativeModule cleanup:
1. Some JS executes a call to `RCTBlobManager.addNetworkingHander`. This schedules an async method call on the `RCTBlobManager` method queue.
2. In `RCTCxxBridge invalidate`, on the JS thread, we loop through all the `RCTModuleData`s, and invalidate them. This invalidates our NativeModules (perhaps not all but only `RCTNetworking`).
3. The `RCTBlobManager.addNetworkingHander` method call finally executes, with `RCTNetworking`'s methodQueue set to nil, which throws this error.
Changelog:
[iOS][Fixed] - Fix RCTBlobManager cleanup crash
Reviewed By: PeteTheHeat
Differential Revision: D20498096
fbshipit-source-id: d2d60984637ddf883278289258aa9b2ae81bb172
Summary:
Changelog: [internal]
layoutDirectionPass down layoutDirection from `RCTSurfacePresenter` down to `YogaLayutableShadowNode`.
In `ParagraphShadowNode`, we propagate layoutDirection from yoga node to `TextAttributes.layoutDirection`.
Reviewed By: shergin
Differential Revision: D20420041
fbshipit-source-id: 86e01d31ea9415acb8579c44c470cac870ec1b8f
Summary:
Changelog: [Internal]
# Why was it crashing?
Crash was caused by `data.getTrackImageRequest()` returning NULL. The crash happened inside `getCoordinator` method. If you look at the implementation of the method below
```
if (request) {
return &request->getObserverCoordinator();
} else {
return nullptr;
}
```
you might notice that we check for NULL, why is it crashing then? And why is it only crashing in production?
The reason is compiler's optimiser, which looks at `data.getTrackImageRequest()`, this method returns `ImageRequest const &` and sees that this method will always return a value, never NULL. Compiler then looks at our `getCoordinator` function, sees that we check there for nullity but since it can never be null, removes that branch.
# Solution
Create new SliderState with non null image observer.
Reviewed By: shergin
Differential Revision: D20491367
fbshipit-source-id: 17b7cf31feabbe6f8ece324a3d329902b2ef6a2d
Summary:
A few recent imports have explicitly added ".js" to the end of their path. This prevents Metro from resolving platform-specific JS files, e.g. "Foo.android.js" or "Foo.windows.js" instead of "Foo.js".
React Native Windows provides its own implementation of files in a few cases where stock React Native will share them between Android and iOS. We hope to reduce/eliminate these long term, but requiring explicit ".js" files currently breaks us in a couple of places where we have custom implementations.
This change is a quick regex replace of ES6 and CommonJS imports in 'Libraries/" to eliminate ".js".
## Changelog
[General] [Fixed] - Do not explicitly include ".js" in Library imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28311
Test Plan: I haven't done any manual validation of this, but `flow-check` should catch any issues with this during CI.
Reviewed By: cpojer
Differential Revision: D20486466
Pulled By: TheSavior
fbshipit-source-id: 31e1ccc307967417d7d09c34c859f0b2b69eac84
Summary:
Patch for T63997094.
Will still crash in debug mode, and log soft errors, so as not to entirely hide errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20473855
fbshipit-source-id: 8b052b1ae3c886f83d6a7922feb158172cdcd33d
Summary:
We don't need it anymore because the same logic is already implemented in `YogaLayoutableShadowNode::layoutTree()`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20464175
fbshipit-source-id: 3dd2293ee102a9b67a856104720d3a7dc4103d7f
Summary:
Changelog: [Internal]
# Problem
SafeAreaView is getting reused, its previous `safeAreaInsets` is top: 44, bottom: 34 so `safeAreaInsetsDidChange` doesn't get called because it doesn't change. Therefore state gets never updates because `safeAreaInsetsDidChange` is never called.
# Solution
Update state whenever a new state is assigned.
Reviewed By: shergin
Differential Revision: D20444198
fbshipit-source-id: 75d1458450c70d74647df4962ddad88d5f6a38d2
Summary:
Changelog: [internal]
# Problem
Assigning `CALayer.contents` implicitly animates the difference. As we keep `UIView` in recycle pool between usages, they keep their previous state. This was causing animation of border when the views were being reused.
# Solution
Wrapping application of mutations in `CATTransaction`.
Reviewed By: shergin
Differential Revision: D20442045
fbshipit-source-id: 214d6c422f23f399dec46b5bf1a38a7b64758160
Summary:
Fixed some url in the code that was outdated.
## Changelog
[Internal] [Fixed] - Fix outdated url in Image Example of RNTester and comment in StyleSheet Type
Pull Request resolved: https://github.com/facebook/react-native/pull/28285
Test Plan: Url can be accessed, and content displayed makes sense.
Differential Revision: D20464293
Pulled By: shergin
fbshipit-source-id: f0c97f7a95ed2a3d6c396cff6cda0bdaab7f5c35
Summary:
Fixes https://github.com/facebook/react-native/issues/28271
As explained by mmallet-youilabs , if the parameters passed to the `move` function are too expensive, this can have an impact on performance. Thus making these parameters captured by value mutable, the parameters are not movable.
## Changelog
[iOS] [Fixed] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28297
Test Plan: Steps to reproduce (and expected results) are not applicable (unless running with a profiler).
Differential Revision: D20464278
Pulled By: shergin
fbshipit-source-id: 846a8bc6c61cb4aa21fbd96b419c3775190a2c84
Summary:
This PR is to address https://github.com/facebook/react-native/issues/28200
Even though GeoLocation was extracted from the Core, there are still libraries i.e. the CoreLocation.h library included which cause Apple to reject Apps, as mentioned here.
This removed all references to the CoreLocation library that where remaining.
## Changelog
[iOS] [Removed] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28300
Test Plan:
- Flow check passes.
- RNTest built successfully.
Differential Revision: D20441145
Pulled By: shergin
fbshipit-source-id: 03faa4d20dc15cea931b42f34f13814df9c94a01
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to take `view.layer.zIndex` into account when we do hit-testing, so now we don't need to sort *all subviews* on *all levels of hierarchy* every time we process touch down event.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20425987
fbshipit-source-id: 025bd968ae948b9b0a4188845efc0de950fb5cdf
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to have it implemented on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432156
fbshipit-source-id: f77b96919bab21b6628472b9fe58c5f4e3233318
Summary:
Now, having `orderIndex` feature in the core, we can use it for implementing `zIndex` feature. All we need to do is just to assign this `zIndex` value to `orderIndex`.
Then we will use this to remove some platform-specific code that implements `zIndex` on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432155
fbshipit-source-id: b4d62b63006f45899de38e1f40b1dfbe69550ada
Summary:
This behavior matches the behavior of `dynamic_cast` (on which some callsites rely on).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20456792
fbshipit-source-id: 9604da0f9f78cc7357e60ed11012756e753e4b45
Summary:
This was causing an exception cascade leading to production
errors. Added a test which repros the problem and passes with the
fix.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D20408858
fbshipit-source-id: 3fa9b8669bf3bf7617bfc05ef8f23d52bc969b4e
Summary:
This fixes a bug in Android TextInlineViews that was reproducible in ActivityLog screen, see T63438920
Since Text are virtual nodes it is not necessary for these kind of views to stack views during diffing.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D20448085
fbshipit-source-id: 2d852975493bf6bcc7840c80c5de5cb5f7890303
Summary:
Changelog: [Android] [Added]
Adding:
- OverrideColorScheme interface to AppearanceModule
- setOverrideColorScheme method to AppearanceModule
This allows RN surfaces's color scheme to be overriden by custom theme from the app.
When set, AppearanceModule will use the value from OverrideColorScheme instead of system theme (light/dark)
Reviewed By: JoshuaGross
Differential Revision: D20405810
fbshipit-source-id: 8e562148a75231781649b615fdaf3368beeb477d
Summary:
This method does not have implementation and we don't use it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20423392
fbshipit-source-id: cfb5e4a60dbeca26a968c29d20e74dd6af0bf660
Joshua Gross
Héctor Ramos
Mike Grabowski
Tommy Nguyen
Sam Mathias Weggersen
Ramanpreet Nara
Rick Hanlon
Sergio Estevao
Christoph Nakazawa
Valentin Shergin
Jesse Katsumata
Samuel Susla
Eloy Durán
Nick Gerleman
Hans Halverson
Luna Ruan
maschad
Marc Horowitz
David Vacca
Jack Wang
Héctor Ramos
Héctor Ramos