Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47547
In [#47176](https://github.com/facebook/react-native/pull/47176) we disabled the generation of the component registration for app specific components as it was creating a circular dependency between the app and React Native.
However, we made a couple of typos that make it not work as expected and users picked up those typos soon.
This change fixes them for good.
## Changelog
[iOS][Fixed] - Properly stop generating component registration for components defined in app.
Reviewed By: blakef
Differential Revision: D65750433
fbshipit-source-id: 1a879c5be014905558b9fd05e6f16ac36b784ed6
Summary:
Fixes https://github.com/facebook/react-native/issues/47352
This fixes a bug when the user is providing its own CMakeLists.txt file say because they want to compile more C++ code than we actually provide.
Previously the `*.cpp` will evalute file in the current directory, meaning that the app's default `OnLoad.cpp` file would be ignored.
## Changelog:
[ANDROID] [FIXED] - Use absolute path when compiling appmodules.so sources
Pull Request resolved: https://github.com/facebook/react-native/pull/47379
Test Plan:
Tested against the reproducer provided in:
- Use absolute path when compiling appmodules.so sources
Reviewed By: cipolleschi
Differential Revision: D65428676
Pulled By: cortinico
fbshipit-source-id: 7f3e4d470da0fffc5191c1a2c7e8fec517fee496
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47339
Fixing issue raised in https://github.com/facebook/react-native/issues/47307
This is a follow up from D62286026.
It appears there was a line that went missing while trying to refactor the code.
`fitsSystemWindows = true` is needeod for < API 30 to avoid content rendering under the system bars when Modal is shown with Activity that is edge-to-edge.
Changelog:
[Android][Fixed] Fix Regression - Modal content rendering below system bar on < API 30 when activity is edge-to-edge
Reviewed By: cortinico
Differential Revision: D65280014
fbshipit-source-id: 616ff739be55635f1295ef3bf8b997a27ef769ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47269
There were [reports](https://github.com/reactwg/react-native-releases/issues/595) that patching in the fixes for iOS controlled input did not work as expected.
I think tracked this down to a difference in how I tested, where the controlled component I used passed value as a child of the `TextInput`, instead of via `value`. Passing via `value` triggers a secondary bug, where we don't correctly pass a reference to correct ShadowView when creating attributedstring, specifically in the iOS TextInputShadowNode impl.
We previously passed nothing for the ShadowView (only the first two struct fields). This was exposed in D52589303 which enabled `-Wextra`, but there, I went with same behavior of passing empty ShadowView, instead of the correct behavior (like Android impl) of passing a ShadowView of the current ShadowNode.
After fixing this, we now correctly create event emitters in the passed attributedstring, which matches expectations for pargraph-level eventemitter now in typing attributes. We don't seem actually use this on iOS for TextInput right now (just Text), but this is likely the right foundation for events regardless.
Changelog:
[iOS][Fixed] - Fix missing emitter attributes on iOS TextInput when controlled component value specified using `value` instead of `children`
Reviewed By: cipolleschi
Differential Revision: D65108163
fbshipit-source-id: 499fe28439fabd2579eca6ded7fd13fd8ea2e43e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46970
Fixes https://github.com/facebook/react-native/issues/44157
This one is a bit of a doozy...
During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored.
In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that:
1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting.
2. Backing text has an NSShadow with no color (does not render) not in the AttributedText
3. Event emitter attributes change on each update, and new text does not inherit the attributes.
The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison.
The event emitter attributes being misaligned is a real problem. We fix in a couple ways.
1. We treat the attribute values as equal if the backing event emitter is the same
2. We set paragraph level event emitter as a default attribute so the first typed character receives it
After these fixes, scenario in https://github.com/facebook/react-native-website/pull/4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress).
Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue.
I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue).
Changelog:
[iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch)
Reviewed By: javache, philIip
Differential Revision: D64121570
fbshipit-source-id: 2b3bd8a3002c33b68af60ffabeffe01e25c7ccfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47195
When a user wants to create a Fabric Component i their app (not in a separate library) the app fails to build because:
- The custom component has to inherit from `RCTViewComponentView`
- `RCTViewComponentView` imports `ViewProps.h`
- `ViewProps.h` imports `HostPlatformViewProps.h`
- `HostPlatformViewProps.h` imports `BaseViewProps.h`
- `BaseViewProps.h` imports `YogaStylableProps.h`
which is a Yoga private header and the App has not visibility over it.
It is also not possible to fix this issue with forward declaring the `YogaStylableProps`, because `BaseViewProps` inherit from the yoga's props, so the compiler needs the full declaration of `YogaStylableProps` to work
This needs to be picked in 0.76
## Changelog
[iOS][Fixed] - Give apps access to Yoga headers
Reviewed By: blakef
Differential Revision: D64925222
fbshipit-source-id: e724076bbfb0a678948340dfab2ce609e6509533
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47018
This change makes it so that newly typed text in a TextInput will include the existing attributes present based on cursor position. E.g. if you type after an inner fragment with blue text, the next character will be blue (or, an event emitter specific to an inner fragment will also be expanded). This is a behavior change for the (admittedly rare) case of uncontrolled TextInput with initially present children AttributedText, but more often effect controlled components, before state update (we are after, less likely to need to reset AttributedString because of mismatch).
Originally included this in D64121570, but it's not needed to fix the common case since we include paragraph-level event emitter as part of default attributes, and has some of its own risk, so I decided it is better separate.
Changelog:
[iOS][Changed] - Include existing attributes in newly typed text
Reviewed By: cipolleschi
Differential Revision: D64352310
fbshipit-source-id: 90ef8c49f50186eadf777e81cf6af57e1aada207
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
* Re-enable integration tests (#46639)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46639
These tests were skipped when we were switching to component stacks, which also hid a bug later in the stack. Re-enable them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349616
fbshipit-source-id: ccde7d5bb3fcd9a27adf4af2068a160f02f7432a
* Add integration tests for console errors + ExceptionManager (#46636)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46636
Adds more integration tests for LogBox (currently incorrect, but fixed in a later diff).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349614
fbshipit-source-id: 8f5c6545b48a1ed18aea08d4ecbecd7a6b9fa05a
* Refactor LogBox tests to spies (#46638)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46638
This is annoying, but in the next diff that fixes a bug I need to test using the default warning filter instead of a mock (really, all this mocking is terrible, idk why I did it this way).
Unfortunately, in Jest you can't just reset mocks from `jest.mock`, `restoreMocks` only resets spies and not mocks (wild right).
So in this diff I converted all the `jest.mock` calls to `jest.spyOn`. I also corrected some of the mocks that require `monitorEvent: 'warning',` like the warning filter sets.
I also added a test that works without the fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349615
fbshipit-source-id: 4f2a5a8800c8fe1a10e3613d3c2d0ed02fca773e
* Fix errors with component stacks reported as warnings (#46637)
Summary:
Ok so this is a doozy.
## Overview
There was a report that some console.error calls were being shown as warnings in LogBox but as console.error in the console. The only time we should downlevel an error to a warning is if the custom warning filter says so (which is used for some noisy legacy warning filter warnings internally).
However, in when I switched from using the `Warning: ` prefix, to using the presence of component stacks, I subtly missed the default warning filter case.
In the internal warning filter, the `monitorEvent` is always set to something other than `unknown` and if it's set to `warning_unhandled` then `suppressDialog_LEGACY` is always false.
However, the default values for the warning filter are that `monitorEvent = 'unknown'` and `suppressDialog_LEGACY = true`. In this case, we would downlevel the error to a warning.
## What's the fix?
Change the default settings for the warning filter.
## What's the root cause?
Bad configuration combinations in a fragile system that needs cleaned up, and really really bad testing practices with excessive mocking and snapshot testing (I can say that, I wrote the tests)
## How could it have been caught?
It was, but I turned off the integration tests while landing the component stack changes because of mismatches between flags internally and in OSS, and never turned them back on.
Changelog: [General] [Fixed] - Fix logbox reporting React errors as Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46637
Reviewed By: huntie
Differential Revision: D63349613
Pulled By: rickhanlonii
fbshipit-source-id: 32e3fa4e2f2077114a6e9f4feac73673973ab50c
* [LOCAL] using older version of React Dev Tools
- Older version has old URL, updated tests
- Comments on test don't match what's being tested. Updated.
---------
Co-authored-by: Rick Hanlon <rickhanlonii@meta.com>
Summary:
AppRegistry was not treated as a Callable Module in bridgeless mode. This is breaking headless tasks on Android.
Fixes:
- https://github.com/facebook/react-native/issues/46050
## Changelog:
[ANDROID] [FIXED] - Made AppRegistry callable from Native code in Bridgeless (fixes headless tasks)
Pull Request resolved: https://github.com/facebook/react-native/pull/46480
Test Plan: Used repro from linked issue
Reviewed By: javache
Differential Revision: D62637486
Pulled By: cortinico
fbshipit-source-id: 756527003ac6d712e76c02c188e280d15c010068
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47237
The Xcodeproj gem has been released yesterday to version 1.26.0 and it broke the CI pipeline of react native.
This should fix the issue
## Changelog
[Internal] - Pin Xcodeproj gem to 1.26.0
Reviewed By: blakef
Differential Revision: D65057797
fbshipit-source-id: f4035a1d3c75dd4140eb1646ab2aa0ccb08fb16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47101
See https://github.com/facebook/react-native/issues/47011
borders do not have this problem because they call `removeAllAnimations` on the layer after changing it, which is what I am doing here
Changelog: [iOS] [fixed] - Fixed bug where background colors would sometimes animate when changing on Views
Reviewed By: cipolleschi
Differential Revision: D64493968
fbshipit-source-id: cf81549f21b124b67c6e7647c6ae827bfe80a9cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47176
While writing the guide for the New Architecture, we realized that we need to exclude the generation of the Cls function in the RCTThirdPartyFabricComponentsProvider for components defined in the app.
This is needed because a component that is defined in the app will have those function defined in the app project. However, the RCTThirdPartyFabricComponentsProvider is generated in Fabric, inside the Pods project.
The pod project needs to build in isolation from the app and cocoapods then link the app to the pods project. But the compilation of the pods project fails if one of the symbol needed by the pods lives in the app.
By disabling the generation of that function in th RCTThirdPartyFabricComponentsProvider, we can successfully build the app.
The downside is that the user needs to register the component manually, but this is not an issue because if they are writing a component in the app space, they have all the information tomanually register it in the AppDelegate
## Changelog
[iOS][Fixed] - Do not generate the ComponentCls function in the RCTThirdPartyFabricComponentsProvider for components deined in the app.
Reviewed By: cortinico, blakef
Differential Revision: D64739896
fbshipit-source-id: 0eca818ea0198532a611377d14a3ff4c95cb5fe3
Summary:
For users who may have node installed in a path with a space, this requires escaping. For example:
```
NODE_BINARY=/Users/blakef/Library/Application Support/fnm/node-versions/v20.12.0/installation/bin/node
```
Needs to be:
```
NODE_BINARY=/Users/blakef/Library/Application\ Support/fnm/node-versions/v20.12.0/installation/bin/node
```
# Changelog
[iOS][Fixed] Generated NODE_BINARY in .xcode.env.local now supports paths with a space
Reviewed By: cipolleschi
Differential Revision: D64080118
fbshipit-source-id: 1045473e4fd284fc570fa538984618630be1af6d
Summary:
Whe migrating this interface to Kotlin we've subtly introduced a breaking change which is causing a lot of breakages in the ecosystem.
This is forcing users to do:
```
// Before
reactContext.getNativeModule(UIManagerModule::class.java)!!.eventDispatcher
// After
reactContext.getNativeModule(UIManagerModule::class.java)!!.getEventDispatcher()
```
This reverts this breaking change.
Plus the method had a generic parameters which was completely unnecessary so I'm removing it.
Changelog:
[Android] [Fixed] - Undo breaking change on UIManager eventDispatcher accessor
Reviewed By: cipolleschi
Differential Revision: D64533594
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47086
When we migrated `ViewManagerDelegate` to Kotlin, we convered his string params to be `String` (rather than `String?`).
Existing implementation of this interface in OSS written in Kotlin were using `String?` due to this interface being in Java (and not being Nullsafe annotated).
Therefore now changing this interface from `String?` to `String` is a breaking change for them.
Affected libraries are:
https://github.com/search?q=%22fun+receiveCommand%28%22+%22commandId%3A+String%3F%22+%22args%3A+ReadableArray%22+language%3Akotlin+-org%3Afacebook+-is%3Afork&type=code&p=4
This prevents the breaking change and should be included in 0.76.
Changelog:
[Android] [Fixed] - Undo breaking change on ViewManagerDelegate.kt String params
Reviewed By: cipolleschi
Differential Revision: D64532446
fbshipit-source-id: aac286554ad0e35f557160f900bcbad1acc5930d
Summary:
When migrating `PackagerConnectionSettings` from Java to Kotlin in https://github.com/facebook/react-native/pull/45800 the new class ended up being declared as final, causing a breaking change in 0.76.
We should add the `open` directive to `PackagerConnectionSettings.kt` to restore the old behavior. That would be crucial for the `expo-dev-client` package, given that Expo needs to be able to extend this class in order to overwrite the `debugServerHost` value.
## Changelog:
[ANDROID] [FIXED] - Make PackagerConnectionSettings class open again
Pull Request resolved: https://github.com/facebook/react-native/pull/47005
Test Plan: Run RNTester on Android
Reviewed By: huntie
Differential Revision: D64323645
Pulled By: cortinico
fbshipit-source-id: 6870a3dee929ba664e4c402f321f84af7704f892
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46764
This is a patched fix to earlier attempt (D63700769) and resolving crash due to`java.lang.IllegalArgumentException: View=DecorView@b9f88af[AdsManagerActivity] not attached to window manager`.
- removing ` !dialogWindow.isActive` check as it is always true resulting in always doing early return causing other bugs
- adding try/ catch instead so the code can still run but can catch the known exception without crashing
Changelog:
[Android][Fixed] - Fix crash for Modal not attached to window manager
Reviewed By: mdvacca
Differential Revision: D63712422
fbshipit-source-id: 85fb6df340eb1139f954c92b5f1daf0dc41671d2
Summary:
Ok so this is a doozy.
## Overview
There was a report that some console.error calls were being shown as warnings in LogBox but as console.error in the console. The only time we should downlevel an error to a warning is if the custom warning filter says so (which is used for some noisy legacy warning filter warnings internally).
However, in when I switched from using the `Warning: ` prefix, to using the presence of component stacks, I subtly missed the default warning filter case.
In the internal warning filter, the `monitorEvent` is always set to something other than `unknown` and if it's set to `warning_unhandled` then `suppressDialog_LEGACY` is always false.
However, the default values for the warning filter are that `monitorEvent = 'unknown'` and `suppressDialog_LEGACY = true`. In this case, we would downlevel the error to a warning.
## What's the fix?
Change the default settings for the warning filter.
## What's the root cause?
Bad configuration combinations in a fragile system that needs cleaned up, and really really bad testing practices with excessive mocking and snapshot testing (I can say that, I wrote the tests)
## How could it have been caught?
It was, but I turned off the integration tests while landing the component stack changes because of mismatches between flags internally and in OSS, and never turned them back on.
Changelog: [General] [Fixed] - Fix logbox reporting React errors as Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46637
Reviewed By: huntie
Differential Revision: D63349613
Pulled By: rickhanlonii
fbshipit-source-id: 32e3fa4e2f2077114a6e9f4feac73673973ab50c