Summary:
This diff should not change any behaviour.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399000
fbshipit-source-id: 976f5740c53d58ceead7d2bc4c9e0eb3f97ebb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42215
This diff should not change any behaviour.
**Why:** This logic is only used once from the UIConstantsProviderManager. So, let's just inline it. Inlining this method will make ReactInstance.java have fewer private methods, which'll make ReactInstance.java easier to read.
**Concern:** Inlining this method into ReactInstance's constructor will make the constructor too hard to read.
- I think it'll be fine: we will simplify this method significantly in D52399003.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399002
fbshipit-source-id: 8c0dc69af86109da8144546347eecd2e01c0e0be
Summary:
When a FlatList is in side a scroll view (think Netflix style navigation), the DPAD up/down fires on the scroll view, despite scrollEnabled={false} being set. This additiontially conflicts with any custom scroll event that has been created.
## Changelog:
[Android] [Fixed] - fix: prevent scroll event in nested scroll when scrollEnabled={false}
Pull Request resolved: https://github.com/facebook/react-native/pull/42219
Test Plan:
I tested this by making a ScrollView with FlatList of opposite scrolling direction inside with basic card layouts.
Both had scrollEnabled={false}
I scrolled the ScrollView myself as it has multiple rows using:
```
const scrollToItem = React.useCallback(
(itemIndex: number): void => {
const targetScrollY = itemIndex * height
scrollViewRef.current?.scrollTo({ y: targetScrollY, animated: true })
},
[height]
)
React.useEffect(() => {
// Row 0, is global nav, but it's also the first row of cards
// when we scroll to "1" what we mean is global nav is hidden
// we should still be showing the first row of items.
scrollToItem(rowIndex <= 1 ? 0 : rowIndex - 1)
}, [rowIndex, scrollToItem])
```
Reviewed By: NickGerleman
Differential Revision: D52642168
Pulled By: mdvacca
fbshipit-source-id: 9305bc56ba6b03b04b9f69a14d433593cab2025e
Summary:
`compose-source-maps.js` fails if `-o` is not specified when it should output the composed source map.
## Changelog:
[GENERAL] [FIXED] - Fix `compose-source-maps.js` failing if `-o` is not specified when it should output the composed source map
Pull Request resolved: https://github.com/facebook/react-native/pull/42203
Test Plan:
Tested this in an internal repo. This was the output before this fix:
```
% node node_modules/react-native/scripts/compose-source-maps.js dist/main.jsbundle.map dist/main.jsbundle.hbc.map
node:internal/streams/writable:472
throw new ERR_INVALID_ARG_TYPE(
^
TypeError [ERR_INVALID_ARG_TYPE]: The "chunk" argument must be of type string or an instance of Buffer or Uint8Array. Received undefined
at _write (node:internal/streams/writable:472:13)
at Writable.write (node:internal/streams/writable:494:10)
at Object.<anonymous> (/~/node_modules/.store/react-native-virtual-c8e66dddc1/node_modules/react-native/scripts/compose-source-maps.js:64:20)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
at node:internal/main/run_main_module:28:49 {
code: 'ERR_INVALID_ARG_TYPE'
}
Node.js v20.10.0
```
Reviewed By: christophpurrer
Differential Revision: D52650438
Pulled By: arushikesarwani94
fbshipit-source-id: b8f8f01fb6d843887d874a7283a1a6807c7762e7
Summary:
Dependency on `chalk` was introduced in https://github.com/facebook/react-native/pull/37510, but was never declared. In pnpm setups, the CLI fails to run because of this.
This needs to be picked to 0.73.
## Changelog:
[GENERAL] [FIXED] - Declare missing dependency `chalk`
Pull Request resolved: https://github.com/facebook/react-native/pull/42235
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D52660337
Pulled By: cortinico
fbshipit-source-id: 1cd45fcff72045c127773566a27103f1b38262b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42233
This diff removes the need for providing the `ios_folder` argument to `use_react_native`. We no longer do any manual path tranformations to get the iOS project root.
Instead we use `Pod::Config.instance.installation_root` which always points to the correct directory.
Changelog: [iOS][Breaking] - CocoaPods: remove the `ios_folder` argument from the `use_react_native` function.
Reviewed By: cipolleschi
Differential Revision: D52659429
fbshipit-source-id: 67c79cd9d74a0351ad2c242b74cbd48b6bd2dc94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42207
In open source, with the new architecture, layout animations are **always** enabled.
They cannot be disabled.
Therefore, when this UIManagerModule method is called with false, just report an error. That way, if layout animations were explicitly disabled on Android, the developer will know, when they try to enable the new architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52349297
fbshipit-source-id: 7969bd7294ce7369643004e5ff7e0c1ed4a59cd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41998
Now the error message propts people to turn on the interop layer.
And, it adds more details to the suggestion to use hasViewManager(viewManagerName).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52002909
fbshipit-source-id: 80ea60b4f6a5fe15d773bb1f3f41de5ce43d6652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42067
These methods should not be implemented in the new architecture.
The **only** code that called these UIManagerModule methods was the paper renderer. And the New Architecture should instead use the Fabric renderer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52345416
fbshipit-source-id: 76511aa97e5dfa938aca658af03fb43122547df1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41997
Many methods on PaperUIMangaer are iOS only.
Many methods on PaperUIManager are Android only.
This diff makes sure that BridgelessUIManager only exports Android methods on Android, and iOS methods on iOS.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52012876
fbshipit-source-id: 6527048083eae93577a58d4b77f0645fab84217f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42200
Changelog: [Internal]
Quick hack to make it easy to determine whether a given build of React Native is using the C++ implementation of InspectorPackagerConnection or the legacy platform-specific implementation.
For now, we just append this information to the `title` field. Ultimately, rather than polluting the title, this should be an inert capability flag that gets reported via `inspector-proxy`. I'm not doing that yet since we have work in the pipeline to set up a proper capability flag system soon.
Reviewed By: huntie
Differential Revision: D52629415
fbshipit-source-id: a4e873f4be78ae49b35b94fd5d41d0e2efc02dbe
Summary:
PR https://github.com/facebook/react-native/pull/42159 was working but it was the wrong fix.
The right fix is to use the `"PUBLIC_HEADERS_FOLDER_PATH"` Xcode build setting instead.
bypass-github-export-checks
## Changelog:
[iOS][Changed] - Revert "Update Yoga.podspec: fixes archiving for macos catalyst on react-native 0.73.1 in xcode"
## Facebook:
Original commit changeset: 21b9b3568986
Original Phabricator Diff: D52624342
Reviewed By: arushikesarwani94
Differential Revision: D52656133
fbshipit-source-id: 84a37fe3fca57d5e34139c17c6c1957fe8d40aaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42165
This will help avoid a name collision when we remove the new suffix from newGetOrCreateReactInstanceTask.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D52495532
fbshipit-source-id: 79a04cff51eef07b91876a1351b8444654a79274
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42187
Updates the docblocks for `Pressability` and `usePressability`, as suggested in the code review for {D52388699}.
Changelog:
[General][Changed] Updated Pressability/usePressability Docblocks
Reviewed By: sammy-SC
Differential Revision: D52604388
fbshipit-source-id: e82dd6caa46fe69281e996cbdb8b8e5105b46955
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42194
Apps that have multiple concurrently running React instances may suffer from issues where tearing down one instance affects the bindings / LongLivedObjectCollection instance of another due to the use of static getter for LongLivedObjectCollection. This should allow host platforms, e.g., react-native-windows (which still forks the TurboModuleBinding C++ files [here](https://github.com/microsoft/react-native-windows/tree/main/vnext/ReactCommon/TEMP_UntilReactCommonUpdate/react/nativemodule/core/ReactCommon) for the reasons already mentioned) to manage per instance LongLivedObjectCollections.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52581170
fbshipit-source-id: 791e3baeefaf23f544eeddd5a216735535523a9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42037
Creates an Objective-C wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native iOS apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `RCTInspectorPackagerConnection` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52225495
fbshipit-source-id: f1b9657ef0d665cf7892c15c34c5104e2777ec43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42018
Creates an JNI wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native Android apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `InspectorPackagerConnection.java` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52231237
fbshipit-source-id: 5a0e3bd8b2b711c1c592db15c51df4c3cc89aaad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42197
Some std::ranges functions don't work well (or at all) when using
clang, eg see
https://fb.workplace.com/groups/474291069286180/posts/9724112847637243
This works in clang 16, but not clang 15 which fbcode is on. Note that more complicated parts of ranges work, but not these simpler helpers, funnily enough :).
As I'm trying to make RN compile in fbcode, I need clang to work.
Moving them back to iterators, but using rbegin/rend making it fairly readable still.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52481786
fbshipit-source-id: f37d4e1912b33eee392061dc787afaacd9554409
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
This PR tries to fix a build error when `import <React/RCTAppSetupUtils.h>` from *.m files. Since the `[[deprecated("")]]` syntax is a C++14 feature and it was placed inside the `RCT_EXTERN_C_BEGIN` block. If the file in imported from Objective-C *.m files or Swift files, it will have a syntax error. Instead of using the C++ syntax, this PR uses the `__deprecated_msg()` statement that is also used in other code in react-native and that is C supported syntax.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix RCTAppSetupPrepareApp.h import error from Objective-C *.m files
Pull Request resolved: https://github.com/facebook/react-native/pull/42172
Test Plan:
- test building and importing **RCTAppSetupPrepareApp.h** from a *.m file
- test `RCTAppSetupPrepareApp(application, turboModuleEnabled)` will show a compile warning
Reviewed By: arushikesarwani94
Differential Revision: D52603421
Pulled By: cipolleschi
fbshipit-source-id: bfec8d0ba6378a265ad30dd8ca1d3ab15cff96ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42191
X-link: https://github.com/facebook/yoga/pull/1539
React native supports transforms and if a node has a transform it will [form a containing block for absolute descendants regardless of position type](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block). So we need to pass that information into Yoga to ensure this happens.
The verbiage for the field "alwaysFormsContainingBlock" is very specific. In a vacuum a node cannot simply "form a containing block". It only forms a containing block in reference to a different node. This can be illustrated in a scenario where we have a static node that is a flex container which has 1 absolute child and 1 relative child. This static node will form a containing block for the relative child but not the absolute one. We could just pass the information on rather something has a transform or not but Yoga is not supposed to know about transforms in general. As a result we have a notion of "always" forming a containing block. Since Yoga is a flexbox spec, non-absolute nodes' containing blocks will ways be their parent. If we add something like a transform to a node then that will also apply to absolute nodes - hence we can say the node will **always** form a CB, no matter who is the descendant.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52521160
fbshipit-source-id: bab9319ffddec617f5281823930f2a00cc2967f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42190
Essentially undoing D51182861 that was put in place to support adding a default position type to Fabric. Previously I had already removed the code that set the default to something other than Yoga default, but I did not remove all this extra code that allows you to do that. Since we no longer need this we should remove it so as not to encourage messing with the defaults in such a way that they differ from Yoga defaults.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515993
fbshipit-source-id: fb4ab726cf73bf08fd6aa44b99196962a9839694
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42189
tsia, we had the equality op defaulted so might as well do this for inequality
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515802
fbshipit-source-id: ce31a00eddda991221c91364508fed6df78fd5b4
Summary:
Adds changelog for the 0.73.2 release.
## 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
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.73.2 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/42186
Test Plan: Read the changelog 🤞
Reviewed By: huntie
Differential Revision: D52604441
Pulled By: lunaleaps
fbshipit-source-id: 3d67da6d8ff1e3afe9a875bd38eb851fc28cd7ac
Summary:
In my mac, I use a case-sensitive volume and when I build a react-native 0.73 project it failed with an error that can't find the hermes release tarball to extract:
```
Node found at: /usr/local/bin/node
Preparing the final location
Extracting the tarball
tar: Error opening archive: Failed to open '/Volumes/Workspace/meet-art-link/ios/Pods/hermes-engine-artifacts/hermes-ios-0.73.1-Release.tar.gz'
```
Note the `...-Release.tar.gz` in the error. In the disk it's `...-release.tar.gz`.
The build fails in after download the release tarball in release mode because the hermes tarball name in the `replace_hermes_version.js` build script is capitalized, while the file is lowercase on disk.
The fix is to ensure the hermes tarball name's "build type" is lowercase just like the function that creates the tarballs in react-native release located in `hermes_utils.js` in `getHermesPrebuiltArtifactsTarballName()`.
Perhaps it's better to retrieve the tarball name from the same method it's generated? E.g.:
```js
const { getHermesPrebuiltArtifactsTarballName } = require('react-native/scripts/hermes/hermes-utils');
const tarballName = getHermesPrebuiltArtifactsTarballName(`${version}-${configuration}`);
const tarballURLPath = `${podsRoot}/hermes-engine-artifacts/${tarballName}`;
```
If yes, let me know to update the PR.
## 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
-->
[iOS][Fixed] - Fix release build error due to a casing issue in hermes tarball path after download prebuilt tarball
Pull Request resolved: https://github.com/facebook/react-native/pull/42160
Test Plan: Use a case sensitive volume or system and build react-native 0.73 in release mode, it will fail. Apply the patch in this PR and it will work fine.
Reviewed By: cortinico
Differential Revision: D52603439
Pulled By: cipolleschi
fbshipit-source-id: 41ed8d8202874f338e4aa3af88d9d28ec1b8b3d5
Summary:
Closes https://github.com/facebook/react-native/issues/42164
## Changelog:
[IOS] [FIXED] - Fixes `with-environment.sh` script for the case when Node can't be found prior to loading `.xcode.env`
Pull Request resolved: https://github.com/facebook/react-native/pull/42184
Test Plan: This is a trivial update, no need for much testing.
Reviewed By: cortinico
Differential Revision: D52602653
Pulled By: cipolleschi
fbshipit-source-id: 0881456bf165d895252ae38cb7c7aee945cfaf52
Summary:
Currently our CI will auto-tag any `npm publish` as `latest` for the monorepo packages. This is because [we do not specify a tag](https://github.com/facebook/react-native/blob/main/scripts/monorepo/find-and-publish-all-bumped-packages.js#L104), so npm will [default to `latest`](https://docs.npmjs.com/cli/v10/commands/npm-dist-tag#description). We encountered a similar issue for `react-native` awhile ago and fixed that with [always specifying a tag](https://github.com/facebook/react-native/blob/main/scripts/npm-utils.js#L84), with the explicit opt-in for `latest`.
yarn and npm will resolve `*` dependencies using `latest`. This will be a problem for any React Native version that uses `*` deps. We have actively tried to remove these `*` versions but older patches may still contain them.
When we do a monorepo package bump, it may be for 0.71 and for a user who is initializing a 0.72 version project (that still has * deps), they will receive monorepo packages of version `0.71.x`, which is not compatible. (React Native monorepo packages do not faithfully follow semver)
This change allows us to specify what tags to use and suggest tags based on what branch you are on and asks for confirmation
```
> branch 0.73-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.73-stable"
◉ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.73-stable","latest" (Y/n)
> branch 0.72-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.72-stable"
◯ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.72-stable" (Y/n)
> branch main
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "nightly"
? Confirm these tags for *ALL* packages being bumped: "nightly" (Y/n)
```
## Changelog:
[INTERNAL] [CHANGED] - Support dist-tags in publishing monorepo packages to avoid default "latest" tag.
Pull Request resolved: https://github.com/facebook/react-native/pull/42146
Test Plan: `yarn test scripts/`
Reviewed By: NickGerleman
Differential Revision: D52551769
Pulled By: lunaleaps
fbshipit-source-id: 52f923464387cffdc6ca22c6f0a45425965a3680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42158
Changelog: [Internal]
* Ports an existing Java/ObjC InspectorPackagerConnection behaviour to the C++ implementation: socket errors should trigger a reconnection. This was a simple omission in D52134592.
* Clarifies the relationship between the `didFailWithError` and `didClose` methods on `IWebSocketDelegate`: calling either one will terminate the connection (and trigger a reconnection), and it's legal to call `didClose` after `didFailWithError`.
* I'm also adding logic to ensure we don't double-schedule reconnections if both methods are called.
* Cleans up the scaffolding comments from D52134592
Reviewed By: huntie
Differential Revision: D52576727
fbshipit-source-id: 07e5a5c36222dc7bede8bcb17a1f3ced2788736b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42118
JFrog CDN periodically gives us headaches when downloading boost.
this change moves from JFrog to the official CDN by boost.
## Changelog
[Internal] - Download boost directly from boost archives
Reviewed By: cortinico
Differential Revision: D52479171
fbshipit-source-id: a53a9cb2ea6dfdf2b82b3c8e69c697b24cc40cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42156
changelog: [internal]
Add a missing nullptr check to prevent crash if called after component was reused
Reviewed By: fkgozali
Differential Revision: D52572807
fbshipit-source-id: 1b5b26996e562abbcb986865299e02df20b58043
Summary:
https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8 deprecated some of the methods in `RCTBundleURLProvider, and is part of React Native version 0.73. Let's remove the deprecated options for React Native 0.74+
bypass-github-export-checks
## Changelog:
[IOS] [REMOVED] - Remove deprecated RCTBundleURLProvider options
Pull Request resolved: https://github.com/facebook/react-native/pull/42114
Test Plan: CI should pass.
Reviewed By: huntie
Differential Revision: D52537732
Pulled By: cipolleschi
fbshipit-source-id: ea5d17c7c66a60bceb2a12f2e17e39be4c56d422
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42022
Some tests to ensure that the order of nodes is correct as defiend by order index that is derived from zIndex + positioning. These tests do not ensure that the native platform then goes and lays them out correctly. That will be done later with e2e tests on catalyst
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52295063
fbshipit-source-id: 8ae29fc50ad65db8e5c0ab28a132546d8489dffe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42021
# Context
A while ago D48905010 was committed that set the CALayer's zPosition equal to the zIndex passed in via props. This was to avoid an issue like: https://pxl.cl/40F72
where the rotating view would clip into the background.
There are a few issues here.
* The current zIndex code is designed to be cross platform on the C++ layer and not the native layer. This diverges from the Android behavior and adds a special case for this platform when we have the ability to share all of this logic
* Static nodes will apply a zIndex when they shouldn't. This code pre-empts the static check [here](https://www.internalfb.com/code/fbsource/[cf8ad268b4cf]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/components/view/ConcreteViewShadowNode.h?lines=98) that zeroes out the "order index" for static nodes
* As a result of the above, static nodes can eclipse their children which should never happen because static nodes ignore zIndex values
# Reason for the clipping
The reason this clipping is happening is because the red/blue views share the same stacking context as the white background (as indicated by the vertical black line). {F1175070418}
This in combination with the fact that our zIndex implementation will NOT set iOS's zPosition means that these three views (red view, blue view, white background view) all have the same zPosition (0) and will be laid out in the order described by the orderIndex mentioned earlier. This index essentially just changes the document order that is used for tiebreakers when zPosition is tied.
So, all the views are on the same stacking context and they all have no zPosition set. Add the rotation that the colored views are doing and you get this clipping. Apple will change the "zPosition" in a sense for the parts of the view that should be perceived as "further away" due to the rotation. So, we clip into our background which has a lower order index but the same zPosition.
# This change
The fix here just makes it so that the rotating views are not on the same stacking context as the background so the changing zPosition from the rotation does not matter. This can be achieved by setting the zIndex of the container to any number (among other things). Note that this is only the case because the default position type is relative in this stack. Otherwise you would also need to set the position type as well. Now the stacking context looks like: {F1175083828} and the problem is solved!
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52181701
fbshipit-source-id: 580f860273b9c8470181d92d7ad542546664ed77
Ramanpreet Nara
Ryan Wilson
Tommy Nguyen
Paul Schreiber
Dmitry Rykun
Moti Zilberman
zhongwuzw
Alex Hunt
Riccardo Cipolleschi
Tim Yung
Eric Rozell
Luna
Samuel Susla
Kesha Antonov
Alexander Blom
Kudo Chien
Joe Vilches
fortmarek
William Fernandes
Dr. Sergey Pogodin
Luna Wei
Saad Najmi