Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47886
We were not scaling border radii properly when they overlap.
We were relying on Android's handling of the issue which is not compliant with the web algorithm leading to **visible gaps between layers when the radii overlapped**
We are now following web spec https://www.w3.org/TR/css-backgrounds-3/#corner-overlap
Changelog: [Android] [Added] Add overlapping radii resolution logic preventing incorrect rendering
Reviewed By: NickGerleman
Differential Revision: D66269809
fbshipit-source-id: 4ab7025dc1e41be6205ff6b828617e1e222536a9
Summary:
The `onLayout` handler of the `KeyboardAvoidingView` view is async due to the `await AccessibilityInfo.prefersCrossFadeTransitions` in `_relativeKeyboardHeight`.
A connected `onLayout` handler will be unable to access the event. Call `persist()` on the event so that it can be accessed asynchronously.
## Changelog:
[GENERAL] [FIXED] - Accessing KeyboardAvoidingEvent event in onLayout handler
Pull Request resolved: https://github.com/facebook/react-native/pull/47798
Test Plan:
The following should not produce an error:
```
import * as React from 'react';
import {
KeyboardAvoidingView,
SafeAreaView,
TextInput
} from 'react-native';
export default function() {
return (
<SafeAreaView>
<KeyboardAvoidingView onLayout={(event) => console.log(event)} behavior="padding">
<TextInput />
</KeyboardAvoidingView>
</SafeAreaView>
);
}
```
Reviewed By: cipolleschi
Differential Revision: D66306085
Pulled By: dmytrorykun
fbshipit-source-id: 9ccf00db79947670ddc7de74a47cc6dc27455fc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47876
Currently, if a device is connected to the bundler via, say, `http://10.0.2.2:8081` (Android default), and a debugger is opened on `http://localhost:8081`, we rewrite hostnames `10.0.2.2.`<->`localhost` so that URLs are correct relative to each.
However, if the debugger is on a different port or protocol, this breaks down - because we only rewrite hostnames.
This fixes that by using the debugger's connecting `Host` header and `encrypted` state to derive the base URL of the server relative to the frontend. We then update the rewriting logic to use this actual full origin (protocol + host) in place of the device-relative origin.
Changelog:
[General][Fixed] dev-middleware: Fix URL rewriting where device and debugger reach the server on different ports/protocols.
Reviewed By: huntie
Differential Revision: D66077627
fbshipit-source-id: 01f6565149caa34b1e9e50dd58deb0122485657c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47872
Largely a refactoring to the way we currently rewrite `url`/`urlRegex` in `Debugger.setBreakpointByURL` CDP requests (debugger->target).
Rewriting regexes is fragile, it only really works if we can assume `'localhost'` appears literally and that ports and protocols don't need changing. The intention here is to freeze the current behaviour so as not to break anyone relying on it (if anyone is), and decouple it from more robust rewriting we want to generalise.
Also adds simple regex escaping to host names (always IPv4 addresses) we inject into regex patterns, since the previous approach could've led to false matches in unlikely edge cases.
Changelog:
[General][Fixed] dev-middleware: Regex-escape IP addresses in urlRegex replacements
Reviewed By: huntie
Differential Revision: D66238782
fbshipit-source-id: 4cd0029081d68c193e36d3713057ffdc7ef0656f
Summary:
currently running jest test, it shows an error:
```
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down. From __tests__/App.test.tsx.
at getState (node_modules/react-native/Libraries/Utilities/Appearance.js:18:26)
at addChangeListener (node_modules/react-native/Libraries/Utilities/Appearance.js:71:19)
at subscribe (node_modules/react-native/Libraries/Utilities/useColorScheme.js:10:66)
at subscribeToStore (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:6232:10)
at commitHookEffectListMount (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13038:26)
at commitPassiveMountOnFiber (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14461:11)
at commitPassiveMountEffects_complete (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14421:9)
at commitPassiveMountEffects_begin (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14408:7)
at commitPassiveMountEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14396:3)
at flushPassiveEffectsImpl (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16287:3)
at flushPassiveEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16236:14)
at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16051:9
at workLoop (node_modules/scheduler/cjs/scheduler.development.js:266:34)
at flushWork (node_modules/scheduler/cjs/scheduler.development.js:239:14)
at Immediate.performWorkUntilDeadline [as _onImmediate] (node_modules/scheduler/cjs/scheduler.development.js:533:21)
```
it is a regression from https://github.com/facebook/react-native/issues/46123 that to have a lazy require.
this pr tries to mock `useColorScheme` to return `light`. i think we don't necessarily test the color scheme changes in jest runtime. originally `useColorScheme` also returns `light` because of [this statement](9a60038a40/packages/react-native/Libraries/Utilities/Appearance.js (L77-L83))
## Changelog:
[GENERAL] [FIXED] - Fixed jest error from Appearance.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47629
Test Plan:
```sh
$ npx react-native-community/cli init RN0762 --pm bun --version 0.76.2
$ cd RN0762
$ bun test run
```
Reviewed By: cipolleschi
Differential Revision: D66297456
Pulled By: huntie
fbshipit-source-id: 80d1460532e76bd1815c66964547b50d7f7b3558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47874
We should be searching for the .bat file on Windows to remain compatible with some user setups.
Changelog: [Android][Fixed] look for sdkmanager.bat
Reviewed By: cipolleschi
Differential Revision: D66295240
fbshipit-source-id: 6b79a9aa40f77ed9c5b3d6ad92b1a62e78159223
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47875
The old architecture looks broken because in the OnLoad.cpp file we try to include the autolinking.h header which is only generated when the New Architecture is enabled.
This fix guards the include and the usage of the function provided by the autolinking so that the old architecture should work as well.
## Changelog
[Internal] - Include autolinkin.h in OnLoad.cpp only if it exists
Reviewed By: blakef
Differential Revision: D66295318
fbshipit-source-id: 18461e6b70ac92af57b805bef51c0df49db02283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47568
Resolves https://github.com/facebook/hermes/issues/1549.
Changelog:
[General][Fixed] - When using Babel with plain JavaScript files, support for additional user syntax plugins should be fixed (now uses Babel's parser instead of hermes-parser). There is no change for JS files annotated with `flow`, where extended JS syntax remains unsupported.
Reviewed By: blakef
Differential Revision: D65816797
fbshipit-source-id: 9f05e86019548ac8727ee65c2e2c417d78a406d8
Summary:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47871
Changelog: [internal]
No need to keep going back to save test files when we change C++ files and need to re-run tests :)
Reviewed By: javache
Differential Revision: D66293212
fbshipit-source-id: dc232e1d3f7f8ae1578e894ce14bd21ccf3c8ade
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47870
Changelog: [internal]
This flag allows us to run optimized mode by using the right buck modes for the Fantom CLI, using minified + dev in Metro and building bytecode using Buck as well.
It's disabled by default but in the future we can enable it based on the configuration in the test file (e.g.: if it's a benchmark) or we can run tests in both modes by default to catch problems caused by the differences between environments.
Reviewed By: rshest
Differential Revision: D66292709
fbshipit-source-id: d25294b739ff6a67507990241784b838d5b30dcd
Summary:
### Problem
The calculated width for a multiline text is based on the longest line. However it does not account for text that wraps.
**Example** if numberOfLines=1 and the text wraps
```
+---------------------------+
This is a long text that
will wrap
+---------------------------+
```
The TextView will render
```
+---------------------------+
This is a long text t...
+---------------------------+
```
because the `calculatedWidth` took the width of the first line.
Also see https://github.com/facebook/react-native/pull/41770#issuecomment-2453611554 for additional context.
### Solution
If the text wraps, take the whole width.
```
+---------------------------+
This is a long text that w...
+---------------------------+
```
Fixes https://github.com/facebook/react-native/issues/39722
Fixes https://github.com/facebook/yoga/issues/1730
## Changelog:
[GENERAL] [FIXED] - Fix text not taking full width
Pull Request resolved: https://github.com/facebook/react-native/pull/47435
Test Plan:
```tsx
<Text
numberOfLines={1}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{'This is a long text that will wrap.'}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\ntest\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
```
1. Verify that the first and third text take full width
2. Verify that the second text does not take full width
| Before | After |
|:------:|:-----:|
| <img width="480" alt="Screenshot 2024-11-05 at 9 00 24 PM" src="https://github.com/user-attachments/assets/b8d765c0-f4b1-42c6-afc7-75862c52612a"> | <img width="480" alt="Screenshot 2024-11-05 at 9 01 49 PM" src="https://github.com/user-attachments/assets/f1534c14-a56a-4d44-8edc-4d9f75166cb2"> |
Reviewed By: NickGerleman
Differential Revision: D65521732
Pulled By: realsoelynn
fbshipit-source-id: 0bb0bb306445e73e8b24ff4c02921739d15ee07e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47754
The `./resolveAssetSource` processor was added to the `defaultSource` prop in the `RCTImageView` static view config in D65819218.
To match this in native view config, we're adding the `customType = "ImageSource"` hint to the view config infra, so it knows to assign correct processor to the native view config in runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66228921
fbshipit-source-id: d0e0cd9e2f5cc0ba5b3a7002f7ade3f45305a2ac
Summary:
RNTester jobs are failing because we bumped folly to the recent version but we didn't update the podfile.lock
## Changelog:
[Internal] - Bump Podfile.lock to new Folly version
Pull Request resolved: https://github.com/facebook/react-native/pull/47868
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292931
Pulled By: cipolleschi
fbshipit-source-id: 19cbe1321d2891135aa9777823e9dff2916b16dc
Summary:
CI is failing to build HermesC on windows due to a version mismatch of the CMake already installed
## Changelog:
[Internal] - Fix Windows CI for HermesC
Pull Request resolved: https://github.com/facebook/react-native/pull/47867
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292617
Pulled By: cipolleschi
fbshipit-source-id: 5e8f4f45e33fbdd9ff163b4e8a09cb98d4366dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47733
In https://github.com/facebook/yoga/pull/1729 I moved the cleanup of `display: contents` nodes to happen before all the early returns, but that change also made it be called **before** `cloneChildrenIfNeeded`. It actually needs to be called after `cloneChildrenIfNeeded` to make sure that children of `display: contents` nodes are properly owned.
It also needs to be called in every short-path, so it's being called in four places in this PR. Please let me know whether it's ok or not.
X-link: https://github.com/facebook/yoga/pull/1743
Reviewed By: NickGerleman
Differential Revision: D65953902
Pulled By: zeyap
fbshipit-source-id: 0b18a5651f19c23564f5b3aa2a50833426e9ca5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47732
This pull request addresses the issue where combining align-content and align-items properties resulted in incorrect layout behavior in Yoga version 3.1.0, as reported in [Issue https://github.com/facebook/yoga/issues/1739](https://github.com/facebook/yoga/issues/1739).
# Changes Made:
Alignment Logic Update: Modified the alignment calculations to ensure that the combination of align-content and align-items properties produces the expected layout, consistent with CSS Flexbox standards and previous Yoga versions.
Test Cases Added: Introduced new test cases to cover scenarios involving various combinations of align-content and align-items properties to prevent future regressions.
# Testing:
All existing tests pass successfully.
New test cases confirm that the layout behaves as expected when align-content and align-items are used together.
# Impact:
This fix ensures that layouts using both align-content and align-items properties render correctly, aligning with the behavior observed in Yoga version 1.19.0 and standard web browsers.
X-link: https://github.com/facebook/yoga/pull/1742
Reviewed By: joevilches
Differential Revision: D65953882
Pulled By: zeyap
fbshipit-source-id: 7e12a21b1d442b35c3f3536cad32dc4b82130d15
Summary:
- Current implementation does not follow CSS spec for rectangle boxes with corner angles. It is using non spec compliant algorithm to calculate start and end points. This PR follows the spec compliant algorithm to implement and makes sure Web, iOS and Android gradients are identical with corner angles.
- Also, currently it is using `CAGradientLayer` which does not support spec compliant start and end points i.e. start and end point can be outside of rectangle bounds. This leads to inconsistent gradients on iOS for corner angles compared to web and android. So this PR replaces it with `CGGradient`.
- I have also moved some files to make it easier to add more background image types in future.
## Changelog:
[GENERAL] [FIXED] - Linear gradient start and end point algorithm.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/47003
Test Plan:
- Added multiple gradient example which should be identical in all platforms (Web, iOS and Android) and tested thoroughly on all platforms. I think some visual test cases can help here.
- I have referred to [blink's](https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/css/css_gradient_value.cc) implementation.
## Aside
Took a while to understand the [spec](https://www.w3.org/TR/css-images-3/#corner-gradient-example), but felt great after getting it. Gradients should be 100% identical on all platforms now. Sorry i missed testing cornered angles + rectangles earlier and I found out it is inconsistent on platforms just this weekend 😅
<img width="1389" alt="Screenshot 2024-10-14 at 12 24 45 AM" src="https://github.com/user-attachments/assets/2f61eb87-502b-4b8c-88f3-d8a3cca9a7a3">
Reviewed By: joevilches
Differential Revision: D64497127
Pulled By: jorge-cab
fbshipit-source-id: 2647176ae2ee74b6c71f9061465b07dccdabcfc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47735
We are trying to remove or minimize private header usage in YogaLayoutableShadowNode.cpp and YogaLayoutableShadowNode.h. There are a few "trivial" ones, meaning some private call maps 1:1 to an existing public API, so I just opt to use that instead
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66131948
fbshipit-source-id: 7068021513703d1c142d3c298f4804e4e8b81ee2
Summary:
This PR fixes the code for generating EventEmitter C++ code in case nested objects in arrays are used.
```typescript
export interface NativeProps extends ViewProps {
onEvent: DirectEventHandler<
Readonly<{
payloadArray: Readonly<
{
obj: Readonly<{ str: string }>
}[]
>
}>
>;
}
export default codegenNativeComponent<NativeProps>('SomeComponent');
```
In this case the generated `EventEmitters.cpp` code would contain:
```c
obj.setProperty(runtime, "str", payloadArrayValue,obj.str);
```
while
```c
obj.setProperty(runtime, "str", payloadArrayValue.obj.str);
```
is expected.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Codegen: Support nested objects in arrays
Pull Request resolved: https://github.com/facebook/react-native/pull/47514
Test Plan: Tested with the reproduction case above to verify correct output.
Reviewed By: javache
Differential Revision: D65848670
Pulled By: elicwhite
fbshipit-source-id: 0021e87bc7213fff615465cab8554cc1a2159522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47737
We may see an NSRangeException when setting new AttributedString content, where setting the AttributedString itself changes selection (before we mutate it later).
It seems like the selection here is not in a good state yet in regards to the AttributedString backing exposed (since we are reading it while modifying it). So let's fold the logic for updating typing attributes into the collection of ignored work from non-user-selection updates, since programatically setting an AttributedString will already trigger updating typing attributes.
I also added a nil check here, which is unrelated to the crash, but it seems like we should have it for safety...
Changelog:
[iOS][Fixed] - Fix possible NSRangeException when updating typing attributes in response to new text content
Reviewed By: cipolleschi
Differential Revision: D66202986
fbshipit-source-id: fded492b5022c5fef5b9563f93a57549d06a7020
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47738
- updating targetSdk to 35 for RN Android and helloworld
- **Note:** `tagetSdk` of RN Android does not have effect on the app's targetSdk. App can set `targetSdk` regardless of what RN targetSdk is. Updating the targetSdk just signals that RN Android has been tested with targetSdk 35 and apps can choose to support lower targetSdk as needed.
Changelog:
[Android][Changed] updating targetSdk to 35 (apps can still choose their own targetSdk regardless of RN version)
Reviewed By: NickGerleman
Differential Revision: D66209381
fbshipit-source-id: 2f26e8f605a383ff662e4b1d65611f186a7d7979
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47734
- With forced edge-to-edge on Android 15 targetSdk 35, `HermesBadge` overlaps with the top status bar.
- Move the location of the HermesBadge to align with bottom of the header so we can avoid UI overlap with minimal changes to the template.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D66183918
fbshipit-source-id: 6e9eff337660a133349a2813e9ee033a8d2b749e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47707
NewAppScreen should be removed from public API test
Changelog: [Internal]
Reviewed By: cipolleschi, blakef
Differential Revision: D66165484
fbshipit-source-id: 2b72a874e443447a2b444921f25cec729bcb89c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47761
When breaking the last dependency, we created the `RCTApDependencyProvider` in the Codegen pod.
This is not an issue per sè. The problem comes in with the new template in Swift: ReactCodegen contains some headers with some C++ code that Swift can't really process.
That's why most libraries started failing in jobs like [this one](https://github.com/facebook/react-native/actions/runs/11906196751/job/33177904733): the template app was not able to load the `ReactCodegen` pod in the Swift app delegate.
Given that the app delegate only have to actually load the RCTAppDependencyProvider, I extracted that class in its own pod: ReactAppDependencyProvider.
The name of the pod does not follow the React-RCTXXX structure because that will create issues with the import statements and the `use_frameworks!` use case.
> [!NOTE]
> We need to update the template and change the `import ReactCodegen` to `import ReactAppDependencyProvider`
## Changelog:
[iOS][Added] - Extract RCTAppDependencyProvider in the ReactAppDependencyProvider pod
Reviewed By: blakef
Differential Revision: D66241941
fbshipit-source-id: 6b888109c65d9560fff322ec84a16da78fbcd64b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47760
Changelog: [internal]
(this is internal because this API isn't enabled in OSS yet)
This fixes 2 bugs in `MutationObserver`:
1. Incorrectly reporting updates for the same node multiple times, if changes are observable by different targets in the same observer.
2. Incorrectly ignoring observations of subsequent targets in a given observer.
These were caught when migrating the unit tests for `MutationObserver` that were mocking Fabric to a Fantom integration test that uses the whole C++ infra.
Reviewed By: sammy-SC
Differential Revision: D66232571
fbshipit-source-id: b6e967ca4deaa1a69d35f14d4f921103fec2bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47759
Changelog: [internal]
These interfaces should be available in the global scope, so this exposes them in their setup modules.
Reviewed By: javache
Differential Revision: D66232574
fbshipit-source-id: 191c579ffce3fb8b4b454b5c5725661ff160a46f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47758
Changelog: [internal]
This helps with debugging when adding logs in native code. By default they're logged to stderr and not shown in the Jest output, but we can opt into getting them with this new flag.
Reviewed By: sammy-SC
Differential Revision: D66232572
fbshipit-source-id: d507fa4438ae46988fafc92123d0954ab3d27631
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47673
Update shared monorepo build script:
- Refactor entry point discovery and file iteration
- Add support for "exports" subpath patterns (skip considering as entry point with warning)
This is required for the incoming migration of `react-native-codegen` to this build setup (D51465053).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D66121262
fbshipit-source-id: 0deb2c2b26de442ee348ef9de54a1fa144368b6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47685
Currently, we assume any URL with a hostname of `10.0.2.2` or `10.0.3.2` (device-relative) is eligible for rewriting to `localhost` (frontend-relative), because we assume the device is an Android emulator. We rewrite these URLs between device and dev machine so that the rewritten URLs are reachable from the dev machine.
This diff narrows this logic so that we'll only rewrite URLs where the hostname matches the pre-existing list *and* this matches the host the device is actually connected on, according to its headers from the original connection.
The main motivation for this change is to unblock removing assumptions about device-reachable vs server-reachable hosts. Later in the stack we'll drop the hardcoded listing of `10.0.2.2` etc in favour of identifying URLs that target the dev server, from whatever network.
There's also an edge case fix here that `10.0.2.2` etc might actually refer to a remote LAN server, and not be an Android emulator's alias for for an emulator host.
Changelog:
[General][Fixed] RN DevTools: Don't assume 10.0.2.2 is an alias for localhost unless it's used to establish a connection to the server
Reviewed By: huntie
Differential Revision: D66058704
fbshipit-source-id: bad28717b0c9b1ca43e2ea3391cef13f87892e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47719
There is a subset of `ImageProps` that are used by Android but not used by iOS. They were missing in the `ImageProps.h`. It was fine when they were only consumed by the Android mounting layer. But it becomes a problem if we want to write some shared C++ code based on those props.
This diff adds those props to the corresponding C++ type.
This should have no practical effect for both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65426569
fbshipit-source-id: dc1c9fe4a6e0e62e62f84b9b249e1c7d253290f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47608
This is a codemod. It was automatically generated and will be landed once it is approved and tests are passing in sandcastle.
You have been added as a reviewer by Sentinel or Butterfly.
Autodiff project: fileops2
Autodiff partition: xplat.js.react-native-github.packages.react-native.ReactCommon.cxxreact
Autodiff bookmark: ad.fileops2.xplat.js.react-native-github.packages.react-native.ReactCommon.cxxreact
This updates `open`, `close`, `read`, `write`, and `pipe` call sites to use
`folly::fileops` qualified name lookup.
This is the 2nd phase in a 3-phase change to remove folly's global definitions
of the posix functions that conflict with windows CRT.
The 1st phase created namespaces for folly's posix functions. The 2nd phase
updates callsites to use the qualified name of folly's `open`, `close`,
`read`, `write`, and `pipe` functions. The 3rd and final phase will remove
folly's globally defined posix functions and have windows CRT define them
again.
**What is the reason for this change?**
Folly's global definitions of posix functions on Windows causes `#include`
order issues if folly is not included first.
For example, when `gtest/gtest.h` is included before folly, gtest includes
`windows.h` and that declares `open`, `read`, and `chdir`, which creates
ambiguous references to folly's `open`, `read`, and `chdir`.
Another example is where posix functions go undeclared when
`folly/portability/windows.h` is included without other portability headers
(e.g., `folly/portability/unistd.h`). `folly/portability/windows.h` includes
`windows.h` in a way that only underscore versions of the posix functions are
available (e.g., `_open`, `_close`).
These issues create friction for windows development.
**Background: What is the purpose of `folly::portability::{fcntl,stdlib,sysstat,unistd}`?**
It is a portability layer to make posix functions available and behave
consistently across platforms. Some posix functions don't exist on windows
(e.g., `sysconf`). Some other posix functions, folly changes to adapt behavior
across platforms. For example, on windows folly defines `open`, `read`,
`write`, and `close` functions to work with sockets. Folly makes these
functions available in the global scope for convenience.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65855147
fbshipit-source-id: b06863330ca213b9d1bffe0ee85e0fbf1bc8a845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47713
`defaultSource` is defined as a single `ImageSource` in docs (https://reactnative.dev/docs/next/image#defaultsource) but its type is a vector of `ImageSource`s in `ImageProps.h`.
This diff changes its C++ type to just `ImageSource`.
Technically, this is a breaking change, however I don't think folks should directly access `ImageProps` outside of `RCTImageComponentView.mm`
Moreover, this prop is actually not implemented in Fabric, so this change should have no practical effect.
Changelog: [Internal]
Facebook
T208171435 - [RN][Fabric][iOS] Implement defaultSource support for Image
Reviewed By: javache
Differential Revision: D65821570
fbshipit-source-id: 38139b0f8d6da495e82c4ef72c19af3db254ba6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47637
Changelog: [Internal]
RSNRS does not support off JS thread layout due to current fiber tree corruption when syncing happens on more than one shadow tree at the same time. This diff guarantees that RSNRS will only be enabled on the JS thread, avoiding any state corruption.
Reviewed By: sammy-SC
Differential Revision: D64500893
fbshipit-source-id: aa20f54a0fcfa47534ae099e95307a692bd9fd0f
