Summary:
X-link: https://github.com/pytorch/pytorch/pull/89233
The `-weak_framework` flag is no longer necessary, Buck will weakly link frameworks depending on the `target_sdk_version` of the binary being linked.
Reviewed By: ebgraham, malfet
Differential Revision: D41348639
fbshipit-source-id: 47992282ba030294b2304c550d49df13e24e9c79
Summary:
UIRefreshControl has a tight integration with iOS in terms of UINavigationBar/UIScrollView. In this regard, whenever there's a UIScrollView with a UINavigationBar on top, the OS automatically adjusts the contentInset of the UIScrollView to reflect that (something that is exposed to React Native). In a similar manner, UIScrollView passes this along to the attached UIRefreshControl.
By setting the frame manually, the RCTRefreshControl component was preventing this behavior. Although having the option is desired, it should not be done by default. In the past it was possible to adjust for this by manually setting the correct value, calculating the statusBar's height/safeAreaInsets.top and appending 44pt (the UINavigationBar height). However, due to changes related to the Dynamic Island (see [here](https://useyourloaf.com/blog/iphone-14-screen-sizes)), the safe area and the status bar size no longer align, making this calculation more tricky.
In summary: this changes allows `progressViewOffset` to exist (in order to maintain feature parity with Android) but provides the opportunity for the OSs default behavior to kick in when applicable.
| Applying by default | Not applying by default (this change) |
:-------------------------:|:-------------------------:
![](https://user-images.githubusercontent.com/753361/200828632-0c9aa605-770c-47be-a825-1e061478c2b4.gif) | ![](https://user-images.githubusercontent.com/753361/200828664-dded9a47-bdbc-4b88-8ab7-92a76cea47e8.gif)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix application of _progressViewOffset in RCTRefreshControl to not occur by default (when value is unset)
Pull Request resolved: https://github.com/facebook/react-native/pull/35281
Test Plan: The GIFs attached display the behavior as expected/unexpected. I'm unaware of any tests written for RCTRefreshControl that could be improved to cover this change. Notes appreciated.
Reviewed By: sammy-SC
Differential Revision: D41302080
Pulled By: cipolleschi
fbshipit-source-id: a2a8e6ef1dcc2e73220c2a182b4516f3bbd94f60
Summary:
Fix linter warning when pulling in some code into AR
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D41269423
fbshipit-source-id: 4305d6c362a51e62b19b4d3590fb0823073dff9a
Summary:
This change puts back D40716048 (279cfec55f) but in the right way, i.e. modifying the script that should generate those changes.
## Changelog
[iOS][Added] - Make the blobs proper TM
Reviewed By: dmytrorykun
Differential Revision: D41312160
fbshipit-source-id: 38850a63eb8d66ffd179743b4948a23340c8782e
Summary:
changelog: [internal]
Removing this to decrease clutter of warnings when devs navigate to Marketplace Home.
Reviewed By: cipolleschi
Differential Revision: D41306378
fbshipit-source-id: a1b7f8ebe1f4bb00e931d609eb97a3bbd5ef9052
Summary:
Cherry pick e877ebfe08 from React Native macOS into React Native Core. We've had this bug fix in our fork for a while now, so it's probably safe.
=== Original change notes ===
First, misc straightforward deprecated API updates.
Second, defensive changes to potentially address RCTDisplayLink crash.
Real-world data suggests crashes with this stack:
CVDisplayLink::start()
-[RCTDisplayLink updateJSDisplayLinkState] (RCTDisplayLink.m:157)
-[RCTDisplayLink registerModuleForFrameUpdates:withModuleData:]_block_invoke (RCTDisplayLink.m:67)
-[RCTTiming timerDidFire] (RCTTiming.mm:324)
-[_RCTTimingProxy timerDidFire] (RCTTiming.mm:93)
Some symbols are missing in this stack, presumably due to compiler optimizations.
-updateJSDisplayLinkState is calling CVDisplayLinkStart as a result of a
call to "_jsDisplayLink.paused = NO".
-registerModuleForFrameUpdates block is presumably getting called via pauseCallback,
likely via [RCTTiming startTimers], presumably owned by RCTCxxBridge.
The most likely immediate explanation for the crash is that we are calling
CVDisplayLinkStart with a zombie _displayLink pointer.
However there is a lot of indirection here as well as thread-hopping, and
unfortunately no clearly incorrect code that would explain such a zombie pointer.
Some defensive changes:
-explicitly remove the association to pauseCallback when underlying display link object is invalidated.
-remove a prior attempt at additional check in updateJSDisplayLinkState itself as it is not relevant.
-make sure we explicitly set _displayLink to NULL when we release it, such that there is one less failure point.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - RCTDisplayLink fix plus bonus deprecated API cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/35359
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D41335438
Pulled By: christophpurrer
fbshipit-source-id: 5e97d28eab7dd8e5c81d0a5386df6631e16405a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35315
These headers are needed on react-native-macOS, but not explicitly imported all the time.
It seems that some UIKit header will implicitly import them.
We have other use case in react-native(-iOS) in which we also explicitly importing them - https://github.com/facebook/react-native/search?q=QuartzCore- , hence use following 'that' practice 'here'.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D41229835
fbshipit-source-id: b0182bf4f7905e8e157b341eb62cadec6ba354ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35106
This Diff remove the assert on the initializer in the EventEmitter in place of a more idiomatic check when the method is invoked.
It aims to solve an internal error and promotes best practices for the iOS platform.
## Changelog:
[iOS][Changed] Refactor RCTEventEmitter initialization
Reviewed By: sammy-SC
Differential Revision: D40762253
fbshipit-source-id: 83d26616ce147914948e536e9e4b1010758fb690
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35163
# What
This diff contains all the changes from D40333083 (0fac9817df) (aka https://github.com/facebook/react-native/pull/34964), **except** the change to `setUpReactDevTools.js`, which actually uses the new files.
# Why
* We want to ship the Buck, C++, etc. changes before the JavaScript changes that depend on those files.
* Otherwise, apps can fail at startup with the message:
```
`TurboModuleRegistry.getEnforcing(...): '${name}' could not be found. ` +
'Verify that a module by this name is registered in the native binary.',
```
* Note that this only occurs if you are using a previously-built version of the C++, Obj C, etc. files in RN, but a more recent version of the JavaScript files. If you are building from matching sources, this does not occur.
* After a few days, we can land the JS files.
## Changelog
Changelog
[General][Added] Add, but don't use, DevTools Settings Manager.
Reviewed By: NickGerleman
Differential Revision: D40873390
fbshipit-source-id: c7bac6ae65f85666b8616443db278ebb175b691b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35123
**Context**
On RN Desktop, images can be copy/pasted into text inputs.
When copy/pasting local files w/ semi-colons in the filename (`/downloads/devices:pre-call-IMG_346C38284B2B-1.jpeg`), RN would throw this error.
{F785684529}
The error was due to no having the correct asset loader due to the local file path being parsed incorrectly.
To parse the url, we convert the string URI to a `NSURL` using a custom convertor fn.
The conversion was matching any `:` and assuming it was a network url scheme:
https://www.internalfb.com/code/archon_react_native_macos/[fde4113acd89fb13ee11636c48b59eac49c21bae]/React/Base/RCTConvert.m?lines=97-111
When an image path with `:` in the name was passed to this, it was assuming it was a valid network url and not file path.
Because this is a local filepath, the image path needs to be a filesystem url. Since this was parsed as network url, it did not have the `file://` prefix and would not pass this check, causing the loader to throw.l
https://www.internalfb.com/code/fbsource/%5B60d9d5e67383%5D/xplat/js/react-native-github/Libraries/Image/RCTImageLoader.mm?lines=220-230
## Changelog
[iOS] [Added] - Add support for parsing files w/ `:` in filename
Reviewed By: christophpurrer, philIip
Differential Revision: D40729963
fbshipit-source-id: 2f3adcabc8f0f1f22cbfca69c3484e72b1d93d25
Summary:
D38121921 (5ddb9977e6) added a grid accessibilityRole to Flow typings and RNTester example shared with iOS. It it forwarded on Android, but doesn't have an equivalent UIAccessibilityTrait mapping.`RNTesterSnapshotTests/testScrollViewExample` reports an error:
```
Failure: RedBox errors: (
"Error setting property 'accessibilityRole' of RCTScrollView with tag #125: Invalid UIAccessibilityTraits 'grid'. should be one of: (
adjustable,
====================== 38 lines skipped ======================
) (NSInternalInconsistencyException)
Path: <unknown>
Line: 0
```
This adds the grid mapping, which I think should fix this error.
Changelog:
[ios][Fixed] - Map `accessibilityRole: grid` to `UIAccessibilityTraitNone`
Reviewed By: christophpurrer
Differential Revision: D40848904
fbshipit-source-id: 80f72bcd4e4826cc0d535693117a6c1e5fbd1d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35117
This mimics some behavior we have in Android that allow uesers to turn on selectively TM and Fabric.
Notice that if fabric is enabled, TM must be enabled as well, otherwise the app won't work
## Changelog
[iOS][Added] - Added the possibility to selectively enable TM and Fabric with the new Architecture
Reviewed By: cortinico
Differential Revision: D40794328
fbshipit-source-id: b7fc7bb819d05566dcd335832cab224f80b23346
Summary:
Currently, RCTBlobManager (the native module for Blob support) cannot be loaded on iOS when the new architecture is enabled.
## Changelog
[General] [Added] - `BlobModule` to `RCTCoreModulesClassProvider`
Pull Request resolved: https://github.com/facebook/react-native/pull/35047
Test Plan:
The snippet below can be used to test Blob support with the new architecture enabled.
```
// App.tsx
import { useEffect } from 'react';
import { View } from 'react-native';
function uriToBlob(uri: any) {
return new Promise((resolve, reject) => {
const xhr = new XMLHttpRequest();
xhr.responseType = 'blob';
xhr.onload = () => {
const blob = xhr.response;
resolve(blob);
};
xhr.onerror = err => {
reject(err);
};
xhr.open('GET', uri);
xhr.send();
});
}
export default function App() {
useEffect(() => {
uriToBlob('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png');
});
return <View />;
}
```
Related issue: https://github.com/facebook/react-native/issues/35042
Reviewed By: NickGerleman
Differential Revision: D40716048
Pulled By: cipolleschi
fbshipit-source-id: 17643d230fa7ea83baee363d137d51f87818baa8
Summary:
* Add a DevToolsSettingsManager, which has android and iOS variants, which uses a new TM (Android) or takes advantage of the Settings TM (iOS) to get/set console patch settings
* This is backed by either the existing Settings module (iOS) or a new Java TM, which uses the SharedPreferences AP
## Testing
Manual testing
## Changelog
[General] [Added] - Add DevToolsSettingsManager
Pull Request resolved: https://github.com/facebook/react-native/pull/34964
Test Plan: * Extensive manual testing
Reviewed By: NickGerleman
Differential Revision: D40333083
Pulled By: rbalicki2
fbshipit-source-id: f3816e3bd7dea3086f6f2269c3a099af14aebb3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35064
Original commit changeset: 0fb0db845c04
Original Phabricator Diff: D40610875 (d941940b4c)
Open source is using BUCK 1 which does not seem to have the `oncall` directive.
Backing it out because it is breaking the external CI.
## Changelog
[internal]
Reviewed By: cortinico
Differential Revision: D40635873
fbshipit-source-id: 79ebd4db0972520fcca6ccb8c1725657a8ef7949
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
Changelog:
[Internal][ErrorHandling] 3/n Add a gate for parsing unhandled JS errors in C++
Gate this just in case it causes issues. Enabling this is definitely a better behavior than before, because we want the JS stack when there is a JS error, not the native stack.
Reviewed By: sammy-SC
Differential Revision: D40397393
fbshipit-source-id: 586b4d7bcf710edb048b5c643646ba2f3c4c302a
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary: Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268252
fbshipit-source-id: 9211add120448e95f892d36a85583c700b2ec9a0
Summary:
Changelog: [iOS][Internal] - Get the "move across" pointer event test passing on iOS
After implementing the "MoveAcross" pointer event test it indicated that the implementation, at least on iOS, was firing the events in an incorrect order. Extrapolating from the test's expectations all the events related to entering/leaving/ect. should fire before the down/move/up instead of placing those down/move/up/ect. between the leave and enter events.
Reviewed By: lunaleaps
Differential Revision: D39221372
fbshipit-source-id: 31b7292e524a9ec9d998e658b7d0ef3ebc825d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
A follow up to D38708718 (403fea25f6) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
Summary:
Brings in line with rest of code base and avoids running into this error
```
‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
```
when `Requires Only App-Extension-Safe-API` is set to Yes.
## Changelog
[iOS] [Fixed] - Update usage of UIApplication.sharedApplication in RCTKeyCommands
Pull Request resolved: https://github.com/facebook/react-native/pull/34787
Test Plan: Setting `Requires Only App-Extension-Safe-API` to Yes before this change means the app will not compile, after the change it does.
Reviewed By: dmytrorykun
Differential Revision: D39812410
Pulled By: cipolleschi
fbshipit-source-id: 78d185ba20301b10609e4a387f000f0cfda55663
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Currently, fbios link groups depend on supermodules to generate. To continue supporting
link groups while allowing us to migrate off supermodules, we'll add a `fbios_link_group` label on all fbios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D39543862
fbshipit-source-id: 2abe5b3ee883e77336076d88436a1c84139b5a97
Summary:
This behaviour diverges from the original SafeAreaView implementation and causes issues when you try to use SafeAreaView in non-root placements (not recommended)
Changelog: [iOS][Internal]
Reviewed By: sammy-SC
Differential Revision: D39497303
fbshipit-source-id: 03bc288557f611bd4a8c16b3a6df8887e89ee9ec