Summary:
Reverts {D41122065 (1b1b26a099)}, which is no longer necessary because {D41208895 (7cf4cf3afb)} fixed the `ref` invalidation in `ScrollView`.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41390543
fbshipit-source-id: 36c3db80af6e426f233ef0aaf5909942fb7103b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35431
`[ -f "$source" ]` was wrong.
`man test` reads:
> -f file True if file exists and is a regular file.
-e file True if file exists (regardless of type).
hermes.framework is not a regular file but a directory. `-e` is beter here.
Also intermediate destiantion directories are now created if they didn't exist.
Changelog:
[iOS][Fixed] - Make copy-hermes-xcode.sh more reliable.
Reviewed By: robhogan
Differential Revision: D41472846
fbshipit-source-id: 87de0b48d178ca542299b8e5fa741fdc0570d4e2
Summary:
X-link: https://github.com/facebook/yoga/pull/1176
`Values` is a wrapper to story an array of YGValue's as CompactValues.
From https://github.com/facebook/yoga/issues/1174 we see a warning `Wdeprecated-copy` beacuse a user-defined copy constructor is not present, but a user-defined asignment operator is (the defaulted one). This adds an explicitly defaulted copy contructor which should silence the warning I think.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41447490
fbshipit-source-id: 8cc8f291cf12014d87cc71c4598bb84fdd6cd930
Summary:
In this diff I'm refactoring ViewGroupManager to implement IViewGroupManager
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386918
fbshipit-source-id: 427b9689eb3408c2477cf38494d42280b41fd7d8
Summary:
In this diff I'm introducing IViewGroupManager to extract methods required to add/remove views from a viewGroup
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386920
fbshipit-source-id: a7d893d92d0f12766dcc71dfd1b22539c3b9687d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35392
Changelog:
[General][Added] - For supporting Dev Loading View across platforms, adding the DevLoadingViewController without an activity/context.
Reviewed By: rshest
Differential Revision: D40947239
fbshipit-source-id: de124b0a7ee39dc7da3c1c45972a6703eff2f0ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35385
In OpenSource builds folly:: types are not always easy to consume.
With butter:: we actually allow consumers to opt-into other/non folly:: types (by providing a custom butter:: implementation).
This change adds a butter::function for that purpose.
It is especially useful for react-native-windows which prefers Mso::Functor over folly::Function.
You can use it by setting those compiler flags:
-DBUTTER_FUNCTION_OVERRIDE_INCLUDE=<functional/functor.h>
-DBUTTER_FUNCTION_OVERRIDE=Mso::Functor
std::function is no option as it is not move-only and we can't wait till 2025 > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0288r9.html
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41388193
fbshipit-source-id: 56f58b9ddc602aa4b13000031d50de5228b4a16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
changelog:
[General][Add] LogBox now makes URL links tappable.
Logbox messages may contain URLs with more information about the given error. Right now, they are not tappable or copyable. So engineers need to resort to manually retype the link to browser. This diff tries to address that.
Example of StrictMode error that has link in it.
{F798509909}
Reviewed By: yungsters
Differential Revision: D41305784
fbshipit-source-id: 456a9faf34f8b9e443759dd6903ba67d0b9de73c
Summary:
This PR makes sure that the `preapre_package_for_release` script fail fast if there is already a tag for the desired version
on github.
## Changelog
[General] [Added] - Make the `prepare_package_for_release` fail if there is already a git tag with that version
Pull Request resolved: https://github.com/facebook/react-native/pull/35305
Test Plan:
Tested manually. The script is currently only invoked during the release process.
<img width="1238" alt="Screenshot 2022-11-10 at 12 24 03" src="https://user-images.githubusercontent.com/11162307/201090947-274c1b1c-0b6a-4619-bc85-fa60e5eaeee1.png">
Reviewed By: cortinico
Differential Revision: D41403159
Pulled By: cipolleschi
fbshipit-source-id: fb87df345b14568c750482e5c68be53551a9acbb
Summary:
Original title: **[RN] Do not encode path to cmake in hermes-engine Pod, build hermesc in prepare_pods**
The result of `#{%x(command -v cmake | tr -d '\n')}` was being encoded into the `hermes-engine` Pod. This can lead to conflicts in the CocoaPods cache when `pod install` is run on different machines.
Instead of running the command during `pod install`, we defer to the actual build scripts so they can find `cmake` when `$CMAKE_BINARY` is not set.
More importantly, this fixes an issue that crept into the Sandcastle CocoaPods offline mirrors, but which would only manifest itself when people run `js1 oss prepare-pods`.
RNTester would not build due to RNTesterPods.xcworkspace being configured to use cmake from an arbitrary path instead of using the cmake from $PATH.
This does not affect Sandcastle due to `CMAKE_BINARY` getting overriden in Sandcastle.
---
**Update** by dmytrorykun:
It is impossible to address the problem described in the original title by simply adding `CMAKE_BINARY=${CMAKE_BINARY:-cmake}` to `build-hermes-xcode.sh`. This script is supposed to run from Xcode. Since Xcode doesn't have access to system `PATH` variable, it is unable to locate `cmake`, and build fails.
However this diff contains other useful changes:
1. Remove trailing newline in `cmake` path in `build-hermes-xcode.sh`.
2. Fix inverted logic in `copy-hermes-xcode.sh`.
3. Fix typo in `remove xcuserdata` step in Sandcastle.
4. Remove unused `HERMES_DISABLE_HERMESC_BUILD`.
Changelog:
[iOS] [Fixed] - Various fixes for Hermes build-from-source behaviour.
Reviewed By: cipolleschi
Differential Revision: D41139384
fbshipit-source-id: 4a4a44a7ac201d279718d84cd02d60b4eaf3956b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
## Changelog:
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
Summary:
The order of following calls is irrelevant.
```
__update_pods_and_offline_mirrors "$JS_ENGINE_JSC"
__update_pods_and_offline_mirrors "$JS_ENGINE_HERMES"
```
If execute `__update_pods_and_offline_mirrors "$JS_ENGINE_HERMES"` last, then `prepare_pods "$JS_ENGINE_HERMES"` is redundant.
allow-large-files
Changelog:
[Internal][Changed] - Cleanup offline pod mirrors updating behaviour.
Reviewed By: cipolleschi
Differential Revision: D41346899
fbshipit-source-id: 694713330fb94561d872883a18f97869cd30cd26
Summary:
Investigating [this comment](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4170008), I made some tests.
It seems like we can simply use `#import <RCTAppDelegate.h>` instead of the `#import <React-RCTAppDelegate/RCTAppDelegate.h>` in both setups:
- default setup
- `use_frameworks! :linkage => :static`
## Changelog
[iOS] [Fixed] - Support `use_framework! :linkage => :static` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35394
Test Plan:
1. Manually tested with a new app
2. CircleCI
3. Sandcastle
Reviewed By: cortinico
Differential Revision: D41402060
Pulled By: cipolleschi
fbshipit-source-id: e1ed8196ed860b3663a88f5283f2745e39b0e944
Summary:
Changelog:
[iOS][Changed] - Abort pod install if bad HERMES_ENGINE_TARBALL_PATH is set.
Reviewed By: cipolleschi
Differential Revision: D41341471
fbshipit-source-id: 34a3ac154b0a3f795d07dcd10f92361cb9bb4ad6
Summary:
The template has moved to typescript now, the self-reference needed an update
## 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
-->
[GENERAL] [FIXED] - reference App.tsx vs App.js in text of new typescript template
Pull Request resolved: https://github.com/facebook/react-native/pull/35377
Test Plan: It is just a text change - it either makes sense or it doesn't. I think it makes sense?
Reviewed By: cipolleschi
Differential Revision: D41386912
Pulled By: NickGerleman
fbshipit-source-id: 6e62c11567e8fbff70b123446a827b18af43e864
Summary:
The commit 3eddc9abb7 included on v0.69 introduced a wrong `if` statement inside the `componentDidUpdate` function of the `TouchableOpacity` component. As this `if` statement always evaluates to `true` (`(true || false) !== undefined`) we end up making unnecessary calls to the `_opacityInactive` method every time the component props changes, e.g. every time a `<Text>` inside the TouchableOpacity changes we call this function over and over, and this has been causing some performance issues on big lists.
This PR fixes this problem by adjusting the `componentDidUpdate` function to only call `_opacityInactive` when necessary.
Closes https://github.com/facebook/react-native/issues/34442
Closes https://github.com/facebook/react-native/issues/32476
## Changelog
[General] [Fixed] - Fix TouchableOpacity componentDidUpdate causing an excessive number of pending callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/35387
Test Plan:
1. Open the RNTester app and navigate to the `Touchable* and onPress` page
2. Test the `TouchableOpacity` component through the many sections
Reviewed By: cipolleschi
Differential Revision: D41397396
Pulled By: ryancat
fbshipit-source-id: 24863b5cbbdd2f3dd1f654b43d7031560937b888
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:
- Untrack Test Reports generated by test libraries (reporters E.g. `jest-junit`)
- E.g. `/reports/junit/js-test-results.xml` report is generated; when we exec `yarn test-ci`, which is **_shouldn't_ be tracked**
### NOTE: Used `[skip ci]` to avoid wastage of compute resources �🌏
- Feel free to init tests manually if you find it necessary
## 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
-->
[GENERAL] [CHANGED] - Untrack Test Reports generated by test libraries (reporters E.g. `jest-junit`)
Pull Request resolved: https://github.com/facebook/react-native/pull/35187
Test Plan:
`yarn test-ci`
Reviewed By: cipolleschi
Differential Revision: D40993282
Pulled By: sshic
fbshipit-source-id: 3fe150d3e8bd45cec56b50f2dc071002412e475e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35379
This diff moves the publishing coordinates from:
```
com.facebook.react:react-native
com.facebook.react:hermes-engine
```
to
```
com.facebook.react:react-android
com.facebook.react:hermes-android
```
I've picked those they are the most layout friendly when building from source, but we can discuss if we want others.
I've updated the Gradle plugin to have a dependencySubstitution rule + update the template with those changes.
It should now be possible to still use `implementation("com.facebook.react:react-native:+")` inside libraries
on 0.71+ and RNGP will resolve dependencies correctly.
Changelog:
[Android] [Changed] - Void the Maven coordinates for react-native and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D41380525
fbshipit-source-id: 91e059fa261acb89bee7ca0c79c30c3d856a2c80
Summary:
From exception logging, found crashes due to `Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference`. Tracing through the stack, it appears the constructor for `ViewGroup` conditionally calls `initializeScrollbarsInternal()`, which in turn calls `getChildCount()`. However `ReactModalHostView` overrides `getChildCount()`, so `getChildCount()` is called before `ReactModalHostView` constructor completes, resulting in null reference when accessing `mHostView` from `getChildCount()`.
## 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
-->
[Android] [Fixed] - Fix crash on initialize modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35380
Test Plan: In the rn-tester project, display a modal.
Reviewed By: javache, cipolleschi
Differential Revision: D41392235
Pulled By: ryancat
fbshipit-source-id: ce78e4d458ad41769e78139ea0a8a038384e830d
Summary:
This allows folks with a monorepo setup for React Native to set a simple configuration on the "Bundle React Native code and images" phase. This is because the bundler was configured to look for node_modules in a specific place, but in a monorepo your node_modules may be at the root one layer lower than a default configuration.
This same pattern of overriding this variable exists in the [react-native-xcode](https://github.com/facebook/react-native/blob/main/scripts/react-native-xcode.sh#L63) file.
Fixes: https://github.com/facebook/react-native/issues/33636 - "Unable to resolve module index"
```
Error: Unable to resolve module ./index from /Volumes/Nexus/Projects/xxx/.:
None of these files exist:
* index(.native|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
* index/index(.native|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
```
## Changelog
[General] [Added] - Add support for overriding `PROJECT_ROOT` during bundle steps for monorepos.
Pull Request resolved: https://github.com/facebook/react-native/pull/35354
Test Plan: Working CI build via CircleCI.
Reviewed By: cipolleschi
Differential Revision: D41319439
Pulled By: ryancat
fbshipit-source-id: 8516e54436b0a9d4b9df1efeee8e62c95d4d35b2
Summary:
Changelog: [Internal]
I think this started to break when https://github.com/facebook/react/pull/25441 was synced to RN. Before, `closestInstance` would only be non-null under Fabric, after it could be non-null in both. And we were using `closestInstance` to determine which data to send to `selectNode` in devtools. This diff makes a change to call `selectNode` once for non-fabric and once for fabric, one of them would not send anything to devtools frontend, this would make sure it works for both platforms.
Reviewed By: mondaychen
Differential Revision: D41366466
fbshipit-source-id: fcf30d03e443f6fa067782cd31b7cfd2e0cd841e
Summary: Cleanup rn_defs. Most of the imports here were not related to RN, and for others we can use rn_apple_library instead.
Reviewed By: mdvacca
Differential Revision: D41302584
fbshipit-source-id: 0db79e202c0e18dd590ae0e6bf2821e6b49b606a
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) |
:-------------------------:|:-------------------------:
 | 
## 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:
Jscodeshift has become maintained again in the past year, and has gotten rid of quite a good chunk of old dependencies that are no longer needed!
## 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] - update jscodeshift
Pull Request resolved: https://github.com/facebook/react-native/pull/35356
Reviewed By: cipolleschi
Differential Revision: D41325527
Pulled By: rshest
fbshipit-source-id: 666b25c9bb3b1720479e9e098968b3b983adc2b4
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:
# What
* Pass the DevTools Settings Manager to connectToDevTools.
* This is an object that provides write and synchronized read access to on-device storage, that React DevTools will use during startup.
* This allows us to persist settings like whether to show component stacks on error, and on restart, behave correctly. In the future, this will be used to power the "restart and profile" flow.
Changelog
[General][Added] Pass DevTools Settings Manager to connectToDevTools
Reviewed By: lunaruan
Differential Revision: D40880260
fbshipit-source-id: 379a2c93b4cde0360e6fd380d837f426943bfa9e
Summary:
Fixes missing/incorrect devDependencies in a newly built app. The previous set did not pull in prettier, causing linting to fail. There was a peerDependency warning on yarn install. We also saw a separate lint warning at runtime specific to TS 4.9 being pulled in now, so we constrain in that version a bit.
Prettier and preset-env versions match the constraints and lockfiles of other RN packages.
## Changelog
[General] [Fixed] - Fixup template devDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/35372
Test Plan:
Created a new app targeting 0.71 via `react-native init`.
1. `yarn install --force` no longer shows warnings
2. `prettier` is installed, `yarn lint` no longer fails, and shows no warnings or errors
3. ~Tentatively a test step to add tests against linting in new app, but last time doing that in CircleCI led to timeouts with no output that I didn't have time to debug, so maybe that's fixed now? �♀️.~ (edit: still hangs)
Reviewed By: NickGerleman
Differential Revision: D41363021
Pulled By: lunaleaps
fbshipit-source-id: d6163b01e8934d75a231fa0fd849d7bde7b3500c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35353
Unfortunately we have 2 different definitions of SystraceSection.h
- xplat/js/react-native-github/ReactCommon/cxxreact/SystraceSection.h
- xplat/js/react-native-github/ReactCommon/react/renderer/debug/SystraceSection.h
The first one is the Old Arch one and the second one is the New Arch one.
As we first step, we unify the implementation
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D41307049
fbshipit-source-id: a9eb854dfcf49f87ad81fd9cc8dbe51648ecd209
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35342
This is a native implementation of the JS shimmed layout-specific properties in https://github.com/facebook/react-native/pull/35316.
There is an experiment splitting the prop splitting codepath in Fabric, so this change effectively has two implementations depending on whether `enablePropIteratorSetter` is enabled.
None of these changes make sense to propagate Yoga. `inlineEnd`, etc are already mapped to `YGEdgeStart` and `YGEdgeEnd`, but RN's mapping used a different name. Then `blockStart`, `blockEnd`, map directly to existing edges in all cases since we don't support a writing mode.
On web, the last value in the style which computes the given dimension is given precedence. E.g. if "left" comes after "start" it will be chosen. Yoga stylesheets are unordered, and precedence for edges is given based on specificity (left > start > horizontal > all).
We give precedence to new renamings (e.g. start to inlineStart), but to preserve consistent behavior, we give precedence to specific edges before overwriting them with flow relative ones (e.g. marginTop has precedence over marginBlockStar).
Changelog:
[General][Added] - Add Fabric implementation of flow-relative padding and margin
Reviewed By: javache
Differential Revision: D41267765
fbshipit-source-id: 896e2ed71fe8bf83aef00b0a9d70fd20b2ce47a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35369
Somwhere between importing https://github.com/facebook/react-native/pull/35017 and running `js1 oss update-pods`, the entire Podfile lock was deleted without me noticing. This change runs `js1 oss prepare-pods` to restore it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41343786
fbshipit-source-id: 79abe41b18b8e13b9fba70906b8301b002d0e3db
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:
This PR is a task of https://github.com/facebook/react-native/issues/34872
- combined `Flow` and `TS` `buildPropertySchema` fn 's into common fn
- added callback param `resolveTypeAnnotation` to the same
- moved it to `parsers-commons.js`
- re-organized imports and exports
## Changelog
[INTERNAL] [CHANGED] - [Codegen]: Refactored `buildPropertySchema` fn of (Flow, TS) into common fn in `parsers-commons.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/35288
Test Plan:
- ensure 👇 is `#00ff00`
```bash
yarn lint && yarn flow && yarn test-ci
```
Reviewed By: christophpurrer
Differential Revision: D41247738
Pulled By: cipolleschi
fbshipit-source-id: aecc0ed8d07efa1c2c39e8a8e64b4ee73b720b8f
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:
Cherry pick 19a62d9f57 to React Native. These style props were being applied to a <Text> element, not a <View> element. They seemingly only worked because of a quirk of iOS.
=== Original change notes ===
The issue with the test is that the react native Text component has its own props for shadows - i.e. [textShadowColor, textShadowRadius, etc](https://reactnative.dev/docs/text-style-props) and the shadow props that View uses does not work on Text (i.e. shadowColor, shadowRadius, etc.). Not entirely sure how this test was passing without any errors before my change, it seems like something about the change is causing (expected) errors to actually show up.
## 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] [Fixed] - Shadow consistency opacity fix with test updates
Pull Request resolved: https://github.com/facebook/react-native/pull/35360
Test Plan: Tested in our React Native macOS fork on iOS.
Reviewed By: cipolleschi
Differential Revision: D41335366
Pulled By: christophpurrer
fbshipit-source-id: f789b9565ed4e00fa558af8e418dd9e078064f98
Tim Yung
GabeDahl
Dmitry Rykun
matiassalles99
Rujin Cao
Nick Gerleman
David Vacca
Arushi Kesarwani
Christoph Purrer
Riccardo Cipolleschi
Pieter De Baets
Samuel Susla
Riccardo Cipolleschi
David Angulo
Mike Hardy
Gabriel Donadel Dall'Agnol
Phillip Pan
Richard Howell
Pranav Yadav
Nicola Corti
Alpha
Connor Tumbleson
Tianyu Yao
Nicolas Gallagher
Rafael
Stian Jensen
Robert Balicki
Nick Gerleman
Ellis Tsung
Saad Najmi
