[Investigation] ANRs Using Multiline TextInput on Samsung Devices #35936

NickGerleman · 2023-01-23T21:39:30Z

NEW UPDATE: we have now released patch releases containing the second wave of fix for:

UPDATE: we have now released a patch release containing the first mitigation for all the supported versions of React Native plus 0.68 (since it's still used by a significant number of users):

Please upgrade to those versions and report back here if it helps! We are still planning to do further investigation, but don't expect any new releases concerning this topic for at least a couple weeks (unless something unexpected happens).

There have been repeated and persistent signals of ANRs (hangs) when typing into a multiline TextInput on Samsung phones. This is most reported by using the out-of-the-box keyboard provided by Samsung One UI 5. We have been able to locally reproduce the hangs on two separate Galaxy S22 devices. Most devices will not be as fast as the ones we have tested on.

Impact

The issue presents as repeated hangs or ANRs when typing into a TextInput which has a large amount of text. It is specific to the Samsung soft keyboard, and does not reproduce when using other keyboards like GBoard on the same device. There are a different set of TextInputs where we have confirmed impact depending on whether Fabric is enabled or disabled.

Fabric enabled

Both controlled and uncontrolled TextInputs are impacted.

Fabric disabled

Controlled TextInputs and uncontrolled TextInputs which set an initial value via child are impacted.

Root causing

Root causing the issue focused on:

Locally profiling the hang under different scenarios
Examining which span differences create the hang
Reproducing the issue outside of React Native

Profiling

We saw similar results to the trace already shared in #35590. A Java sampling profiler shows the process com.samsung.android.honeyboard has a very long running frame, delivering input.

This triggers code on the main thread, in the app process, where we see a hang happen while committing a text change from the IME to the underlying Spannable backing the EditText. The hang happens in an event handler which has subscribed to changes to the underlying text. The long-running work seems to be laying out the text.

Because the hang happens in response to an edit to the underlying Spannable, investigation focused on the Spannable content differences in scenarios which created ANRs vs not.

Spannable differences between hang/no hang

We examined typing into the below example, which may hang on Fabric but not Paper:

<TextInput multiline={true} />

Grammarly annotations were present as SuggestionSpan spans on both platforms. On Fabric but not paper there was the presence of AbsoluteSizeSpan spans, which set the font size within the text. This is akin to setting <span style=”font-size: 12px”}>Text</span> within a browser.

When we stubbed out platform code in React Native which set an AbsoluteSizeSpan, that example along with another previously hanging example would no longer hang. The hang was possible to trigger in an uncontrolled TextInput with a short string like “Text Here” as a child, so we attempted to repro the logical extreme, where we add a single span setting font size to the TextInput.

Reproducing outside of React Native

We discovered that adding even a single inclusive span (specifically setting font size) is enough to create hangs. This can reproduced by:

Adding an EditText with an inputType of textMultiLine.
Adding an inclusive span setting font size: E.g. str.setSpan(new AbsoluteSizeSpan(55), 0, string.length(), Spanned.SPAN_INCLUSIVE_INCLUSIVE)
Pasting a large amount of text then starting to type.

We were able to create a repro for this on top of a template Android application. The issue only happens when using the Samsung keyboard.

reproducervideo.mp4

Grammarly annotations are not shown locally when changing the appId and namespace of the repro to com.facebook.katana (the ID of the Facebook app). This implies the Facebook app may be being special-cased, contributing to the lack of internal signal on the issue. This only happened on 1/2 devices, so it's possible there might be some setting or association that wasn't fresh.

Remediation

While the underlying issue seems to be outside of React Native, the issue still has a real-world effect on our users. We are starting the process to mitigate the issue by working to notify Samsung. This issue has already shown signs of impacting the Android app ecosystem outside of React Native and the ability to set spans with formatting like font size is a fundamentally important part of the platform.

We hope this issue will be addressed in a future update from Samsung, but this does not address the already-present impact of the issue. A potential mitigation which we are exploring is whether React Native could avoid adding AbsoluteSizeSpan (or formatting spans in general) in more common cases.

There have been previously discovered workarounds for the issue, such as setting keyboardType to visible-password. We recommend against preemptively using these workarounds, due to impact on UX and accessibility.

The text was updated successfully, but these errors were encountered:

jefflewis · 2023-01-24T14:13:49Z

One solution we've tried that doesn't involve changing the field type to get rid of suggestive text and avoid the entire problem class is a horrible hacky solution that can work... We made a web view and post a message from the onchange listener to the react view. Maybe that helps find a workaround?

So a native app, with the react runtime, running a webview with a textinput whose sole purpose is to provide state back to the react view. 😅

econner · 2023-01-24T17:47:20Z

Hi, this issue also affects Pixel phones based on our logs of ANRs as well as many comments in the other thread. Are you also notifying Google? Or is there another potential issue w/ Pixel phones?

See:
#35155 (comment)
#35155 (comment)
https://support.google.com/pixelphone/thread/181332682/keyboard-freezing-after-android-13-update?hl=en

Thanks.

NickGerleman · 2023-01-24T22:14:05Z

Hi, this issue also affects Pixel phones based on our logs of ANRs as well as many comments in the other thread. Are you also notifying Google? Or is there another potential issue w/ Pixel phones?

See: #35155 (comment) #35155 (comment) https://support.google.com/pixelphone/thread/181332682/keyboard-freezing-after-android-13-update?hl=en

Thanks.

Would you mind creating a separate issue for this? It's hard to tell if the issue is related, but using GBoard on Samsung devices does not repro this specific issue we are tracking.

Summary: In facebook#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 the most common cases, when it is sufficient to set `android:textSize`. In simple cases, it causes typing into the TextInput to no longer hang. This does not 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 could potentially do further work to reduce the number of spans emitted in these scenarios, but this may be fighting a losing battle against the platform. Changelog: [Android][Fixed] - Partial Mitigation for Samsung TextInput Hangs (Paper) Reviewed By: cortinico Differential Revision: D42721684 fbshipit-source-id: 5599070f10a385c6063683e3ac7a5acbbdc10ae9

NickGerleman · 2023-01-25T19:41:36Z

Hey folks! We think we have a mitigation for common cases of this issue. Please see PR #35967 for some more information about where it may or may not work.

For folks impacted by hangs specific to the Samsung keyboard on Android 13, we would like feedback on whether the change resolves the issue. Based on the signal we get, we will backport to RN 0.68+. Please give feedback directly on the PR.

Please note that because this package impacts build artifacts, tools like patch-package or local edits to the source will not result in a change if consuming React Native by NPM package. It can instead be tested either by building React Native from source, or by updating to a nightly we will publish soon after the change is merged (it looks like it will just miss the one scheduled to start 20 minutes from now). I will update this comment once a nightly is available with the fix, later today or tomorrow.

Edit: React Native 0.0.0-20230126-2108-53932d002 has this fix.

dozoisch · 2023-01-25T23:33:11Z

@NickGerleman thank you for the update! Really appreciate it.

Not sure if there are nightlies being built for 0.68/0.69, but if the fix is backported earlier to those, we'll be happy to help with testing. Unfortunately can't update quickly to 0.71 right now.

We're currently looking to see if we can build from sources to test the fix, but with the backport, we would be able to help test faster!

Summary: Pull Request resolved: facebook#35967 In facebook#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 the most common cases, when it is sufficient to set `android:textSize`. In simple cases, it causes typing into the TextInput to no longer hang. This does not 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 could potentially do further work to reduce the number of spans emitted in these scenarios, but this may be fighting a losing battle against the platform. Changelog: [Android][Fixed] - Partial Mitigation for Samsung TextInput Hangs (Paper) Reviewed By: cortinico Differential Revision: D42721684 fbshipit-source-id: 1b6935014c8055c3bd547c7ba5294bb9975479c2

Summary: Pull Request resolved: facebook#35967 In facebook#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: ec15bf996a6918cadbb53f9d371281e83bb6208e

NickGerleman · 2023-01-26T04:02:16Z

As a reminder, we're only looking for feedback in this particular thread from folks impacting by hangs specific to Samsung keyboard on A13, and that applying the fix to node_modules will not apply the change since it is reliant on packaged build artifacts.

@NickGerleman thank you for the update! Really appreciate it.

Not sure if there are nightlies being built for 0.68/0.69, but if the fix is backported earlier to those, we'll be happy to help with testing. Unfortunately can't update quickly to 0.71 right now.

We're currently looking to see if we can build from sources to test the fix, but with the backport, we would be able to help test faster!

@dozoisch I pushed a new revision, which should work on Fabric, and also reduce the number of Spans in more complicated cases like non-uniform text sizes. We may end up just backporting this into the wild. I don't know we will get a lot of folks who will use the nightly or build from source.

Summary: Pull Request resolved: facebook#35967 In facebook#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: 000a8ceb0200abb19a2aa77cdb78276d289c3115

Summary: Pull Request resolved: #35967 In #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

dozoisch · 2023-01-26T15:22:46Z

Thanks, @NickGerleman! I saw that it landed on main yesterday. Happy to test it as soon as it gets published on 0.68 or 0.69. Keep us posted 🙌

cortinico · 2023-01-27T08:52:05Z

Hi all,
As @NickGerleman mentioned, we released a nightly version (specifically 0.0.0-20230126-2108-53932d002) that can be used to verify that the issue is solved. We'd be happy if someone could try it out and confirm that the fix is effectively working.

Just a heads up that nightlies are considered not production ready as they haven't been tested as thoroughly as stable releases. This is just a mechanism we have in place to let developers evaluate a feature or test a patch like in this case.

How to test it on a new project.

Create a new project with npx react-native init RNNightly --version nightly
Try to type in a Multiline TextInput on a Samsung device (you can use the reproducer in TextInput hangs with Samsung keyboard's Grammarly integration #35590).

Creating a new project is going to be the easiest way to test this.

How to test it on an existing project.

Testing this patch in your existing project can be done as follows:

First make sure you're on the latest stable version of React Native: 0.71.1
Update your project manually to the nightly using the following diff (that's similar to the output you'll see on the upgrade helper).

diff --color -r 0.71.1/RNDiffProj/.eslintrc.js nightly/RNDiffProj/.eslintrc.js
3c3
<   extends: '@react-native-community',
---
>   extends: '@react-native',
diff --color -r 0.71.1/RNDiffProj/.gitignore nightly/RNDiffProj/.gitignore
63a64,66
>
> # testing
> /coverage
diff --color -r 0.71.1/RNDiffProj/.ruby-version nightly/RNDiffProj/.ruby-version
1c1
< 2.7.6
---
> 2.7.0
diff --color -r 0.71.1/RNDiffProj/.watchmanconfig nightly/RNDiffProj/.watchmanconfig
1c1
< {}
\ No newline at end of file
---
> {}
Only in 0.71.1/RNDiffProj/__tests__: App-test.tsx
Only in nightly/RNDiffProj/__tests__: App.test.tsx
diff --color -r 0.71.1/RNDiffProj/_node-version nightly/RNDiffProj/_node-version
1c1
< 16
---
> 18
diff --color -r 0.71.1/RNDiffProj/android/app/build.gradle nightly/RNDiffProj/android/app/build.gradle
16,17c16,17
<     //   The folder where the react-native Codegen package is. Default is ../node_modules/react-native-codegen
<     // codegenDir = file("../node_modules/react-native-codegen")
---
>     //   The folder where the react-native Codegen package is. Default is ../node_modules/@react-native/codegen
>     // codegenDir = file("../node_modules/@react-native/codegen")
diff --color -r 0.71.1/RNDiffProj/android/app/src/main/res/drawable/rn_edit_text_material.xml nightly/RNDiffProj/android/app/src/main/res/drawable/rn_edit_text_material.xml
23c23
<         <!--
---
>         <!--
Binary files 0.71.1/RNDiffProj/android/gradle/wrapper/gradle-wrapper.jar and nightly/RNDiffProj/android/gradle/wrapper/gradle-wrapper.jar differ
diff --color -r 0.71.1/RNDiffProj/android/gradle/wrapper/gradle-wrapper.properties nightly/RNDiffProj/android/gradle/wrapper/gradle-wrapper.properties
3c3
< distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
---
> distributionUrl=https\://services.gradle.org/distributions/gradle-7.6-bin.zip
diff --color -r 0.71.1/RNDiffProj/android/gradle.properties nightly/RNDiffProj/android/gradle.properties
28c28
< FLIPPER_VERSION=0.125.0
---
> FLIPPER_VERSION=0.174.0
diff --color -r 0.71.1/RNDiffProj/android/gradlew nightly/RNDiffProj/android/gradlew
207a208,213
> # Stop when "xargs" is not available.
> if ! command -v xargs >/dev/null 2>&1
> then
>     die "xargs is not available"
> fi
>
diff --color -r 0.71.1/RNDiffProj/android/gradlew.bat nightly/RNDiffProj/android/gradlew.bat
17c17
< @if "%DEBUG%" == "" @echo off
---
> @if "%DEBUG%"=="" @echo off
28c28
< if "%DIRNAME%" == "" set DIRNAME=.
---
> if "%DIRNAME%"=="" set DIRNAME=.
43c43
< if "%ERRORLEVEL%" == "0" goto execute
---
> if %ERRORLEVEL% equ 0 goto execute
78c78
< if "%ERRORLEVEL%"=="0" goto mainEnd
---
> if %ERRORLEVEL% equ 0 goto mainEnd
83,84c83,86
< if  not "" == "%GRADLE_EXIT_CONSOLE%" exit 1
< exit /b 1
---
> set EXIT_CODE=%ERRORLEVEL%
> if %EXIT_CODE% equ 0 set EXIT_CODE=1
> if not ""=="%GRADLE_EXIT_CONSOLE%" exit %EXIT_CODE%
> exit /b %EXIT_CODE%
diff --color -r 0.71.1/RNDiffProj/android/settings.gradle nightly/RNDiffProj/android/settings.gradle
4c4
< includeBuild('../node_modules/react-native-gradle-plugin')
---
> includeBuild('../node_modules/@react-native/gradle-plugin')
diff --color -r 0.71.1/RNDiffProj/app.json nightly/RNDiffProj/app.json
4c4
< }
\ No newline at end of file
---
> }
diff --color -r 0.71.1/RNDiffProj/ios/Podfile nightly/RNDiffProj/ios/Podfile
33,34d32
<     # Upcoming versions of React Native may rely on get_default_flags(), but
<     # we make it explicit here to aid in the React Native upgrade process.
51a50
>     # https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L197-L202
54,55d52
<       # Set `mac_catalyst_enabled` to `true` in order to apply patches
<       # necessary for Mac Catalyst builds
diff --color -r 0.71.1/RNDiffProj/ios/RNDiffProj/AppDelegate.mm nightly/RNDiffProj/ios/RNDiffProj/AppDelegate.mm
26c26
< /// This method controls whether the `concurrentRoot`feature of React18 is turned on or off.
---
> /// This method controls whether the `concurrentRoot` feature of React18 is turned on or off.
Only in nightly/RNDiffProj: jest.config.js
diff --color -r 0.71.1/RNDiffProj/package.json nightly/RNDiffProj/package.json
14c14
<     "react-native": "0.71.1"
---
>     "react-native": "0.0.0-20230126-2108-53932d002"
19,20c19,20
<     "@babel/runtime": "^7.20.0",
<     "@react-native-community/eslint-config": "^3.0.0",
---
>     "@babel/runtime": "^7.12.5",
>     "@react-native/eslint-config": "^0.72.1",
28c28
<     "metro-react-native-babel-preset": "0.73.7",
---
>     "metro-react-native-babel-preset": "0.73.5",
32,34d31
<   },
<   "jest": {
<     "preset": "react-native"

Next steps

As nightlies are not supposed to be used for production, once we have enough confidence that this fix is working well, we'll be pushing point releases for our stable versions.

For the time being, please comment to this issue by providing feedback on the latest nightly and we'll keep you posted on how we're going to proceed.

rikur · 2023-01-29T18:15:34Z

Applying the patch from the PR and building from source did not solve our ANRs on Samsung devices running Android 13.

NickGerleman · 2023-01-30T05:49:36Z

@rikur could you help by clarifying:

How you built the patched app from source?
Is your TextInput controlled or uncontrolled?
Do you use any formatting in your TextInput?
Does your scenario also lag with GBoard?

Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 (cherry picked from commit e89d23c)

Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 (cherry picked from commit 2e2ce8a)

Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 (cherry picked from commit 77bd902)

…k#36575) Summary: Pull Request resolved: facebook#36575 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]( facebook#35936 (comment)) for greater context on the platform behavior. D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all. We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding. Changelog: [Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()` Reviewed By: javache Differential Revision: D44298159 fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002 # Conflicts: # ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java (cherry picked from commit 181bd38)

Summary: Pull Request resolved: facebook#35967 In facebook#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: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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

…ic (facebook#36546) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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

Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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: facebook#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]( facebook#35936 (comment)) 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: facebook#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]( facebook#35936 (comment)) 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: facebook#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]( facebook#35936 (comment)) 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: facebook#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]( facebook#35936 (comment)) 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: facebook#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]( facebook#35936 (comment)) 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

…k#36575) Summary: Pull Request resolved: facebook#36575 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]( facebook#35936 (comment)) for greater context on the platform behavior. D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all. We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding. Changelog: [Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()` Reviewed By: javache Differential Revision: D44298159 fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002

@AlexanderEggers

* [LOCAL] update podlock post release to fix CI * Fix measurement of uncontrolled TextInput after edit Summary: D42721684 (facebook@be69c8b) 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 * Minimize EditText Spans 1/9: Fix precedence (facebook#36543) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 2/9: Make stripAttributeEquivalentSpans generic (facebook#36546) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 3/9: ReactBackgroundColorSpan (facebook#36547) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 4/9: ReactForegroundColorSpan (facebook#36545) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 5/9: Strikethrough and Underline (facebook#36544) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 6/9: letterSpacing (facebook#36548) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 7/9: Avoid temp list (facebook#36576) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 8/9: CustomStyleSpan (facebook#36577) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Mimimize EditText Spans 9/9: Remove addSpansForMeasurement() (facebook#36575) Summary: Pull Request resolved: facebook#36575 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]( facebook#35936 (comment)) for greater context on the platform behavior. D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all. We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding. Changelog: [Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()` Reviewed By: javache Differential Revision: D44298159 fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002 # Conflicts: # ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java * Use RN Build Utils for Building Hermes Artifacts Summary: We moved Hermes some build utils from [Hermes repo](https://github.com/facebook/hermes/tree/main/utils) to [React Navtie repo](https://github.com/facebook/react-native/tree/main/sdks/hermes-engine/utils) a while ago to have more control over them. However some paths on the CI were not updated. We continued to use old build scripts for Hermes prebuilds. Some unfortunate side effects are: - `HERMES_ENABLE_DEBUGGER` is [hardcoded to true](https://github.com/facebook/hermes/blob/main/utils/build-apple-framework.sh#L65). That makes Hermes much slower in Release configuration. - BUILD_TYPE is [set to Release](https://github.com/facebook/hermes/blob/main/utils/build-apple-framework.sh#L10) instead of `MinSizeRel` which inreases Hermes binary size. This diff copies these build utils from RN to Hermes source directory before we perform Hermes build. Changelog [Internal] Reviewed By: cipolleschi Differential Revision: D44066721 fbshipit-source-id: f45ad6a31fb01c10199f69cc7bbcbbc83b793d34 * Fix TextView alignment being reset on state updates Summary: Changelog: [Android][Fixed] Resolved bug with Text components in new arch losing text alignment state. Reviewed By: mdvacca Differential Revision: D34108943 fbshipit-source-id: 3992e9406345be919b5e3595fc1f9e61cf67a699 # Conflicts: # ReactAndroid/src/main/java/com/facebook/react/views/text/TextAttributeProps.java # ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java * [0.71.7] Bump version numbers * Do not send extra onChangeText even wnen instantianting multiline TextView (facebook#36930) Summary: Pull Request resolved: facebook#36930 This diff fixes facebook#36494 Now this code matches its [Fabric counterpart](facebook@7b48899). There is also one extra check that `_lastStringStateWasUpdatedWith != nil`. With that in place we don't send extra `onChangeText` event when `attributedText` is assigned for the first time on TextView construction. Changelog: [IOS][Fixed] - Do not send extra onChangeText even wnen instantianting multiline TextView Reviewed By: sammy-SC Differential Revision: D45049135 fbshipit-source-id: 62fa281308b9d2e0a807d024f08d8a214bd99b5e * Read Maven group from GROUP property (facebook#37204) Summary: The [React Native TV repo](https://github.com/react-native-tvos/react-native-tvos) shares most of the same Android code as the core repo. Beginning in 0.71, it needs to also publish Android Maven artifacts for the `react-android` and `hermes-android` libraries. In order to avoid conflicts, it needs to publish the artifacts to a different group name. However, `react-native-gradle-plugin` uses a hardcoded group name (`com.facebook.react`). Solution: read the group name from the existing `GROUP` property in `ReactAndroid/gradle.properties`. ## Changelog: [Android] [Fixed] - read GROUP name in gradle-plugin dependency code Pull Request resolved: facebook#37204 Test Plan: - Android unit tests have been added for the new code and new method in `DependencyUtils.kt`. - Existing tests should pass - The new code defaults to the correct group (`com.facebook.react`) so no functional change is expected in the core repo. Reviewed By: luluwu2032 Differential Revision: D45576700 Pulled By: cortinico fbshipit-source-id: 6297ab515b4bdbb17024989c7d3035b0a2ded0ae # Conflicts: # packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactPlugin.kt * bumped packages versions #publish-packages-to-npm * [LOCAL] bump RNGP to 0.71.18 * [LOCAL] update podlock * [0.71.8] Bump version numbers * fix(types): cross platform autoComplete for TextInput (facebook#36931) Summary: Since v0.71 the autoComplete prop on TextInput is available on iOS ([release notes](https://reactnative.dev/blog/2023/01/12/version-071#component-specific-behavior)). However, this change is not reflected in the types. Original types PR here - DefinitelyTyped/DefinitelyTyped#65144 by chwallen ## Changelog: [GENERAL] [FIXED] - Fix autoComplete type for TextInput Pull Request resolved: facebook#36931 Test Plan: Setting the autoComplete prop on TextInput to `nickname`, `organization`, `organization-title`, or `url` should not result in typescript errors. Reviewed By: NickGerleman Differential Revision: D45052350 Pulled By: javache fbshipit-source-id: 40993833b4ed14f91e3bf3521a264ea93517a0c9 * Allow string `transform` style in TypeScript (facebook#37569) Summary: Pull Request resolved: facebook#37569 Fixes facebook#37543 Missed as part of D39423409 (or maybe we didn't have TS types inline yet?) Changelog: [General][Fixed] - Allow string `transform` style in TypeScript Reviewed By: cortinico Differential Revision: D46161450 fbshipit-source-id: 24ee9e19365b7209ec0a2c8fb5a5d7ac78203f4d * fix: [gradle-plugin] 3rd party lib dependency substitution (facebook#37445) Summary: For 3rd party libraries to work with a React Native fork (such as the TV repo) that uses a different Maven group for `react-android` and `hermes-android` artifacts, an additional dependency substitution is required. ## Changelog: [Android][fixed] RNGP dependency substitutions for fork with different Maven group Pull Request resolved: facebook#37445 Test Plan: - Manual tested with an existing project - Unit tests pass Reviewed By: rshest, dmytrorykun Differential Revision: D45948901 Pulled By: cortinico fbshipit-source-id: 4151a1d3616172a92c68812c3a0034c98b330d67 * fix: fix virtualizedList scrollToEnd for 0 items (facebook#36067) Summary: Fixes facebook#36066 ## Changelog [GENERAL] [FIXED] - VirtualizedList scrollToEnd with no data Pull Request resolved: facebook#36067 Test Plan: Run `yarn test VirtualizedList-test` Reviewed By: jacdebug Differential Revision: D43041763 Pulled By: javache fbshipit-source-id: d4d5e871284708a89bf9911d82e9aa97d7625aca * [LOCAL] bump hermes version post release * Make CircleCI caches for hermesc be version dependent (facebook#37452) Summary: Pull Request resolved: facebook#37452 Fixes facebook#37428 We do have cache poisoning for hermesc on Windows and Linux due to reusing the same cache key among different React Native version. This fixes it by specifying a cache key which is version dependent + it invalidates the caches by defining a new key. Changelog: [Internal] [Fixed] - Make CircleCI caches for hermesc be version dependent Reviewed By: cortinico Differential Revision: D45909178 fbshipit-source-id: 830c87ae45739c7053342a68dac2ee7581945c1d * [0.71.9] Bump version numbers * bumped packages versions #publish-packages-to-npm * bump RNGP to 0.71.19 * [0.71.10] Bump version numbers * [LOCAL] update podlock to fix CI * Revert "fix: border width top/bottom not matching the border radius (facebook#34362)" This reverts commit cd6a913. * Fix invalid context cast in ReactRootView (facebook#36121) Summary: Hi 👋 I'm one of the Expo contributors. When upgrading the Stripe dependency in Expo for SDK48 release on Android, we noticed the following error: ```java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity``` With Kudo we narrowed it down to an underlying issue in the following cast in `ReactRootView` done during checking for keyboard events: ```((Activity) getContext())``` The `getContext()` is actually a `ContextThemeWrapper` for `ExperienceActivity`, so we should not cast it to an `Activity` directly - instead, we unwrap it using `getBaseContext()`. Implementing the following fix into the Expo fork fixed the crash for us: expo@0e2c9ca ## Changelog [ANDROID] [FIXED] - Fixed crash occurring in certain native views when handling keyboard events.  Pull Request resolved: facebook#36121 Test Plan: Tested manually by comparing two builds before and after this change. The main branch build crashes when the [Stripe 0.23.1](https://github.com/stripe/stripe-react-native) Card Element from the example app is mounted on screen. Applying the change fixed the issue. Happy to make a more isolated reproduction if necessary. --- Full stack trace: ``` AndroidRuntime D Shutting down VM E FATAL EXCEPTION: main E Process: host.exp.exponent, PID: 8849 E java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:937) E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:913) E at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061) E at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3352) E at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2286) E at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8948) E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231) E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239) E at android.view.Choreographer.doCallbacks(Choreographer.java:899) E at android.view.Choreographer.doFrame(Choreographer.java:832) E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214) E at android.os.Handler.handleCallback(Handler.java:942) E at android.os.Handler.dispatchMessage(Handler.java:99) E at android.os.Looper.loopOnce(Looper.java:201) E at android.os.Looper.loop(Looper.java:288) E at android.app.ActivityThread.main(ActivityThread.java:7898) E at java.lang.reflect.Method.invoke(Native Method) E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936) ``` Reviewed By: cortinico Differential Revision: D43186530 Pulled By: javache fbshipit-source-id: 2143495f6b0c71f342eba6d5abb2bfa4a529fbdd * Prevent crash in runAnimationStep on OnePlus and Oppo devices (facebook#37487) Summary: We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" facebook#35766 with OnePlus/Oppo devices as well, but don't have one on hand to test. This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging. ### Hypothesis of the root cause Based on stacktrace in facebook#35766 (which is the same one we see) Normally, this should happen 1. Choreographer.java constructs a FrameDisplayEventReceiver 2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos` 3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past ### Fix 1. Add logging so we get the parameters to debug more if we end up getting this error 2. In production, just ignore past times instead of throwing an Error ## Changelog: Pick one each for the category and type tags: [ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep Pull Request resolved: facebook#37487 Test Plan: Ran our app using patched version and verified no issues showed up when using it Reviewed By: cipolleschi Differential Revision: D46102968 Pulled By: cortinico fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a * Use `Content-Location` header in bundle response as JS source URL (facebook#37501) Summary: Pull Request resolved: facebook#37501 This is the iOS side of the fix for facebook#36794. That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction). Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](react-native-community/discussions-and-proposals#646) to pass to the JS engine, even where the request URL isn't JSC-safe. We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too). For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment. For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first. Changelog: [iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL Reviewed By: huntie Differential Revision: D45950661 fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d * [LOCAL] Make 0.70 compatible with Xcode 15 (thanks to @AlexanderEggers for the commit in main) * [LOCAL] Bump CLI to 10.2.4 and Metro to 0.73.10 * Add web compat unit tests and fixes (facebook#35316) Summary: Adds compat with W3C logical CSS properties. See facebook#34425 This is a replacement for reverted facebook#34590, which can no longer be imported internally. [General][Added] - Added CSS logical properties. Pull Request resolved: facebook#35316 Test Plan: Unit test snapshots. Reviewed By: NickGerleman Differential Revision: D41230978 Pulled By: necolas fbshipit-source-id: 40e93d0d697f0cb28390480ce2b4bcbce18da70a * resolve some merge conflicts * fix tests * [0.71.11] Bump version numbers * [LOCAL] update podlock for CI * fix(ios): fix `pod install --project-directory=ios` failing (facebook#37993) * Prevent LogBox from crashing on long messages (facebook#38005) Summary: Pull Request resolved: facebook#38005 Fixes facebook#32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.) Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages Reviewed By: GijsWeterings Differential Revision: D46892454 fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd # Conflicts: # Libraries/LogBox/Data/parseLogBoxLog.js # packages/react-native/package.json * [0.71.12] Bump version numbers --------- Co-authored-by: Lorenzo Sciandra <[email protected]> Co-authored-by: Nick Gerleman <[email protected]> Co-authored-by: Lorenzo Sciandra <[email protected]> Co-authored-by: Dmitry Rykun <[email protected]> Co-authored-by: Pieter De Baets <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Douglas Lowder <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Kyle Roach <[email protected]> Co-authored-by: Julien Brayere <[email protected]> Co-authored-by: Riccardo Cipolleschi <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: aleqsio <[email protected]> Co-authored-by: Harry Yu <[email protected]> Co-authored-by: Rob Hogan <[email protected]> Co-authored-by: Nicolas Gallagher <[email protected]> Co-authored-by: Alexander Eggers <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Tommy Nguyen <[email protected]> Co-authored-by: Moti Zilberman <[email protected]> Co-authored-by: Distiller <[email protected]>

@AlexanderEggers

* [LOCAL] update podlock post release to fix CI * Fix measurement of uncontrolled TextInput after edit Summary: D42721684 (facebook@be69c8b) 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 * Minimize EditText Spans 1/9: Fix precedence (facebook#36543) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 2/9: Make stripAttributeEquivalentSpans generic (facebook#36546) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 3/9: ReactBackgroundColorSpan (facebook#36547) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 4/9: ReactForegroundColorSpan (facebook#36545) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 5/9: Strikethrough and Underline (facebook#36544) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 6/9: letterSpacing (facebook#36548) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 7/9: Avoid temp list (facebook#36576) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Minimize EditText Spans 8/9: CustomStyleSpan (facebook#36577) Summary: Pull Request resolved: facebook#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]( facebook#35936 (comment)) 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 * Mimimize EditText Spans 9/9: Remove addSpansForMeasurement() (facebook#36575) Summary: Pull Request resolved: facebook#36575 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]( facebook#35936 (comment)) for greater context on the platform behavior. D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all. We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding. Changelog: [Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()` Reviewed By: javache Differential Revision: D44298159 fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002 # Conflicts: # ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java * Use RN Build Utils for Building Hermes Artifacts Summary: We moved Hermes some build utils from [Hermes repo](https://github.com/facebook/hermes/tree/main/utils) to [React Navtie repo](https://github.com/facebook/react-native/tree/main/sdks/hermes-engine/utils) a while ago to have more control over them. However some paths on the CI were not updated. We continued to use old build scripts for Hermes prebuilds. Some unfortunate side effects are: - `HERMES_ENABLE_DEBUGGER` is [hardcoded to true](https://github.com/facebook/hermes/blob/main/utils/build-apple-framework.sh#L65). That makes Hermes much slower in Release configuration. - BUILD_TYPE is [set to Release](https://github.com/facebook/hermes/blob/main/utils/build-apple-framework.sh#L10) instead of `MinSizeRel` which inreases Hermes binary size. This diff copies these build utils from RN to Hermes source directory before we perform Hermes build. Changelog [Internal] Reviewed By: cipolleschi Differential Revision: D44066721 fbshipit-source-id: f45ad6a31fb01c10199f69cc7bbcbbc83b793d34 * Fix TextView alignment being reset on state updates Summary: Changelog: [Android][Fixed] Resolved bug with Text components in new arch losing text alignment state. Reviewed By: mdvacca Differential Revision: D34108943 fbshipit-source-id: 3992e9406345be919b5e3595fc1f9e61cf67a699 # Conflicts: # ReactAndroid/src/main/java/com/facebook/react/views/text/TextAttributeProps.java # ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java * [0.71.7] Bump version numbers * Do not send extra onChangeText even wnen instantianting multiline TextView (facebook#36930) Summary: Pull Request resolved: facebook#36930 This diff fixes facebook#36494 Now this code matches its [Fabric counterpart](facebook@7b48899). There is also one extra check that `_lastStringStateWasUpdatedWith != nil`. With that in place we don't send extra `onChangeText` event when `attributedText` is assigned for the first time on TextView construction. Changelog: [IOS][Fixed] - Do not send extra onChangeText even wnen instantianting multiline TextView Reviewed By: sammy-SC Differential Revision: D45049135 fbshipit-source-id: 62fa281308b9d2e0a807d024f08d8a214bd99b5e * Read Maven group from GROUP property (facebook#37204) Summary: The [React Native TV repo](https://github.com/react-native-tvos/react-native-tvos) shares most of the same Android code as the core repo. Beginning in 0.71, it needs to also publish Android Maven artifacts for the `react-android` and `hermes-android` libraries. In order to avoid conflicts, it needs to publish the artifacts to a different group name. However, `react-native-gradle-plugin` uses a hardcoded group name (`com.facebook.react`). Solution: read the group name from the existing `GROUP` property in `ReactAndroid/gradle.properties`. ## Changelog: [Android] [Fixed] - read GROUP name in gradle-plugin dependency code Pull Request resolved: facebook#37204 Test Plan: - Android unit tests have been added for the new code and new method in `DependencyUtils.kt`. - Existing tests should pass - The new code defaults to the correct group (`com.facebook.react`) so no functional change is expected in the core repo. Reviewed By: luluwu2032 Differential Revision: D45576700 Pulled By: cortinico fbshipit-source-id: 6297ab515b4bdbb17024989c7d3035b0a2ded0ae # Conflicts: # packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactPlugin.kt * bumped packages versions #publish-packages-to-npm * [LOCAL] bump RNGP to 0.71.18 * [LOCAL] update podlock * [0.71.8] Bump version numbers * fix(types): cross platform autoComplete for TextInput (facebook#36931) Summary: Since v0.71 the autoComplete prop on TextInput is available on iOS ([release notes](https://reactnative.dev/blog/2023/01/12/version-071#component-specific-behavior)). However, this change is not reflected in the types. Original types PR here - DefinitelyTyped/DefinitelyTyped#65144 by chwallen ## Changelog: [GENERAL] [FIXED] - Fix autoComplete type for TextInput Pull Request resolved: facebook#36931 Test Plan: Setting the autoComplete prop on TextInput to `nickname`, `organization`, `organization-title`, or `url` should not result in typescript errors. Reviewed By: NickGerleman Differential Revision: D45052350 Pulled By: javache fbshipit-source-id: 40993833b4ed14f91e3bf3521a264ea93517a0c9 * Allow string `transform` style in TypeScript (facebook#37569) Summary: Pull Request resolved: facebook#37569 Fixes facebook#37543 Missed as part of D39423409 (or maybe we didn't have TS types inline yet?) Changelog: [General][Fixed] - Allow string `transform` style in TypeScript Reviewed By: cortinico Differential Revision: D46161450 fbshipit-source-id: 24ee9e19365b7209ec0a2c8fb5a5d7ac78203f4d * fix: [gradle-plugin] 3rd party lib dependency substitution (facebook#37445) Summary: For 3rd party libraries to work with a React Native fork (such as the TV repo) that uses a different Maven group for `react-android` and `hermes-android` artifacts, an additional dependency substitution is required. ## Changelog: [Android][fixed] RNGP dependency substitutions for fork with different Maven group Pull Request resolved: facebook#37445 Test Plan: - Manual tested with an existing project - Unit tests pass Reviewed By: rshest, dmytrorykun Differential Revision: D45948901 Pulled By: cortinico fbshipit-source-id: 4151a1d3616172a92c68812c3a0034c98b330d67 * fix: fix virtualizedList scrollToEnd for 0 items (facebook#36067) Summary: Fixes facebook#36066 ## Changelog [GENERAL] [FIXED] - VirtualizedList scrollToEnd with no data Pull Request resolved: facebook#36067 Test Plan: Run `yarn test VirtualizedList-test` Reviewed By: jacdebug Differential Revision: D43041763 Pulled By: javache fbshipit-source-id: d4d5e871284708a89bf9911d82e9aa97d7625aca * [LOCAL] bump hermes version post release * Make CircleCI caches for hermesc be version dependent (facebook#37452) Summary: Pull Request resolved: facebook#37452 Fixes facebook#37428 We do have cache poisoning for hermesc on Windows and Linux due to reusing the same cache key among different React Native version. This fixes it by specifying a cache key which is version dependent + it invalidates the caches by defining a new key. Changelog: [Internal] [Fixed] - Make CircleCI caches for hermesc be version dependent Reviewed By: cortinico Differential Revision: D45909178 fbshipit-source-id: 830c87ae45739c7053342a68dac2ee7581945c1d * [0.71.9] Bump version numbers * bumped packages versions #publish-packages-to-npm * bump RNGP to 0.71.19 * [0.71.10] Bump version numbers * [LOCAL] update podlock to fix CI * Revert "fix: border width top/bottom not matching the border radius (facebook#34362)" This reverts commit cd6a913. * Fix invalid context cast in ReactRootView (facebook#36121) Summary: Hi 👋 I'm one of the Expo contributors. When upgrading the Stripe dependency in Expo for SDK48 release on Android, we noticed the following error: ```java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity``` With Kudo we narrowed it down to an underlying issue in the following cast in `ReactRootView` done during checking for keyboard events: ```((Activity) getContext())``` The `getContext()` is actually a `ContextThemeWrapper` for `ExperienceActivity`, so we should not cast it to an `Activity` directly - instead, we unwrap it using `getBaseContext()`. Implementing the following fix into the Expo fork fixed the crash for us: expo@0e2c9ca ## Changelog [ANDROID] [FIXED] - Fixed crash occurring in certain native views when handling keyboard events.  Pull Request resolved: facebook#36121 Test Plan: Tested manually by comparing two builds before and after this change. The main branch build crashes when the [Stripe 0.23.1](https://github.com/stripe/stripe-react-native) Card Element from the example app is mounted on screen. Applying the change fixed the issue. Happy to make a more isolated reproduction if necessary. --- Full stack trace: ``` AndroidRuntime D Shutting down VM E FATAL EXCEPTION: main E Process: host.exp.exponent, PID: 8849 E java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:937) E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:913) E at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061) E at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3352) E at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2286) E at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8948) E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231) E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239) E at android.view.Choreographer.doCallbacks(Choreographer.java:899) E at android.view.Choreographer.doFrame(Choreographer.java:832) E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214) E at android.os.Handler.handleCallback(Handler.java:942) E at android.os.Handler.dispatchMessage(Handler.java:99) E at android.os.Looper.loopOnce(Looper.java:201) E at android.os.Looper.loop(Looper.java:288) E at android.app.ActivityThread.main(ActivityThread.java:7898) E at java.lang.reflect.Method.invoke(Native Method) E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936) ``` Reviewed By: cortinico Differential Revision: D43186530 Pulled By: javache fbshipit-source-id: 2143495f6b0c71f342eba6d5abb2bfa4a529fbdd * Prevent crash in runAnimationStep on OnePlus and Oppo devices (facebook#37487) Summary: We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" facebook#35766 with OnePlus/Oppo devices as well, but don't have one on hand to test. This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging. ### Hypothesis of the root cause Based on stacktrace in facebook#35766 (which is the same one we see) Normally, this should happen 1. Choreographer.java constructs a FrameDisplayEventReceiver 2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos` 3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past ### Fix 1. Add logging so we get the parameters to debug more if we end up getting this error 2. In production, just ignore past times instead of throwing an Error ## Changelog: Pick one each for the category and type tags: [ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep Pull Request resolved: facebook#37487 Test Plan: Ran our app using patched version and verified no issues showed up when using it Reviewed By: cipolleschi Differential Revision: D46102968 Pulled By: cortinico fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a * Use `Content-Location` header in bundle response as JS source URL (facebook#37501) Summary: Pull Request resolved: facebook#37501 This is the iOS side of the fix for facebook#36794. That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction). Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](react-native-community/discussions-and-proposals#646) to pass to the JS engine, even where the request URL isn't JSC-safe. We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too). For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment. For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first. Changelog: [iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL Reviewed By: huntie Differential Revision: D45950661 fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d * [LOCAL] Make 0.70 compatible with Xcode 15 (thanks to @AlexanderEggers for the commit in main) * [LOCAL] Bump CLI to 10.2.4 and Metro to 0.73.10 * Add web compat unit tests and fixes (facebook#35316) Summary: Adds compat with W3C logical CSS properties. See facebook#34425 This is a replacement for reverted facebook#34590, which can no longer be imported internally. [General][Added] - Added CSS logical properties. Pull Request resolved: facebook#35316 Test Plan: Unit test snapshots. Reviewed By: NickGerleman Differential Revision: D41230978 Pulled By: necolas fbshipit-source-id: 40e93d0d697f0cb28390480ce2b4bcbce18da70a * resolve some merge conflicts * fix tests * [0.71.11] Bump version numbers * [LOCAL] update podlock for CI * fix(ios): fix `pod install --project-directory=ios` failing (facebook#37993) * Prevent LogBox from crashing on long messages (facebook#38005) Summary: Pull Request resolved: facebook#38005 Fixes facebook#32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.) Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages Reviewed By: GijsWeterings Differential Revision: D46892454 fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd # Conflicts: # Libraries/LogBox/Data/parseLogBoxLog.js # packages/react-native/package.json * [0.71.12] Bump version numbers * [LOCAL] Bump podfile.lock * [LOCAL] Download artifacts from CI to speed up testing (facebook#37971) (facebook#38612) Co-authored-by: Riccardo Cipolleschi <[email protected]> resolved: facebook#37971 * fix: mount devtools overlay only if react devtools are connected (facebook#38784) * Allow RCTBundleURLProvider to request an inline source map (facebook#37878) (facebook#38995) Summary: See: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html When using direct debugging with JavaScriptCore, Safari Web Inspector doesn't pick up the source map over the network. Instead, as far as I can tell, it expects you to pass the source URL at the time you load your bundle: https://developer.apple.com/documentation/javascriptcore/jscontext/1451384-evaluatescript?language=objc . This leads to a very sub-par developer experience debugging the JSbundle directly. It will however, pick up an inline source map. Therefore, let's add a way to have React Native tell metro to request an inline source map. I did this by modifying `RCTBundleURLProvider` to have a new query parameter for `inlineSourceMap`, and set to true by default for JSC. [IOS] [ADDED] - Added support to inline the source map via RCTBundleURLProvider Pull Request resolved: facebook#37878 Test Plan: I can put a breakpoint in RNTester, via Safari Web Inspector, in human readable code :D <img width="1728" alt="Screenshot 2023-06-14 at 4 09 03 AM" src="https://github.com/facebook/react-native/assets/6722175/055277fa-d887-4566-9dc6-3ea07a1a60b0"> Reviewed By: motiz88 Differential Revision: D46855418 Pulled By: huntie fbshipit-source-id: 2134cdbcd0a3e81052d26ed75f83601ae4ddecfe * chore(releases): improve bump oss script to allow less human errors (facebook#38666) (facebook#38890) Summary: One of the limitations of the existing flow for the release crew is that they need to manually remember to publish all the other packages in the monorepo ahead of a new patch release - this PR modifies the logic for the bump-oss-version script (and makes it available via yarn) so that it will not run if: * there are git changes lying around * if some of the packages need a new release it required a bit of refactoring to extract some portions of the logic from the bump-all-package-versions script, but I think the end result is pretty decent. ## Changelog:  [INTERNAL] [CHANGED] - improve bump oss script to allow less human errors Pull Request resolved: facebook#38666 Test Plan: * checkout this branch * comment L54 of bump-oss-version.js (to remove the check on the branch name) * run `yarn bump-all-updated-packages`, verify that it works and that it detects that some packages have unreleased code * run `yarn bump-oss-version -t asd -v asd` (the "fake" parameters are needed to pass the yargs check), verify that it will throw an error because it finds a package that has unreleased code Reviewed By: mdvacca Differential Revision: D48156963 Pulled By: cortinico fbshipit-source-id: 2473ad5a84578c5236c905fd9aa9a88113fe8d22 # Conflicts: # scripts/publish-npm.js re-add the file nit # Conflicts: # package.json * Add scripts and pipeline to poll for maven (facebook#38980) (facebook#39039) * Fix onChangeText not firing when clearing the value of TextInput with multiline=true on iOS (facebook#37958) Summary: This fix fixes the TextInput issue in facebook#37784 with onChangeText not working on iOS only. ## Changelog:  [IOS] [FIXED] - Fix onChangeText not firing when clearing the value of TextInput with multiline=true on iOS Pull Request resolved: facebook#37958 Test Plan: 1. Run the repro code given in the issue (facebook#37784). 2. Verified that onChangeText works after pressing the submit button. 3. Run the repro code from the issue (facebook#36494) that caused this issue. 4. Verified that issue (facebook#36494) is not reoccurring. Reviewed By: rshest Differential Revision: D47185775 Pulled By: dmytrorykun fbshipit-source-id: 1a1a6534d6bf8b5bb8cf1090734dd894bab43f82 * For targeting SDK 34 - Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase (facebook#38256) Summary: Pull Request resolved: facebook#38256 Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details. Without this fix, app crashes during launch because of : ```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts``` Changelog: [Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase Reviewed By: javache Differential Revision: D47313501 fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698 * [LOCAL] skip un-semver packages in 71 branch * Revert "[LOCAL] skip un-semver packages in 71 branch" This reverts commit a90485a. * [LOCAL] augment forEachPackage to accept optional excludes and add for the bump and trigger release script * [0.71.13] Bump version numbers * Re-enable direct debugging with JSC on iOS 16.4+ (facebook#37914) Summary: Pull Request resolved: facebook#37914 Restores facebook#37874 (reverted earlier today), with fix for `JSCRuntime.cpp` build on Android. Changelog: None Reviewed By: cortinico Differential Revision: D46762984 fbshipit-source-id: 6d56f81b9d0c928887860993b2b729ed96c0734c * Guard `JSGlobalContextSetInspectable` behind a compile time check for Xcode 14.3+ (facebook#39037) Summary: An earlier [change](facebook@8b1bf05) I made (that huntie resubmitted) only works on Xcode 14.3+ (See more info [here](react-native-community/discussions-and-proposals#687)). This change adds the appropriate compiler checks so that the change is compatible with Xcode 14.2 and earlier, and therefore cherry-pickable to 0.71 and 0.72. The check works by checking if iOS 16.4+ is defined, which is the closest proxy I could find for "Is this Xcode 14.3". ## Changelog: [IOS] [CHANGED] - Guard `JSGlobalContextSetInspectable` behind a compile time check for Xcode 14.3+ Pull Request resolved: facebook#39037 Test Plan: I can't actually test on Xcode 14.2 (it won't launch on my MacBook 😢), but I made a similar [PR](#1848) in React Native macOS, whose CI checks run against Xcode 14.2 and I'm getting passing checks there. Reviewed By: huntie Differential Revision: D48414196 Pulled By: NickGerleman fbshipit-source-id: ba10a6505dd11d982cc56c02bf9f7dcdc104bbec * Fix some issues --------- Co-authored-by: Lorenzo Sciandra <[email protected]> Co-authored-by: Nick Gerleman <[email protected]> Co-authored-by: Lorenzo Sciandra <[email protected]> Co-authored-by: Dmitry Rykun <[email protected]> Co-authored-by: Pieter De Baets <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Douglas Lowder <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Kyle Roach <[email protected]> Co-authored-by: Julien Brayere <[email protected]> Co-authored-by: Riccardo Cipolleschi <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: aleqsio <[email protected]> Co-authored-by: Harry Yu <[email protected]> Co-authored-by: Rob Hogan <[email protected]> Co-authored-by: Nicolas Gallagher <[email protected]> Co-authored-by: Alexander Eggers <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Tommy Nguyen <[email protected]> Co-authored-by: Moti Zilberman <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Riccardo Cipolleschi <[email protected]> Co-authored-by: Riccardo Cipolleschi <[email protected]> Co-authored-by: Ruslan Lesiutin <[email protected]> Co-authored-by: Koichi Nagaoka <[email protected]> Co-authored-by: Kun Wang <[email protected]> Co-authored-by: Distiller <[email protected]> Co-authored-by: Alex Hunt <[email protected]>

danieltaub · 2023-10-01T12:04:48Z

We are using RN 0.71.8 together with expo 48.0 and the issue is still happens to all of our Samsung users for some reason, any ideas?

chengweibo · 2024-01-08T09:26:32Z

NEW UPDATE: we have now released patch releases containing the second wave of fix for:

https://github.com/facebook/react-native/releases/tag/v0.69.10

https://github.com/facebook/react-native/releases/tag/v0.70.9

https://github.com/facebook/react-native/releases/tag/v0.71.7

https://github.com/facebook/react-native/releases/tag/v0.68.7

UPDATE: we have now released a patch release containing the first mitigation for all the supported versions of React Native plus 0.68 (since it's still used by a significant number of users):

https://github.com/facebook/react-native/releases/tag/v0.68.6

https://github.com/facebook/react-native/releases/tag/v0.69.8

https://github.com/facebook/react-native/releases/tag/v0.70.7

https://github.com/facebook/react-native/releases/tag/v0.71.2

Please upgrade to those versions and report back here if it helps! We are still planning to do further investigation, but don't expect any new releases concerning this topic for at least a couple weeks (unless something unexpected happens).

There have been repeated and persistent signals of ANRs (hangs) when typing into a multiline TextInput on Samsung phones. This is most reported by using the out-of-the-box keyboard provided by Samsung One UI 5. We have been able to locally reproduce the hangs on two separate Galaxy S22 devices. Most devices will not be as fast as the ones we have tested on.

Impact

The issue presents as repeated hangs or ANRs when typing into a TextInput which has a large amount of text. It is specific to the Samsung soft keyboard, and does not reproduce when using other keyboards like GBoard on the same device. There are a different set of TextInputs where we have confirmed impact depending on whether Fabric is enabled or disabled.

Fabric enabled

Both controlled and uncontrolled TextInputs are impacted.

Fabric disabled

Controlled TextInputs and uncontrolled TextInputs which set an initial value via child are impacted.

Root causing

Root causing the issue focused on:

Locally profiling the hang under different scenarios

Examining which span differences create the hang

Reproducing the issue outside of React Native

Profiling

We saw similar results to the trace already shared in #35590. A Java sampling profiler shows the process com.samsung.android.honeyboard has a very long running frame, delivering input.

This triggers code on the main thread, in the app process, where we see a hang happen while committing a text change from the IME to the underlying Spannable backing the EditText. The hang happens in an event handler which has subscribed to changes to the underlying text. The long-running work seems to be laying out the text.

Because the hang happens in response to an edit to the underlying Spannable, investigation focused on the Spannable content differences in scenarios which created ANRs vs not.

Spannable differences between hang/no hang

We examined typing into the below example, which may hang on Fabric but not Paper:
<TextInput multiline={true} />
Grammarly annotations were present as SuggestionSpan spans on both platforms. On Fabric but not paper there was the presence of AbsoluteSizeSpan spans, which set the font size within the text. This is akin to setting <span style=”font-size: 12px”}>Text</span> within a browser.

When we stubbed out platform code in React Native which set an AbsoluteSizeSpan, that example along with another previously hanging example would no longer hang. The hang was possible to trigger in an uncontrolled TextInput with a short string like “Text Here” as a child, so we attempted to repro the logical extreme, where we add a single span setting font size to the TextInput.

Reproducing outside of React Native

We discovered that adding even a single inclusive span (specifically setting font size) is enough to create hangs. This can reproduced by:

Adding an EditText with an inputType of textMultiLine.

Adding an inclusive span setting font size: E.g. str.setSpan(new AbsoluteSizeSpan(55), 0, string.length(), Spanned.SPAN_INCLUSIVE_INCLUSIVE)

Pasting a large amount of text then starting to type.

We were able to create a repro for this on top of a template Android application. The issue only happens when using the Samsung keyboard.

reproducervideo.mp4
Grammarly annotations are not shown locally when changing the appId and namespace of the repro to com.facebook.katana (the ID of the Facebook app). This implies the Facebook app may be being special-cased, contributing to the lack of internal signal on the issue. This only happened on 1/2 devices, so it's possible there might be some setting or association that wasn't fresh.

Remediation

While the underlying issue seems to be outside of React Native, the issue still has a real-world effect on our users. We are starting the process to mitigate the issue by working to notify Samsung. This issue has already shown signs of impacting the Android app ecosystem outside of React Native and the ability to set spans with formatting like font size is a fundamentally important part of the platform.

We hope this issue will be addressed in a future update from Samsung, but this does not address the already-present impact of the issue. A potential mitigation which we are exploring is whether React Native could avoid adding AbsoluteSizeSpan (or formatting spans in general) in more common cases.

There have been previously discovered workarounds for the issue, such as setting keyboardType to visible-password. We recommend against preemptively using these workarounds, due to impact on UX and accessibility.

Sumsung Galaxy A71 , Sumsung Galaxy A32, Sumsung Galaxy A53 phone the following crash occurs , hope to give me solution，thanks
Fatal Exception: java.lang.IndexOutOfBoundsException: offset(1) should be less than line limit(0)
at android.text.TextLine.measure(TextLine.java:389)
at android.text.Layout.getHorizontal(Layout.java:1254)
at android.text.Layout.getHorizontal(Layout.java:1230)
at android.text.Layout.getPrimaryHorizontal(Layout.java:1200)
at android.widget.TextView.bringPointIntoView(TextView.java:11046)
at android.widget.TextView.updateAfterEdit(TextView.java:11983)
at android.widget.Editor.finishBatchEdit(Editor.java:2086)
at android.widget.Editor.endBatchEdit(Editor.java:2068)
at android.widget.TextView.endBatchEdit(TextView.java:9931)
at android.widget.TextView.doKeyDown(TextView.java:9505)
at android.widget.TextView.onKeyDown(TextView.java:9275)
at android.view.KeyEvent.dispatch(KeyEvent.java:3508)
at android.view.View.dispatchKeyEvent(View.java:15395)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.widget.ScrollView.dispatchKeyEvent(ScrollView.java:738)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at com.facebook.react.ReactRootView.dispatchKeyEvent(ReactRootView.java:234)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1978)
at com.android.internal.policy.DecorView.superDispatchKeyEvent(DecorView.java:1100)
at com.android.internal.policy.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1961)
at android.app.Activity.dispatchKeyEvent(Activity.java:4342)
at androidx.core.app.ComponentActivity.superDispatchKeyEvent(ComponentActivity.java:122)
at androidx.core.view.KeyEventDispatcher.dispatchKeyEvent(KeyEventDispatcher.java:84)
at androidx.core.app.ComponentActivity.dispatchKeyEvent(ComponentActivity.java:140)
at com.android.internal.policy.DecorView.dispatchKeyEvent(DecorView.java:924)
at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:8056)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:7864)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7213)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7270)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7236)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7434)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7244)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:7491)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7217)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7270)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7236)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7244)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7217)
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:10788)
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:10676)
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:10632)
at android.view.ViewRootImpl$ViewRootHandler.handleMessageImpl(ViewRootImpl.java:6822)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:6697)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8757)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

Summary: Pull Request resolved: facebook/react-native#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]( facebook/react-native#35936 (comment)) 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: d4d57e3f73ee57c1efe4f90558f3ad081469855b

NickGerleman mentioned this issue Jan 23, 2023

TextInput hangs with Samsung keyboard's Grammarly integration #35590

Closed

kelset added the Platform: Android Android applications. label Jan 24, 2023

cortinico added the RN Team label Jan 24, 2023

kelset added Component: TextInput Related to the TextInput component. API: Keyboard labels Jan 24, 2023

kelset pinned this issue Jan 24, 2023

This comment was marked as off-topic.

Sign in to view

This comment was marked as duplicate.

Sign in to view

NickGerleman mentioned this issue Jan 25, 2023

Mitigation for Samsung TextInput Hangs #35967

Closed

This comment was marked as off-topic.

Sign in to view

enahum mentioned this issue Jan 27, 2023

Android v2 app issues mattermost/mattermost-mobile#7030

Open

This was referenced Mar 11, 2024

fix(deps): update dependency react-native to v0.76.1 renli-tech/hamburger#59

Open

fix(deps): update dependency react-native to v0.76.1 renli-tech/hamburger-example#10

Open

mend-for-github-com bot mentioned this issue Mar 12, 2024

[NEUTRAL] Update dependency react-native to ^0.76.0 Uncleken13/react-native-video#18

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Investigation] ANRs Using Multiline TextInput on Samsung Devices #35936

[Investigation] ANRs Using Multiline TextInput on Samsung Devices #35936

NickGerleman commented Jan 23, 2023 •

edited by kelset

Loading

jefflewis commented Jan 24, 2023

econner commented Jan 24, 2023

This comment was marked as off-topic.

NickGerleman commented Jan 24, 2023 •

edited

Loading

This comment was marked as off-topic.

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

NickGerleman commented Jan 25, 2023 •

edited

Loading

dozoisch commented Jan 25, 2023

This comment was marked as off-topic.

NickGerleman commented Jan 26, 2023 •

edited

Loading

dozoisch commented Jan 26, 2023

cortinico commented Jan 27, 2023

rikur commented Jan 29, 2023 •

edited

Loading

NickGerleman commented Jan 30, 2023

danieltaub commented Oct 1, 2023

chengweibo commented Jan 8, 2024

Impact

Fabric enabled

Fabric disabled

Root causing

Profiling

Spannable differences between hang/no hang

Reproducing outside of React Native

Remediation

[Investigation] ANRs Using Multiline TextInput on Samsung Devices #35936

[Investigation] ANRs Using Multiline TextInput on Samsung Devices #35936

Comments

NickGerleman commented Jan 23, 2023 • edited by kelset Loading

Impact

Fabric enabled

Fabric disabled

Root causing

Profiling

Spannable differences between hang/no hang

Reproducing outside of React Native

Remediation

jefflewis commented Jan 24, 2023

econner commented Jan 24, 2023

This comment was marked as off-topic.

NickGerleman commented Jan 24, 2023 • edited Loading

This comment was marked as off-topic.

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

NickGerleman commented Jan 25, 2023 • edited Loading

dozoisch commented Jan 25, 2023

This comment was marked as off-topic.

NickGerleman commented Jan 26, 2023 • edited Loading

dozoisch commented Jan 26, 2023

cortinico commented Jan 27, 2023

How to test it on a new project.

How to test it on an existing project.

Next steps

rikur commented Jan 29, 2023 • edited Loading

NickGerleman commented Jan 30, 2023

danieltaub commented Oct 1, 2023

chengweibo commented Jan 8, 2024

Impact

Fabric enabled

Fabric disabled

Root causing

Profiling

Spannable differences between hang/no hang

Reproducing outside of React Native

Remediation

NickGerleman commented Jan 23, 2023 •

edited by kelset

Loading

NickGerleman commented Jan 24, 2023 •

edited

Loading

NickGerleman commented Jan 25, 2023 •

edited

Loading

NickGerleman commented Jan 26, 2023 •

edited

Loading

rikur commented Jan 29, 2023 •

edited

Loading