Summary:
Fixes iOS builds failing with the following error in certain setups:
```
/~/Pods/React-RCTBlob/Libraries/Blob/RCTBlobPlugins.mm:14:9: fatal error: 'RCTBlobPlugins.h' file not found
#import "RCTBlobPlugins.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
```
## 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] - "'RCTBlobPlugins.h' file not found" when building iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29684
Test Plan:
- Existing builds should not fail
- Tested this change internally where we are seeing this build failure
cc hramos
Reviewed By: fkgozali
Differential Revision: D23581090
Pulled By: appden
fbshipit-source-id: 89d2088c362bfbd22df5cd098b110a43d76e784f
Summary:
Changelog: [Internal]
In https://fburl.com/diffusion/3705cj0i we assert that view which is about to be recycled, has no superview.
This is a problem in Legacy interop layer which is nested within another interop layer. This originally wasn't considered.
Removing views in `finalizeUpdates` like it has been done until now is not enough because when a component is deleted, `finaliseUpdates` isn't called.
Reviewed By: shergin
Differential Revision: D23572999
fbshipit-source-id: f007dfe293b7d27d56253656c02529163304f83c
Summary:
Changelog: [internal]
[NSString UTF8String] is nullable. Therefore, we need to check if it isn't nil before passing it to std::string constructor which crashes if it's nil.
Reviewed By: shergin
Differential Revision: D23572652
fbshipit-source-id: 59e7f5e918b2e5c69333bfb687371f856555d8e0
Summary:
The standard says that zIndex should only be defined for non-`static` positioned views. This diff implements it.
For now, it actually enables zIndex for all views in RN because there is no way to specify `position: static` but we will give that ability by changing Flow definitions in future diffs in a couple of weeks (to ensure OTA safety).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23559447
fbshipit-source-id: 20ea10c9349de2c5b1adea5735324a8f57150695
Summary:
Fabric Core does not support exception safety, so technically exceptions are unrecoverable and binaries should be built without exception support.
While it's not the case, some exceptions might bubble to JavaScript realm and be caught as JavaScript exceptions. In this case, we lose the stack trace. To prevent that and to investigate one particular error we have we add this try-catch block in this diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23529233
fbshipit-source-id: 7ac7fb26ac08ad26af8790172de471ac178c3a37
Summary:
This argument for the `onResponderGrant` event callback on `Text` is extraneous.
Changelog:
[General][Fixed] - Remove extraneous argument for `onResponderGrant` Flow type on `Text`.
Reviewed By: TheSavior
Differential Revision: D23513190
fbshipit-source-id: c4057cf534f4cdf73967e4324db64acc8cf323d0
Summary:
The nested `.gitattributes` file in `packages/react-native-codegen/android/` caused some confusion on Linux and macOS, causing Git to show `packages/react-native-codegen/android/gradlew.bat` as modified (CRLF removed, LF added).
Instead of relying on repo-local `.gitattributes` files to convert endings in the working directory, the files should be committed to source control with the correct line endings in the first place. There is no reason to convert LF endings in .sh and many other file to CRLF on Windows (maybe this was an issue a long time ago, but unless Notepad is used this won't be a problem for practically all modern editors).
Also fixed the line endings of `scripts/launchPackager.bat` which was incorrectly committed as LF.
## Changelog
[Internal] [Fixed] - Line endings and .gitattributes
Pull Request resolved: https://github.com/facebook/react-native/pull/29792
Test Plan: Clone repo on Linux, macOS, and Windows, and make sure no modified files show up.
Reviewed By: fkgozali
Differential Revision: D23546135
Pulled By: mdvacca
fbshipit-source-id: 1572fcb959212f212b137066f1aa66f0bb6e86c3
Summary:
It looks like this config in gradle.properties caused the :packages:rn-tester:android:app:dependencies task to fail. This was reported here: https://github.com/gradle/gradle/issues/9645#issuecomment-530746758 -- it's likely related to using Kotlin build.gradle.kts?
For now comment these out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23521954
fbshipit-source-id: 9997f4950d89e5fc57036b05db5518b39d47737b
Summary:
Replaces the `listeners()` method on `EventEmitter` with a `listenerCount()` method.
Changelog:
[General][Removed] - Removed `listeners()` from `DeviceEventEmitter` and `NativeEventEmitter`.
[General][Added] - Added `listenerCount()` to `DeviceEventEmitter` and `NativeEventEmitter`.
Reviewed By: cpojer
Differential Revision: D22204156
fbshipit-source-id: 15029525aeef55de9934a4f319910e666ecbe1d8
Summary:
The Circle CI iOS jobs are failing when installing Watchman:
```
#!/bin/bash --login -eo pipefail
HOMEBREW_NO_AUTO_UPDATE=1 brew install watchman >/dev/null
Error: The `brew link` step did not complete successfully
Exited with code exit status 1
CircleCI received exit code 1
```
The commit associated with the job where this issue first appeared did not make any changes to Watchman, but it did change the VM used by Circle CI for these jobs. Flushing the homebrew cache might help.
## 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]
Pull Request resolved: https://github.com/facebook/react-native/pull/29843
Test Plan: Run on Circle CI. Watchman install step succeeded: https://circleci.com/gh/facebook/react-native/166160?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
Reviewed By: fkgozali
Differential Revision: D23495409
Pulled By: hramos
fbshipit-source-id: 56a68bba3afc1350d4fc409d65f9229e3f38f467
Summary: Changelog: [Changed] Used scoped performance logger to mark the beginning and end of the call to the renderer, instead of using `GlobalPerformanceLogger`.
Reviewed By: lunaleaps
Differential Revision: D23240784
fbshipit-source-id: 7099f1a4b5da3f29596fcee289a715d295ae0a65
Summary:
This type makes more sense as an interface, given a class would be a common implementation (and object types aren't supported in that case).
It also adds the names of the parameters so it's easier to understand for implementers.
Changelog:
[General][Changed] - Changed type definition of IPerformanceLogger from object to interface
Reviewed By: lunaleaps
Differential Revision: D23449816
fbshipit-source-id: be872748827b123587f3f397da20f5545b0aae07
Summary:
When we render a text input that already has a text value (<TextInput value="123" />), its selection (cursor) is automatically set to the end of the text. However, when you swipe to focus the text input with TalkBack, Android decides it needs to clear the selection, which moves the cursor back to the beginning of the text input. This is probably not what you want if you're editing some text that's already there. Ideally we would just keep the selection at the end, but I don't know how to prevent this from happening - it seems to be part of how TextView handles the accessibility focus event? So instead I'm just explicitly setting the selection to the end of the text in our handler for accessibility click.
Changelog: [Android][Fixed] Move selection to the end of the text input on accessibility click
Reviewed By: mdvacca
Differential Revision: D23441077
fbshipit-source-id: 16964f5b106637e55a98c6b0ef0f0041e8e6215d
Summary:
SoLoader fixed crash on Android 4.1, and includes many improvements and fixes https://github.com/facebook/SoLoader/releases/tag/v0.9.0. Also Fresco 2.3.0 depends on it, and will create a PR soon to bump Fresco.
## Changelog
[Android] [Changed] - Bump SoLoader to 0.9.0
Pull Request resolved: https://github.com/facebook/react-native/pull/29821
Test Plan: CI is green
Reviewed By: fkgozali
Differential Revision: D23477538
Pulled By: mdvacca
fbshipit-source-id: d2d982d5c5c84fc173dc66dfe069713ca90711a8
Summary:
After monitoring scuba for a few days, previous fixes(D23301714 D23331828 (https://github.com/facebook/react-native/commit/07a597ad185c8c31ac38bdd4d022b0b880d02859)) don't work as expected.
I managed to test this issue on a Xiaomi device, the crash didn't happen but the there was a popup "Frequetly used email" on top of email edit text:
{F317216473}
Getting rid of the popup probably be the right fix.
For more context see https://github.com/facebook/react-native/issues/27204
Changelog: [Android] - Set caretHidden to true to fix the Xiaomi crash
Reviewed By: mdvacca
Differential Revision: D23451929
fbshipit-source-id: 521931422f3a46a056a9faa4b10fe93cf4732db0
Summary:
This PR tries to remove the code duplication between `RNTesterApp.ios.js` and `RNTesterApp.android.js`. The common code has been moved to `RNTesterAppShared.js`.
This PR also refactors the state architecture and simplifies it to use just one single `useReducer` hook to manage the app's state.
It also adds the visibility hack to make the screen change a little bit faster and removed the unneeded test files.
Pull Request resolved: https://github.com/facebook/react-native/pull/29777
Reviewed By: cpojer
Differential Revision: D23349302
Pulled By: rickhanlonii
fbshipit-source-id: ce0d7b03e6ef65b1655bcb744817b73c5144438b
Summary:
`-all` is the **default** for projects generated by Android Studio, and it provides **additional sources** helpful for debugging. It's also much more likely to already exist on a developer's machine (which has built other Android projects), avoiding additional downloads and saving disk space.
`-all` has also been the variant used in `react-native` for all versions prior to 5bc67b658e.
Follow-up to https://github.com/facebook/react-native/issues/29613
## Changelog
[Android] [Changed] - Use Gradle Wrapper 6.6 (-all variant)
Pull Request resolved: https://github.com/facebook/react-native/pull/29793
Test Plan: No test needed since versions are the same.
Reviewed By: fkgozali
Differential Revision: D23406546
Pulled By: mdvacca
fbshipit-source-id: b74dbbfc0317bccf1940b1e5062d866e50aed28a
Summary:
This diff optimizes the caching of Spannable objects managed by the TextLayoutManager class.
Previously, these objects were cached using unsing a String representation of the RedableMap (creating this string adds a non trivial cost), this diff improves the caching performance relying on the equals / hashcode methods of the ReadableNativeMap class
I created a MC just to have a killswitch
Motivation: I was analysing another bug and I found this non performant code
changelog: [internal] internal
Reviewed By: shergin
Differential Revision: D23429365
fbshipit-source-id: 59e5ad0b1b95da992ac393aecfe029da68a8df97
Summary:
Changes the order of `RCTBorderColors` field designators to match their declaration order, fixing one case of `-Wreorder-init-list` when compiling the RN codebase with Xcode 12.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D23447685
fbshipit-source-id: f04a3841187f0869d2efb60e81ce075c45f27f3c
Summary:
Fixes https://github.com/microsoft/react-native-windows/issues/5867
ScrollResponder has logic so that the first tap exiting out of a soft keyboard is captured instead of leaking to its children. This state is checked by testing if `TextInputState.currentlyFocusedInput()` is non-null. This also fires in cases a soft keyboard is not present (e.g. on Desktop where a physical keyboard is in use). This presents to users as clicks/taps not being registered when moving from a TextInput to something esle.
Instead of checking TextInputState to see if the softKeyboard is open, check `this.keyboardWillOpenTo`, which is tied to keyboard open and close events.
## Changelog
[General] [Fixed] - Prevent ScrollView From Stealing Responder Capture When Using Physical Keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/29798
Test Plan: Validated that on react-native-windows, ScrollView will capture responder events when tapped and a soft-keyboard is open, but will not capture events when clicking from a TextView to a child of a ScrollView and no soft keyboard is open.
Reviewed By: kacieb
Differential Revision: D23426786
Pulled By: TheSavior
fbshipit-source-id: 7138ef0bc4508aaec5531f455b022b105b5d858a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29800
I changed this line in D23272735 (https://github.com/facebook/react-native/commit/700960c9f1a27a12d703b4f0a17673690799f019), to conform to normal ObjC semantics: impl files can import their header by file name.
I forgot that their's some special linking logic happening in this directory that doesn't allow for this import type.
This diff just reverts one line to fix CircleCI builds.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23399893
fbshipit-source-id: 976199c659522effd632aaeb38616d0d6c962f1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29794
Per title - need to declare deps of attrs that we are using (soon Buck will enforce this).
Changelog: declare dependencies of all attributes that are used in the resource target.
Reviewed By: jiawei-lyu
Differential Revision: D23388058
fbshipit-source-id: b395d153188f75f8c0d4a6d69302812a56b23925
Summary:
`#import` is non-standard C++ extension which is AFAIK part of Objective-C. I am surprised that it even compiles on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23407689
fbshipit-source-id: 2861138cbcce33674e118a1ad816e33bbf8f30fe
Summary:
This diff creates the new TransparentImmersiveReactActivity in FB4A, the intention is to help integrate TransparentReactActivity with Fb4A
Changelog: [Deprecated][Android] Deprecated method UIManagerModule.getUIImplementation. This method will not be part of the new architecture of React Native.
Reviewed By: stashuk
Differential Revision: D23324543
fbshipit-source-id: 35395fe410790a9611a4637361b888678eb0a836
Summary:
This updates okhttp to the newest compatible version with a couple of fixes and improvements. See https://github.com/square/okhttp/commits/okhttp_3.12.x
## Changelog
[Android] [Changed] - Update Okhttp to version 3.12.12
Pull Request resolved: https://github.com/facebook/react-native/pull/29741
Test Plan: Current tests should pass.
Reviewed By: shergin
Differential Revision: D23406613
Pulled By: mdvacca
fbshipit-source-id: b0b4ec52a6a8345f1c36e18e384761386096f1d8
Summary:
We have password components which allow visibility to be toggled by
setting both the keyboardType and secureTextEntry props. The order in
which those updates are executed is determined by iterating a NativeMap
of props, and the iteration order of a NativeMap is implementation
dependent.
With libc++ as our STL, we observe that setSecureTextEntry is called
before setKeyboardType. This results in the following sequence of input
type flag settings when toggling the component to visible and then back
to hidden:
* The field starts out with TYPE_TEXT_VARIATION_PASSWORD (0x80).
* When we toggle to visible, setSecureTextEntry is called with password
being false, which clears TYPE_TEXT_VARIATION_PASSWORD.
setKeyboardType is then called with the visible-password keyboard
type, which sets TYPE_TEXT_VARIATION_VISIBLE_PASSWORD (0x90).
* When we toggle back to hidden, setSecureTextEntry is called with
password being true, which sets TYPE_TEXT_VARIATION_PASSWORD but
doesn't clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD. setKeyboardType is
then called with the default keyboard type and additionally sets
TYPE_CLASS_TEXT, but TYPE_TEXT_VARIATION_VISIBLE_PASSWORD remains and
the password field remains visible.
The fix is to clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD when
setSecureTextEntry is called with password being true, to ensure the
password gets hidden.
Changelog:
[Android][Fixed] - Fix secure text entry setting to always hide text
Reviewed By: shergin
Differential Revision: D23399174
fbshipit-source-id: a81deec702e768672e2103b76ab50ec728dac229
Summary:
Changelog:
Sometimes a port different than kRCTBundleURLProviderDefaultPort (8081) can be specified to RCTBundleURLProvider for packager checking or requesting resources through saving them in JSLocation, this adds support for that rather than always falling back to kRCTBundleURLProviderDefaultPort
Reviewed By: PeteTheHeat
Differential Revision: D23395548
fbshipit-source-id: b7a6f0816d1f226a2e3fb82bf2dc0ab9e79ef966
Summary:
Removes `fbjs` dependency from `react-native` because it is no longer referenced.
Changelog:
[General][Changed] - Removed `fbjs` dependency from `react-native`.
Reviewed By: cpojer
Differential Revision: D23358201
fbshipit-source-id: 1945590d2e7ea853434c716a151fc1058718d471
Summary:
Shadow tree introspection was disabled for a while, now we need it back working. This diff also restructures the logic of `MountingCoordinator::pullTransaction()` splitting it into two sections, first one for the base case and the second for the overriding case.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23374948
fbshipit-source-id: 0b5f1c598975bceb3dcb6a0eaee67ff58ef9dda1
Summary:
Just renaming, nothing more.
The idea of MountingTelemetry already grown to something bigger than just mounting telemetry, so we are renaming it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23374947
fbshipit-source-id: f60ce38b75d1ce77498b84688e59598314c69a78
Summary:
Long term fix in native for Error: android_crash:java.lang.NullPointerException:android.widget.Editor$SelectionModifierCursorController.access$300
For more detail please see T68183343 D23301714
Changelog:
[Android][Changed] - Fix Xiaomi TextInput crash in native
Reviewed By: mdvacca
Differential Revision: D23331828
fbshipit-source-id: 914f2d431772f49711b940d47a2b3ef57ab82cdc
Summary:
This diff fixes the initial render of RN Android TextInput. The problem was that "attributedString" was not serialized until an event was sent from native side.
Changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23383969
fbshipit-source-id: 86601434b1fbaa9f712bdb79b013a1d004bc55a4
Summary:
Make sure to check incoming state values before calling SetState, or we call back and forth forever.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D23389355
fbshipit-source-id: 9cf6110cf654fe93f555a6fbfd9b20f112214e0a
Summary:
See title.
This feature makes LayoutAnimations less stable and isn't needed generally; will be deleted soon.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23382973
fbshipit-source-id: f633f482d463b3ee3e4625b30544a33cd6e36119
Summary:
My goal in this diff is to make LayoutAnimations more stable, and more resilient to challenging situations. Namely, LayoutAnimations already works fine with:
1) Reorders
2) Flattening/unflattening
3) Deletion and recreation of the same hierarchy
4) Updates conflicting with an existing animation
However, what if /all/ of those things are combined? Handling update conflicts with multiple ongoing animations, repeatedly flattening/unflattening the same layer of hierarchy and reordering both parents and children, etc .
This diff does not make LayoutAnimations perfect, but it does make LayoutAnimations much more resilient to situations it was not able to handle before.
My primary method of testing was to use two Playground examples: one just repeatedly queues up mutations (some animated, some not) that create, update, and delete in the same hierarchy layer. The second, more complex one, mutates between random view hierarchies that involve a lot of flattening and unflattening as well as reordering, over a depth of 5. It also exercises animations over TextInlineViews, which is more challenging.
LayoutAnimations works best with the new "Flattening Differ" for now, because the Flattening Differ produces a much smaller, nearly minimal set of instructions in cases of flattening-unflattening. I would like that to not be a hard requirement for using LayoutAnimations, but it's a good starting-point for now.
As part of this work, I also developed a lot of debugging and logging mechanisms that are handy for detecting inconsistencies and debugging crashes. Some are included in this diff behind `#define` statements that are disabled by default, and the rest will be published separately and likely cannot be landed permanently, as they're more invasive changes that are only helpful in debugging.
# Followups:
- Automate testing: write a suite of C++ tests that mutates between random diffs and guarantees that all mutations in a StubViewTree are sensible
- Construct a set of minimal repros that catalogues all remaining crashes and inconsistency issues (these seem to be extremely marginal cases and are very hard to repro - so I think it's fine to run this in prod for now, but I will follow-up as soon as I'm back to catalogue and fix all remaining issues)
- This diff focuses on *not crashing*, but it is still possible to construct a sequence of complex mutations that results in (for example) views having some opacity between 0 and 1 if animations are interrupted repeatedly. Although this is easy enough to prevent in product code - the types of scenarios I'm running in tests are very unlikely to ever happen in production - it would be nice to be *sure* that LayoutAnimations will always converge to a sensible View hierarchy with up-to-date props.
- In general, the index adjustment logic is complicated. I don't know if there's a great way around it, so I need to at least catalogue and test all edge-cases as mentioned above.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23382975
fbshipit-source-id: f379d9aa2a4b9c33fa2ba8fa07870c9e31fad5e7
Summary:
In some cases (BottomSheet?) the parent/ViewManager removes all children of the View before Fabric gets a chance to remove the children.
Apparently prior to D23368229 (https://github.com/facebook/react-native/commit/d344fb4e29a827d1e7d233672a3efe3b2b981a8a) (landed just today!) this sequence of operations happened and just noop'ed. Since we've been doing that happily as long as Fabric
has existed, we'll keep doing that for now.
I suspect that on *some* versions of Android this crashes and others it doesn't, based on logviews and my inability to repro certain crashes.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23387044
fbshipit-source-id: 88a46191adef4f6816bd7babd9103d103ddcef33
Summary:
Cleans up the documentation and types for `ImageSource`.
The only material changes here are:
- `ImageSource`'s array variant will now be `$ReadOnlyArray` instead of `Array`.
- `ImageURISource.headers` is now an object of string properties.
Changelog:
[General][Changed] - Refined `ImageSource` Flow type for array-variant and headers.
Reviewed By: kacieb
Differential Revision: D23355812
fbshipit-source-id: c3407db037dfb1d3514a028d1a237eb76ee6fedd
Summary:
We disabled animations on Android because native driver animations weren't working yet. After recent changes in NativeAnimatedModule, animations are now working as expected. This diff re-enables animations for bridgeless mode on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22605612
fbshipit-source-id: 7a7078bf23bb88e7745fc899e1a5ff551425dbad
Tommy Nguyen
Samuel Susla
Valentin Shergin
Tim Yung
Frieder Bluemle
Kevin Gozali
Nat Mote
Héctor Ramos
Rubén Norte
Emily Janzer
Héctor Ramos
Dulmandakh
Rick Hanlon
Lulu Wu
Ankit Tiwari
chirag-singhal
David Vacca
Moti Zilberman
Nick Gerleman
Peter Argany
Ian Childs
Hamid
Shoaib Meenai
Jimmy Zhang
Joshua Gross
Agastya Darma