Changelog: [Internal]

… name (#48174)

Summary:
Fixes an [issue](#48168) where only iOS configurations with "Debug" in the name are configured to use the hermes debugger.

## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->

[IOS] [FIXED] - Enable hermes debugger by configuration type instead of configuration name

Pull Request resolved: #48174

Test Plan:
Added new test scenarios that all pass:
```
ruby -Itest packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
Loaded suite packages/react-native/scripts/cocoapods/__tests__/utils-test
Started
Finished in 0.336047 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 tests, 149 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
166.64 tests/s, 443.39 assertions/s
```

In a personal project with the following configurations:
```
project 'ReactNativeProject', {
    'Local' => :debug,
    'Development' => :release,
    'Staging' => :release,
    'Production' => :release,
  }
```
I added the following to my Podfile:
```
installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
        puts "#{config.name} is debug? #{config.type == :debug}"
    end
end
```
To confirm that my logic is correct:
```
Local is debug? true
Development is debug? false
Staging is debug? false
Production is debug? false
```

Reviewed By: robhogan

Differential Revision: D66962860

Pulled By: cipolleschi

fbshipit-source-id: 7bd920e123c9064c8a1b5d45df546ff5d2a7d8be

Summary:
Pull Request resolved: #48026

This should mitigate this particular issue we're seeing on Windows:
- #46210

Changelog:
[Android] [Changed] - Gradle to 8.11.1

Reviewed By: javache

Differential Revision: D66600321

fbshipit-source-id: d58437485222e189d90bcf4d6b41ca956449ed22

Summary:
Pull Request resolved: #48225

Fixes #47762

The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a Mac Catalyst build. We can resolve this by not putting the event emitters in the attributed string, but this is likely to cause other issues with event handling for nested <Text> components.

## Changelog

[iOS][Fixed] - Workaround for Mac Catalyst TextInput crash due to serialization attempt of WeakEventEmitter

Reviewed By: NickGerleman

Differential Revision: D66664583

fbshipit-source-id: efdfbcb0db4d5e6b9bf7c14f9bbb221faae2d724

Summary:
Pull Request resolved: #48329

With the call to `removeView()` removed from `ReactViewClippingManager` in #47634, we're seeing views erroneously sticking around in the layout.

While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501):
```
public void removeView(View view) {
  if (removeViewInternal(view)) {
--> requestLayout();
--> invalidate(true);
  }
}
```
To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout.

Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt()

Reviewed By: javache

Differential Revision: D67398971

fbshipit-source-id: b100db468cc3be6ddc6edd6c6d078a8a0b59a2c1

Summary:
Pull Request resolved: #46629

If we clipped and had no border or corner radius we would end up hitting this path every time. We can optimize this a bit to avoid that.

Changelog: [Internal]

Reviewed By: NickGerleman

Differential Revision: D63299597

fbshipit-source-id: 90031f964b7669049a4a2efe00a553c888d28cd7

Summary:
#47379 removed local cpp sources from the sources being built with the app. This resulted in a local `android/app/src/main/jni/OnLoad.cpp` file being ignored at build time. I have therefore added logic to the cmake file to prioritise local `cpp` files and fallback to `${REACT_ANDROID_DIR}/cmake-utils/default-app-setup/*.cpp` if none exist.

This resolves #48298

[ANDROID] [FIXED] - Prioritise local OnLoad.cpp, falling back to default-app-setup

Pull Request resolved: #48340

Test Plan:
- Followed the https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules guide (which was broken > 0.76.1)
- Applied the patch to the reproduction repository linked to #47352 to ensure no regression

Reviewed By: cipolleschi

Differential Revision: D67736012

Pulled By: cortinico

fbshipit-source-id: 87f6b8edf1613682585a94e1d1b3e6b4b792e4f5

Summary:
Fixes #47563

It seems like a regression from #45401, where it was aimed to fix `onChangeText` being called multiple times when changing the text programmatically in an input with the `multiline` prop set as true.

This PR reverts that partially, as the `maxLength` check is not being evaluated correctly before setting the text. Not reverting it completely as when removing the second part of the fix, the `onChangeText` gets called multiple times again.

## Changelog:

[IOS] [FIXED] - Fixing TextInput `maxLength` not working in old arch

Pull Request resolved: #48126

Test Plan:
The issue could be reproduced in the rn-tester. See my videos with the before and after the fix.

<details>
<summary>Before:</summary>

https://github.com/user-attachments/assets/86fd67eb-fc14-469a-a5f8-8e83b49f857c

</details>

<details>
<summary>After:</summary>

https://github.com/user-attachments/assets/368383b1-c1bd-4e0b-ac44-c78022462fa0

</details>

Reviewed By: cortinico

Differential Revision: D67025182

Pulled By: cipolleschi

fbshipit-source-id: 720c400eef362618106ae434aef421c7529214fe

…ountOnAndroid

Summary:
Pull Request resolved: #48525

Fixes #48249

`TextMeasureCacheKey` hash and equality functions only incorporates the maximum width constraint. I'm guessing this was an attempt at an optimization, but it can lead to incorrect results in pretty trivial cases. E.g. if Yoga knows a definite size of `Text` in one dimension,  and measures via `YGMeasureModeExactly`, we can have a minimum size corresponding specific to the style in which the text was laid out.

Changelog:
[General][Fixed] - Fix TextMeasureCacheKey Throwing Out Some LayoutConstraints

Reviewed By: christophpurrer

Differential Revision: D67922414

fbshipit-source-id: 0ee0220059fc4e4645b1684c42a0587fe728bedd

#publish-packages-to-npm&latest