Merge from upstream through 2020-07-17 #822
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: `js1 upgrade metro -v 0.60.0` in `fbsource/xplat/js`. Newest Metro release: https://github.com/facebook/metro/releases/tag/v0.60.0 Changelog: [Internal] Reviewed By: cpojer Differential Revision: D22331218 fbshipit-source-id: 000b7e995619a36ae6d0dfbdefbf40bfc849a1eb
Reviewed By: zertosh, bismarkito Differential Revision: D22330388 fbshipit-source-id: 7a86a05da23728ad066702d868d805769389893f
Summary: Changelog: [Internal] I had to update the types-first flags in the giuthub flowconfigs because they are removed in 0.128. I updated the snapshot test as well allow-large-files Reviewed By: mroch Differential Revision: D22336797 fbshipit-source-id: ebeb0c05479d2dac69a66645d042d5671453f5e8
Summary: In facebook@0b63c94, I shipped "Early ViewCommand Dispatch" everywhere but didn't provide a good summary in the commit message. Here it is: The "Early ViewCommand Dispatch" experiment was a success, leading to improved UI responsiveness and fewer overall crashes. Ship to all Fabric and non-Fabric users, and clean up the code a bit. # Context: what? ViewCommands are now used in React Native to do things like scroll ScrollViews to a certain position; focus or blur a TextInput; control the value of controlled TextInputs; and much more. These used to be done using setNativeProps, but we're moving everything to ViewCommands, and most of that migration has already finished. # Context: Why? Because Fabric does not support setNativeProps, there has been an effort to move all setNativeProps callsites to ViewCommands. Since these callsites are in JS where we can't tell if we're running in Paper or Fabric, both Paper and Fabric callsites are being migrated (mostly already done) to ViewCommands. One such example is Android TextInput, which has been using ViewCommands instead of setNativeProps for several months. This migration was largely without issues, except TheSavior and I noticed early on that certain things were just... slower with ViewCommands. It was definitely noticeable, but we determined it to be acceptable and moved on. Recently, it became clear to me that the perf regression may not be acceptable, but there might be an "easy" solution. # Why are ViewCommands slower than SetNativeProps? So, a couple things. SetNativeProps on Paper would actually cause a layout pass; the same is not true for ViewCommands, so they should actually be much faster. But they're not! The reason is that ViewCommands are treated as regular mount items, and they are queued up /after/ all other mount items. That means if you're trying to interact with the UI while some part of it is updating, your ViewCommands must wait for portions of the screen to finish rendering before they execute. In some cases, those views may even disappear before the ViewCommand executes, causing increased exceptions as well as speed degredations. # Proposal This experiment that ran with successful results was: to execute ViewCommands /before/ all other types of mount instructions (by maintaining a separate queue). That means if you tap on a TextInput to focus it while the screen is doing some heavy rendering, the next time the UIManager executes a batch of instructions, it will execute the focus operation out-of-order, at the very beginning. From a user perspective this is actually quite noticeable, and works much better than the older behavior. # Why it's Not That Dangerous * Is it possible that we'll execute instructions after the corresponding view has disappeared? This was already possible, and is actually less likely now, since it's more likely that the ViewCommand will execute before the Delete instructions executes. * Is it possible we'll execute instructions BEFORE the view is created? Yes, this is possible and I actually found a repro for it. My solution: allow ViewCommands to be retried, exactly once. If they throw an exception the first time, we requeue which will cause the command to be executed after the current batch of mount items. Interestingly, this seems to be unnecessary in Fabric, so the logic there is a bit simpler (probably because on Android we do view preallocation under Fabric, so views are created way before they're inserted into the view hierarchy, and apparently before ViewCommands have a chance to execute). * ViewCommands are already an imperative feature that exists outside of the normal React commit cycle. So they're already dangerous. This doesn't change that, but it does make dangerous code *faster*, so that's good. Changelog: [Android][Changed] ViewCommands on Android now execute earlier, as a perf optimization. Reviewed By: mdvacca Differential Revision: D22343648 fbshipit-source-id: 310d94977ac8ca3140ee8aa272272f660efafa36
Summary: JoshuaGross This issue fixes facebook#28279 as discussed in facebook#29157 (comment) Avoid calling [setHyphenationFrequency](https://developer.android.com/reference/android/widget/TextView#setHyphenationFrequency(int)) on Android Sdk < 23. ## 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 --> [Android] [Fixed] - do not call setHyphenationFrequency on AndroidSdk < 23 Pull Request resolved: facebook#29258 Test Plan: | **BEFORE** | **AFTER** | |:-------------------------:|:-------------------------:| | <img src="https://user-images.githubusercontent.com/24992535/86214122-05bf0e00-bb7b-11ea-93b5-2174812bfec9.png" width="300" height="" />| <img src="https://user-images.githubusercontent.com/24992535/86214130-08216800-bb7b-11ea-9fc0-68b28638bf57.png" width="300" height="" /> | The warning displayed with `adb logcat | grep -P "ReactTextAnchorViewManager"`  I remain available to do improvements. Thanks a lot. Fabrizio. Reviewed By: JoshuaGross Differential Revision: D22337095 Pulled By: mdvacca fbshipit-source-id: d0943397af180929c48044ccbc7a9388549021b8
Summary: This is the first implementation stage of on-demand child views mounting for <ScrollView> feature. It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area. Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling. This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22304012 fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary: Just gating. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22325692 fbshipit-source-id: 14cdfb4bf10ad00e090a91659138639360020fca
Summary:
Now we can use `overflowInset` to check if the view's descendants overflow.
```
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
A cell w/o overflow content
│ │
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
┌───────────────────────────┐ ┌───────────────────────────┐
│A cell w/ overflow content │ │A cell w/ overflow content │
│ ┌───────────┐ │ <━━━━━━━━━> │ ┌───────────┐ │
│ │A thing │ │ │ │A thing │ │
└─────────────┤that ├─┘ └─────────────┤that ├─┘
┌ ─ ─ ─ ─ ─ ─ ┤overflows ├ ┐ Inset ********│overflows │**
│ended up │ Overflow******│ended up │**
│ │being │ │ **************│being │**
│visible. │ **************│visible. │**
└ ─ ─ ─ ─ ─ ─ ┤ ├ ┘ **************│ │**
┌─────────────┤ ├─┐ **************│ │**
│ │ │ │ **************│ │**
│ │ │ │ **************│ │**
╔═│ │ │ │═╗ ╔═**************│ │**═╗
║ └─────────────┤ ├─┘ ║ ║ **************│ │** ║
║ ┌─────────────┤ ├─┐ ║ ║ **************│ │** ║
║ │ │ │ │ ║ ║ **************│ │** ║
║ │ │ │ │ ║ ║ **************│ │** ║
║ │ └───────────┘ │ ║ ║ **************└───────────┘** ║
║ └───────────────────────────┘ ║ ║ ║
║ ┌───────────────────────────┐ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ └───────────────────────────┘ ║ ║ ║
║ ┌───────────────────────────┐ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ └───────────────────────────┘ ║ ║ ║
║ ┌───────────────────────────┐ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
║ └───────────────────────────┘ ║ ║ ║
║ ┌───────────────────────────┐ ║ ║ ║
║ │ │ ║ ║ ║
║ │ │ ║ ║ ║
╚═│ │═╝ ╚═══════════════════════════════╝
└───────────────────────────┘
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
│ │
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
│ │
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
```
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22325808
fbshipit-source-id: e80ae196fc9158358a67c6706b0a2ddec6d47ee9
Summary:
In RN 0.62 support for `fontVariant` was added on Android.
Using that prop crashes the app on Android below KitKat (4.3 and below)
To reproduce just add any Text with the `fontVariant` styling prop in the app:
```js
<Text style={{fontVariant: ['tabular-nums']}}>This will crash</Text>
```
It will crash any device running Android below KitKat with the error:
This is caused by `java.utils.Objects` only being available on Android 4.4+
## Changelog
[Android] [Fixed] - Fix font variant crash on Android < 4.4
Pull Request resolved: facebook#29176
Test Plan:
[TextUtils.equals](https://developer.android.com/reference/android/text/TextUtils#equals) was added as soon as API level 1, so no compatibility issue here.
Tested on Emulator running Android 4.1, no crash anymore.
I've searched for other occurences of `java.utils.Objects` in the project, and this was the only one, so no need to remove other occurences ✅
Reviewed By: JoshuaGross
Differential Revision: D22337316
Pulled By: mdvacca
fbshipit-source-id: 5507b21b237a725d596d47b5c01e269895b16d4a
Summary: The change contains a bunch of additional asserts that verify some assumptions on which mounting relies on. Working on the previous diffs I realized that it's very easy to broke those and then spend hours trying to understand what exactly went wrong. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22324087 fbshipit-source-id: 1152c40248885d02bde62a493a574868c3732273
Summary: This introduces a new shadow node trait (`Hidden`) which disables emitting ShadowVides for such nodes and all their descendants. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22134220 fbshipit-source-id: 8ea1fc3186019005ad687eacaca0ba4a4d8343dc
Summary: An interactive demo that stress-tests the `display: none` feature. Changelog: [Internal] Fabric-specific internal change. Reviewed By: mdvacca Differential Revision: D22336304 fbshipit-source-id: 43855e979d45b4bdfdcf82f6b805a4f4af868368
Summary: Build `FBReactNativeSpec.h` and `FBReactNativeSpec-generated.mm` using the new codegen script whenever the workspace is created using CocoaPods if the `USE_CODEGEN` envvar is set to 1. Effectively makes use of the new codegen integration in CocoaPods opt-in. The `USE_CODEGEN` envvar check should be removed when the generated files are removed from source control, at which point use of the new codegen in CocoaPods will be necessary. ``` cd RNTester USE_CODEGEN=1 pod install ``` Changelog: [Internal] Reviewed By: RSNara Differential Revision: D22250128 fbshipit-source-id: 8f06bf1424ca2e003ecfd032ec03d7896569f9bd
Summary:
**Motivation:**
Match the old codegen's behavior when generating structs for type alias derived objects.
**Problem description:**
Take, for example, the following spec:
```
export type MyTypeAlias = { /* ... */ }
export interface Spec extends TurboModule {
// ...
+myMethod: (paramName: MyTypeAlias) => void;
// ...
}
```
The codegen needs to generate a struct to expose the properties of the type alias object. The codegen was producing the following output:
```
- (void)myMethod:(JS::MyModule::SpecMyMethodParamName &)paramName;
```
...which does not match the output from the original codegen:
```
- (void)myMethod:(JS::MyModule::MyTypeAlias &)paramName;
```
The original codegen generates a struct using the type alias name, while the new codegen was generating a struct that uses a combination of the property and parameter names.
Now that type alias names are exposed in the schema, the new codegen can match the original codegen's behavior.
**De-duplication of structs:**
Prior to these changes, type aliases were expanded into regular object types. This meant that any spec that used a type alias more than once would lead to redundant structs getting created. With these changes, we only generate the one struct per type alias, matching the old codegen.
**Expansion of type aliases:**
A new type was introduced in D22200700 (facebook@e261f02), TypeAliasTypeAnnotation:
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
This type may now appear in several locations where a `{| type: 'ObjectTypeAnnotation', properties: [] |}` otherwise would have been used. A `getTypeAliasTypeAnnotation` function is introduced which, given an alias name and an array of aliases provided by the module, will produce the actual object type annotation for the given property parameter.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22244323
fbshipit-source-id: 125fbf0d6d887bd05a99bf8b81b30bdda4f1682b
Summary: Bump Gradle to 6.5 or latest version. ## Changelog [Android] [Changed] - bump Gradle to 6.5 Pull Request resolved: facebook#29043 Test Plan: RNTester builds and run as expected Reviewed By: JoshuaGross Differential Revision: D22337424 Pulled By: mdvacca fbshipit-source-id: 4d089a5edfac6672276572fae2a1a7a236142985
Summary: This was an experiment that never shipped. In the meantime we built Fast Refresh which obviates the need to complicate how we load and store bundles on device. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D22330994 fbshipit-source-id: 5a623b2611dd2622f17dd83ed35ef05c3100e40d
Summary: Changelog: [iOS][Added] - This is the first step to build RCTParagraphComponentAccessibilityProvider. The main idea of RCTParagraphComponentAccessibilityProvider is to provide an array of accessible elements for the AttributedString in PCTParagraphComponentView. Reviewed By: sammy-SC Differential Revision: D22214855 fbshipit-source-id: 69d47555e86452620f89a4b2e21ed6065c8e669c
…frastructure
Summary:
Changelog: [Internal]
FindNoteAtPoint takes transformations into account. There is however a problem with how transformation in ScrollView. In ScrollViewShadowNode, getTransform is overriden. In the override we apply `Transform::Translate(-contentOffset.x, -contentOffset.y, 0)`, this means that ScrollView has moved by {-x,-y}. However this is only true for its children, not for scroll view itself. This trips off findNodeAtPoint and if you scroll more than than screen's height, point will not be evaluated as inside ScrollView.
Until we can figure out how to deal with this properly, I think it is better to disable it as usage of JS Inspector is more common in ScrollViews than it is with transformed views.
Reviewed By: shergin
Differential Revision: D22332779
fbshipit-source-id: f48c9ae67a595e6954c2b70fb287db7f8c74378b
Summary: Changelog: [Internal] - The accessibilityRole will be used to specially distinguish normal fragments and fragments with embedded link, which is helpful when building accessibilityElement. According to this document: https://reactnative.dev/docs/accessibility, the accessibilityRole is a common accessibility props that could be inherited, and this is why I add accessibilityRole to the TextAttributes. Reviewed By: sammy-SC Differential Revision: D22249140 fbshipit-source-id: 408b4415bf44539d8671d3d98f1ec06f8035baf6
Summary: ART has been moved out of OSS, but I created the fabric implementation in github repo, this diff migrates the Fabric ART implementation to FB repository again changelog: [Internal] Reviewed By: shergin Differential Revision: D22352930 fbshipit-source-id: 1125d3f27b98be783529134de0d3fbcf1b01a6f4
Summary: Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server". Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D22330966 fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary: `babel/runtime` is not directly required by RN. Changelog: [Internal] Reviewed By: rubennorte Differential Revision: D22374323 fbshipit-source-id: 269de51ceb53ef101cef70f2d410181fc2300514
Summary: Changelog: [Internal] When JS Inspector is activated, ScrollView is unmounted and then mounted again with same state. ScrollView's content offset was being set to 0 inside `[RCTScrollViewComponentView prepareForRecycle]` during unmount but when it is mounted again, we ignored value inside state. Reviewed By: shergin Differential Revision: D22333125 fbshipit-source-id: f232dc95b695605f4819f29d8e0bf14b2f3e9150
Summary: This refined algorithm now takes a zoom/scale into account and deals with `contentInset` properly. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22382482 fbshipit-source-id: 7e9d34d3bababf68e624c045c308957e7e5c9d84
…ger at all Summary: Changelog: [Internal][Yoga] Don't call config->setLogger(nullptr) directly to avoid having no logger at all Broken in D14151037 (facebook@dc7dce1) when it started calling ``` config->setLogger(nullptr); ``` instead of going thru ``` YGConfigSetLogger(config, nullptr); ``` which does the right thing by setting the logger to its default value: https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/yoga/yoga/Yoga.cpp?commit=835911317e8b3cf7da1866e40e1c79cda0690136&lines=4320-4330 Also by default YogaConfig always have a logger: https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/yoga/yoga/Yoga.cpp?commit=835911317e8b3cf7da1866e40e1c79cda0690136&lines=335-343 Reviewed By: SidharthGuglani Differential Revision: D22387459 fbshipit-source-id: 4da91da87a696d38cc9d8db2acb5845d29398adb
…SLocation Summary: Changelog: Adding packager running check when RCTBundleURLProvider is returning JSLocation, this prevents an invalid address from being returned which might cause various issues. Reviewed By: cpojer Differential Revision: D22390156 fbshipit-source-id: a20dbf63103158a34cbf6dc0ae8349b2f9e5b0a8
Summary: Changelog: [Internal] - add the first accessibilityElement Reviewed By: shergin Differential Revision: D22249310 fbshipit-source-id: e0f1920377eb9d7a22737cf7437b1c5bd7195c5d
Summary: Changelog: [iOS][Added] - `getRectWithAttributedString()` aims to get the rect of the fragment with embedded link, which is necessary when building the `accessibilityElement`. In this function, we first enumerate attributedString to find the range of fragments whose `accessibilityRole` is @"link". Then we calculate the rect of the fragment and send to the block and we would define what to do in the block in `RCTParagraphComponentAccessibilityProvider`. Reviewed By: shergin Differential Revision: D22286733 fbshipit-source-id: 4d11cb54375a4e9e72869e646fcb484de089b14b
Summary: Changelog: [Internal] - Add `accessibilityRole` to `RCTAttributedTextUtils`. AccessibilityRole was in `TextAttributes` which is a Fabric's abstraction so cannot be detected when enumerating attributedString. Mapping accessibilityRole from `TextAttributes` to `NSAttributedString` could provide the attributeName when iterating over attributedString and then successfully find the range of the fragment whose `accessibilityRole` has value @"link". Reviewed By: shergin Differential Revision: D22286747 fbshipit-source-id: eb039d6a35e77d1860f86ba287391ccb56fbe7b5
Summary: Changelog: [Internal] - Add the additional accessibilityElement for embedded links Reviewed By: sammy-SC Differential Revision: D22296547 fbshipit-source-id: 286cd3cb19d288d584ecd94a8201a28851ca042f
Summary: This diff implements TelemetryController, a small tool that can be used to instrument mounting transactions. It abstracts the logic of merging telemetry data of multiple transactions in a thread-safe manner. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D22490580 fbshipit-source-id: 3f3425b88d38fddb555c1390fd8f1ff3ef1c475a
Summary: Here we use `TelemetryController` to instrument mounting transactions in RCTMoutingManagers and wire that with RCTMountingTransactionObserving protocol. Now, performance trackers (flags) that we use can obtain this information and report to some server-side infrastructure. (Which will be implemented in future diffs.) Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D22490581 fbshipit-source-id: 37695560437ae0e27845c3bda2030fe6fa4c6735
Summary: Chrome recently changed schema from 'chrome-devtools' to just 'devtools', this change updates Hermes inspector cli tool usage string to reflect that change Changelog: Minor fix in Hermes Inspector cli tool help message Reviewed By: dulinriley Differential Revision: D22557806 fbshipit-source-id: 95ec9cbaac445e105e7e92aec2b6c4e5a7d7924f
Summary: Changelog: [Internal] - Add an condition to exclude accessibilityRole that not currently used Since I've added all the possible values in accessibilityRole enum, it is necessary to gate what needs to be an accessibilityElement. SO I add a condition to exclude accessibilityRole that not currently used. Reviewed By: shergin Differential Revision: D22559136 fbshipit-source-id: 910d59132984872b5a9816b8e390117b7b1e2e71
…dy resumed Summary: When a native module registers itself as a lifecycle event listener, ReactContext will immediately call `onHostResume` if the activity is already in a resumed state. We rely on this behavior for things like NativeAnimatedModule, which only enqueues the frame callback in onHostResume. However, ReactContext only does this if `hasActiveCatalystInstance()` returns true - which makes sense, because we don't want to notify listeners if the instance has been destroyed. But in bridgeless mode, `hasActiveCatalystInstance` returns false, and we never call `onHostResume` in this case. This diff fixes an issue where native driver animations don't work the first time you navigate to a screen with bridgeless mode enabled. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D22560314 fbshipit-source-id: 1a60cb482896308e21d6e438eb9a7314f580ad04
Summary: A small patch update of the Android build tools from 29.0.2 to 29.0.3. It's the default for newly generated Android projects. ## Changelog [Android] [Changed] - Update Android build tools to 29.0.3 Pull Request resolved: facebook#29350 Test Plan: Build project Reviewed By: JoshuaGross Differential Revision: D22521075 Pulled By: mdvacca fbshipit-source-id: 967bbfc6e45c6457d4867282ba311f86dea96208
Summary: This diff changes the InitialLifeCycleState used when initializing RN in FB4A from BEFORE_RESUME to BEFORE_CREATE. The value of this field is used during the teardown of RN to determine if RN is actually running or not The intention of this change is to represent the right behavior of RN during initialization, also this will allow RN to be turn down in case of memory pressure when the bridge has been initialized but before the user has navigated to a RN screen (preloading) changelog: [internal] Reviewed By: JoshuaGross Differential Revision: D22577555 fbshipit-source-id: e54ef596cfe4429745611fe6022eb000051a93d0
…n FB4A Summary: This diff refactors the destruction of the ReactInstanceManager when the app is experiencing low memory. As part of this refactor, I setup an experiment to understand at what level of memory pressure is convenient to destroy the RN bridge. The experiment is divided in six levels described in the following table: https://pxl.cl/1dzx8 https://www.internalfb.com/intern/qe2/fb4a_react_native_memory/android_fb4a_instance_unload_pressure_v2/setup changelog: [internal] Internal Reviewed By: JoshuaGross Differential Revision: D22577553 fbshipit-source-id: 37f8f561099a1ba6239795f5907090ced3b5dd18
Summary: This appears to be the only usage of whitelist/blacklist in react-native-github, let's use some more inclusive language. Changelog: [JS][Internal] Reviewed By: kacieb Differential Revision: D22539431 fbshipit-source-id: 21d4cd54a5a2a676996ccec7b02ef15c421efee1
…acebook#29307) Summary: Multiline `TextInput` can crash when really long texts are inserted and removed quickly. This is caused by the fact that [`-[NSAttributedString string]`](https://developer.apple.com/documentation/foundation/nsattributedstring/1412616-string?language=objc) doesn't really return a copy, and may mutate the string while it is being used by `convertIdToFollyDynamic`. See microsoft#489 (comment) for more details on the issue. This issue was originally reported in microsoft#486 and was fixed in microsoft#489. ## Changelog [iOS] [Fixed] - Fix multiline TextInput crash when inserting/removing lots of text Pull Request resolved: facebook#29307 Test Plan: 1. Open RNTester > TextInput 2. Search for a multiline example 3. Copy some large text and paste it into the text input view 4. Remove some (or all) text 5. Repeat steps 3-4 Reviewed By: shergin Differential Revision: D22488854 Pulled By: JoshuaGross fbshipit-source-id: 6fab7818d68538450d93460361ff5934caf86c10
Summary: Apparently it's possible for `!isEmpty()` to be true and `peek` to be non-null, but for `poll()` to be false. It doesn't really make sense to me, and I don't have a repro, but that's what logs are showing. I suspect a teardown race condition or /maybe/ a Fabric/non-Fabric handoff race condition. Neither of those make a ton of sense, though. The mitigation is fairly straightforward: we are just much more cautious with how we treat the queue and assume everything could be null. This impacts Fabric and non-Fabric equally. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D22593924 fbshipit-source-id: 7748121951a64941fa6da2bd25ebf070be6dc89c
Summary: This diff fixes a ConcurrentModificationException that is thrown when registering events in React Native. This bug was introduced by D22483508 (facebook@80f1341), before event listeners were registered in the NativeModule Thread, now they are registered in the UI Thread. As part of this diff I change the type of mListeners variable to use CopyOnWriteArrayList instead of ArrayList because this variable is accessed from different threads. This will prevent the exception to happen, but additionally we need to verify if the change of threading made in D22483508 (facebook@80f1341) will cause any other issue (e.g. events not being delivered becuase the listeners are registered too late in the UI Thread) changelog:[Internal] Reviewed By: JoshuaGross Differential Revision: D22599747 fbshipit-source-id: 5c5e46710c4a559badbd713f536e6e6e464fda23
Summary: When stopSurface is called, Fabric might be processing a commit and performing measurements even as the context is being removed from the FabricUIManager map. Just return a 0 from `measure` if we can't get a context. This prevents crashes during teardown for measured views that will never be visible anyway. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D22604716 fbshipit-source-id: 67be8d272afd35fc4c2b51b371939c5623e97f73
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
Summary: It is now required to call RCTBridge.setRCTTurboModuleRegistry for turbo modules to work properly on iOS. ## Changelog [Internal] [Fix] - Fix RNTester TurboModules loading Pull Request resolved: facebook#29538 Test Plan: Tested that images in RNTester now loads properly and Redbox module missing warning are gone. Reviewed By: JoshuaGross Differential Revision: D22884163 Pulled By: fkgozali fbshipit-source-id: daf2fccdb518ec4a382b80b7f7b02004405a7564
…an/0.64-merge-head
HeyImChris
reviewed
Aug 30, 2021
HeyImChris
approved these changes
Aug 31, 2021
amgleitman
added a commit
to amgleitman/react-native-macos
that referenced
this pull request
Sep 2, 2021
This allows us to merge in 0b68f3c and a4757d2, thereby resolving microsoft#822.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
32 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary
Merge facebook/react-native's main branch into react-native-macos's main branch through 2020-07-17 23:59:59 PDT (specifically, f00795d).
These changes were made by repeatedly running git merge and resolving merge conflicts as needed.
Notes
Validation