Summary:
This diff is fixing a NullPointerException occuring when using Placeholder in TextInput. In some particular scenarios Placeholder is being updated before the TextInput is even layed out.
In this diff I'm setting a defult LayoutParams to avoid NullPointerException to be thrown by android EditTextView. This change should not affect layout for TextInput components because layout will be overriden on the next Fabric commit.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D42078080
fbshipit-source-id: 294376e7f78d6ed58fc9f893553356553accba6c
Summary:
This is a two step (1/2) fix to a race that could caused a `DELETE`...`CREATE` mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ, yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This race condition could cause a view to get deleted at the end of one UI frame, yet the mount instructions generated from animation in the next frame still need to access the deleted view and caused crashes like T112157805. Note that even though such crash is recorded as `RetryableMountingLayerException` and is a soft crash (which only gets logged but not crash in production), the out-of-order mount instructions could lead to illegal view state and make the surface unusable, like what's shown here:
{F820669000}
The diff fixes this issue by removing the `DELETE` [conflict animation](https://fburl.com/code/5ctckvz3) keyframe, as well as the `CREATE` [immediate mutations](https://fburl.com/code/txyomytd) from the layout animation. The Fabric mounting layer assumes no combination of `DELETE...CREATE` in the same frame from differ + [layout animation overrides](https://fburl.com/code/zn17uqch).
Reviewed By: sammy-SC
Differential Revision: D41895427
fbshipit-source-id: d6df02663ba707af6db4a63a325ac776ca54d18e
Summary:
Previous diff D41486648 is causing crashes and a sev S311353, which is due to usages of an old Android API that only work after level 24 (D36500518 (https://github.com/facebook/react-native/commit/0fc42fd35c577c71825f020b0fa09bee6d9ad105)). ~~This diff updates the implementation to use a compatible API, but with worse runtime complexity.~~
~~https://fburl.com/txd0r89e is a good explanation on the two algorithm to calculate a streaming median value. This diff uses the approach described in https://stackoverflow.com/a/4903642.~~
## Update
Following suggestion from sshic, I preserved the existing algorithm but with a custom comparator approach.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D41505143
fbshipit-source-id: 494e07fa627b5cf8bad7971fa5de86d270a7412c
Summary:
Delete references of CppComponentRegistry from the internals of React Native Android renderer, since it's not necessary anymore
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638890
fbshipit-source-id: c4b08853722874dbb21891817836862225469dd9
Summary:
This diff deletes the first implementation of C++ ViewManagers integrated into the internals of Fabric
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638894
fbshipit-source-id: 2e7aebff587e2e57b7f3fbf37a24b04943c74573
Summary:
We have the expected module name available as part of the codegen schema, so we can remove the need for developers to implement the `getName` method as part of their module implementation.
Note that this method is not actually used when the TurboModules infra is used, as the moduleName from the turbo module manager is passed through to the TurboModule base class instead. Moving the method to codegen will make it easier to remove this method altogether once the old architecture is fully removed.
Changelog: [Android][Added] Support generating `getName` in react-native-codegen for Java TurboModules
Reviewed By: mdvacca
Differential Revision: D41615387
fbshipit-source-id: 6b117645fa39e5e9ab014b21198496a52f6f2ae2
Summary:
Newer versions of Buck (not released open source) support an `oncall` annotation to denote who owns a particular BUCK file. These annotations are useful to support so that if BUCK files are updated with such annotations they don't break.
## Changelog
[Internal] [Changed] - support oncall annotation in BUCK files
Pull Request resolved: https://github.com/facebook/react-native/pull/35562
Test Plan: The `test_buck` CI job validates that the file can be evaluated by open-source Buck. I ran this on a CircleCI fork, and it passed.
Reviewed By: motiz88
Differential Revision: D41731925
Pulled By: cortinico
fbshipit-source-id: 7d0ae164c3e6289d4aa76892658d46bbe4faf99c
Summary:
Consolidates creation of OkHttpClients used by RN panel apps into PanelAppOkHttpClientProvider. This diff adds no functional changes; however, a followup diff will leverage this to add an Interceptor for overriding the network tier.
Changelog:
[Internal] - Enable passing in custom OkHttpClient to NetworkingModule
Reviewed By: rshest
Differential Revision: D41621244
fbshipit-source-id: 8954f9adc6a0cfdf6312678e2dbd6be8ef9aa5ca
Summary:
Color support for AnimatedInterpolation was incomplete with native drivers, as only rgba type strings were supported. There was also an issue where color props instead a StyleAnimatedNode would never get applied. We were also potentially duplicating color parsing support, which is already centralized in `normalizeColor` / `processColor`.
Changelog: [Android][Added] Enable AnimatedInterpolation to interpolate arbitrary color types.
Reviewed By: mdvacca
Differential Revision: D40571873
fbshipit-source-id: 41857ab0391279c5307bc31b855ea8fbcb4cccd8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
Noticed that we weren't receiving pointer events for nested Text spans when the new pointer events implementation was enabled.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D41496672
fbshipit-source-id: 9d0ed83d1bb5f42211ec655328035651f25fa471
Summary: Changelog: [Internal] - Internal usage broke existing behavior, reverting to check if a flag is set.
Reviewed By: javache
Differential Revision: D41502122
fbshipit-source-id: 296bb1578cd63f935e4111bfec8d58f965149640
Summary:
We have two warnings on MapBuffer which I'd like to resolve as they show up on console every time.
1. We're using a deprecated method receiveCommand, which is actually legit but was missing a propagation of the warning. I'm adding it.
2. We had a null check that that was always not null. That is enforced by the Kotlin type system. I've checked the code and
we're actually always returning non-nulls there or raising exceptions instead.
Changelog:
[Internal] [Changed] - Fix compilation warnings for MapBuffer
Reviewed By: javache
Differential Revision: D41522129
fbshipit-source-id: c2dbb660f95a2ff7dac6e4fcdf476e4058cf730e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
In this diff I'm refactoring ViewGroupManager to implement IViewGroupManager
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386918
fbshipit-source-id: 427b9689eb3408c2477cf38494d42280b41fd7d8
Summary:
In this diff I'm introducing IViewGroupManager to extract methods required to add/remove views from a viewGroup
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386920
fbshipit-source-id: a7d893d92d0f12766dcc71dfd1b22539c3b9687d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35392
Changelog:
[General][Added] - For supporting Dev Loading View across platforms, adding the DevLoadingViewController without an activity/context.
Reviewed By: rshest
Differential Revision: D40947239
fbshipit-source-id: de124b0a7ee39dc7da3c1c45972a6703eff2f0ef
Summary:
From exception logging, found crashes due to `Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference`. Tracing through the stack, it appears the constructor for `ViewGroup` conditionally calls `initializeScrollbarsInternal()`, which in turn calls `getChildCount()`. However `ReactModalHostView` overrides `getChildCount()`, so `getChildCount()` is called before `ReactModalHostView` constructor completes, resulting in null reference when accessing `mHostView` from `getChildCount()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix crash on initialize modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35380
Test Plan: In the rn-tester project, display a modal.
Reviewed By: javache, cipolleschi
Differential Revision: D41392235
Pulled By: ryancat
fbshipit-source-id: ce78e4d458ad41769e78139ea0a8a038384e830d
Summary:
at some point, the `Build.FINGERPRINT` of the emulator has changed and no longer includes `generic` as an option.
It apparently now, on all platforms, includes `google/sdk_gphone` at the beginning. Older emulators may still include `generic` in the `Build.FINGERPRINT` so we should maintain that check too.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix android emulator detection for packager host
Pull Request resolved: https://github.com/facebook/react-native/pull/35111
Test Plan: When running on a modern emulator, ensure that the packager attempts to load from `10.0.2.2`.
Reviewed By: cipolleschi
Differential Revision: D41266071
Pulled By: GijsWeterings
fbshipit-source-id: 43115dbde6a411fe2ebde23e720dff4812a4309f
Summary:
Changelog:
[Internal][Changeded] - https://github.com/facebook/react-native/pull/31841 introduced customisations for DevSupportManager which made this create() redundant, hence deprecating and adding the annotation.
Reviewed By: cipolleschi
Differential Revision: D41292920
fbshipit-source-id: 9fc348a3f4f8f64ba6f7aee85f302e87e10e8cd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35256
Changelog:
[General][Added] - Making Dev Loading View cross platform by abstracting out the activity/context logic from the controller in a polymorph class.
Reviewed By: rshest
Differential Revision: D40908923
fbshipit-source-id: db8e94f8ded5ffe0deeb88335cd7f3d1bf87243a
Summary:
When a __rounded__ View on Android has a border, a small gap appears between the border and the center of the view (most noticeably when the background and border colors are the same)
Since the border is drawn on top of the other layers, the approach here is to make the center of the View slightly larger so that there is an overlap with the border, and closing the visible gap
There are 2 cases for a View with a border:
1. `borderWidth` is set for a consistent border width around all 4 edges
2. Uneven border widths are set (using `borderTopWidth`, `borderLeftWidth, ...)
**How is a rounded rectangle drawn?**
__Case 1__: `borderWidth` is set for a consistent border width around all 4 edges
- Before:
- first, `mInnerClipPathForBorderRadius` was used to draw the center of the View
- then the border is drawn along the path of `mCenterDraw` with a stroke width of the border width
- Now:
- `mBackgroundColorRenderPath` is used to draw the center of the View and is exactly a slightly enlarged version of `mInnerClipPathForBorderRadius`
__Case 2__: Uneven border widths are set (using borderTopWidth, borderLeftWidth, ...)
- Before:
- `mInnerClipPathForBorderRadius` was used to draw the center of the View
- for each edge, a quadrilateral is drawn
- `mOuterClipPathForBorderRadius` clips the outer edge of the border
- `mInnerClipPathForBorderRadius` (same is used to draw the center of the View) clips the inner edge of the border
- Now:
- `mBackgroundColorRenderPath` is used to draw the center of the View, allowing `mInnerClipPathForBorderRadius` to persist as the path that clips the inner edge of the border
When `mGapBetweenPaths` = 0, `mBackgroundColorRenderPath` == `mInnerClipPathForBorderRadius`, which is exactly the original implementation
Changelog:
[Internal][Fixed] - rounded Views with borders shows small gap
Reviewed By: mdvacca
Differential Revision: D39979567
fbshipit-source-id: 6db71d14ead6256e1b7becf73862e0a537c6a47b
Summary:
>Expandable and Collapsible are unique in the Android Accessibility API, in that they are not represented as properties on the View or AccessibilityNodeInfo, but are only represented as AccessibilityActions on the AccessibilityNodeInfo. This means that Talkback determines whether or not a node is "expandable" or "collapsible", or potentially even both, by looking at the list of AccessibilityActions attached to the AccessibilityNodeInfo.
>When setting the accessibilityState's expandable property, it should correlate to adding an action of either AccessibilityNodeInfoCompat.ACTION_EXPAND or AccessibilityNodeInfoCompat.ACTION_COLLAPSE on the AccessibilityNodeInfo. This work should be done in the ReactAccessibilityDelegate class's
>Currently, this feature is being "faked" by appending to the contentDescription in the BaseViewManager class. This should be removed when this feature is implemented properly.
fixes https://github.com/facebook/react-native/issues/30841
## Changelog
[Android] [Fixed] - using AccessibilityNodeInfo#addAction to announce Expandable/Collapsible State
Pull Request resolved: https://github.com/facebook/react-native/pull/34353
Test Plan:
- On some components, the state expanded/collapsed is properly announced on focus, on some it is not.
- On some components only the expanded/collapsed state is announced, and not other component text.
- Upon change, state change is not always announced.
- The accessibilityState's "expanded" field does not seem to work on all element types (for example, it has no effect on 's).
- using accessibilityActions it is possible to add an action for expand/collapse, but these are treated as custom actions and must have their own label defined, rather than using Androids built in expand/collapse actions, which Talkback has predefined labels for.
https://snack.expo.io/0YOQfXFBi
Tests 15th August 2022:
- Paper [Tests](https://github.com/facebook/react-native/pull/34353#issuecomment-1217425302)
- Fabric [Tests](https://github.com/facebook/react-native/pull/34353#issuecomment-1217781734)
Tests 6th September 2022:
- [Button which keeps control of extended/collapsed state in JavaScript with onAccessibilityAction, accessibilityActions and accessibiltyState (Paper)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237601847)
- [TouchableWithoutFeedback keeps control of extended/collapsed state in Android Widget (Paper)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237616304)
- [TouchableWithoutFeedback keeps control of extended/collapsed state in Android Widget (Fabric)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237624755)
- [TouchableOpacity announces visible text and triggers expanded/collapsed with onPress and accessiblity menu (Fabric)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237627857)
Announcing state with custom actions on Fabric (FAIL).
The issue is not a regression from this PR, as documented in https://github.com/facebook/react-native/pull/34353#issuecomment-1207744977. It will be fixed in a separate PR.
Reviewed By: NickGerleman
Differential Revision: D39893863
Pulled By: blavalla
fbshipit-source-id: f6af78b1839ba7d97eca052bd258faae00cbd27b
Summary:
Changelog:
[Internal][Changed] - In order to make Dev Loading View cross platform, refactoring the accessary show methods.
Reviewed By: cortinico
Differential Revision: D41029102
fbshipit-source-id: 475949548fe98217e61d6cf64accbbdc0fb0f1c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35163
# What
This diff contains all the changes from D40333083 (https://github.com/facebook/react-native/commit/0fac9817df403e31d8256befe52409c948614706) (aka https://github.com/facebook/react-native/pull/34964), **except** the change to `setUpReactDevTools.js`, which actually uses the new files.
# Why
* We want to ship the Buck, C++, etc. changes before the JavaScript changes that depend on those files.
* Otherwise, apps can fail at startup with the message:
```
`TurboModuleRegistry.getEnforcing(...): '${name}' could not be found. ` +
'Verify that a module by this name is registered in the native binary.',
```
* Note that this only occurs if you are using a previously-built version of the C++, Obj C, etc. files in RN, but a more recent version of the JavaScript files. If you are building from matching sources, this does not occur.
* After a few days, we can land the JS files.
## Changelog
Changelog
[General][Added] Add, but don't use, DevTools Settings Manager.
Reviewed By: NickGerleman
Differential Revision: D40873390
fbshipit-source-id: c7bac6ae65f85666b8616443db278ebb175b691b
Summary:
This is the 2nd iteration of D39468561 (https://github.com/facebook/react-native/commit/4d1a56813c7975c848631de331e424587054fd57). We first check if the `BridgeDevSupportManager` can be used before we return the `PerfTestDevSupportManager`. This is to avoid a breakage of Quantum that happened on the previous diff.
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
This is now conceptually the new flow for deciding what DevSupportManager to choose.
```
if (developerSupportEnabled) {
if (full support available) {
use full support (i.e. bridge)
} else {
use profiling-only support (i.e. perftest)
}
} else {
disable dev support
}
```
The first attempt at this diff erroneously used this logic:
```
if (developerSupportEnabled) {
if (debug build) {
use full support (i.e. bridge)
} else {
use profiling-only support (i.e. perftest)
}
} else {
disable dev support
}
```
So now we are always checking to see if the `BridgeDevSupportManager` is available, and if it is, we use it.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D40948243
fbshipit-source-id: 50c6b6b905f5b9c5b5ecc090b36edbd6090ea774
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
David Vacca
Xin Chen
generatedunixname89002005325672
Lulu Wu
fabriziobertoglio1987
Fredia Huya-Kouadio
Alexander Oprisnik
Pieter De Baets
Robert Balicki
Neil Mitchell
Genki Kondo
Nicola Corti
Luna Wei
Arushi Kesarwani
Alpha
Ellis Tsung
David Buchan-Swanson
Sharon Zheng
generatedunixname89002005287564
Ramanpreet Nara
Michael Anthony Leon