Summary:
View needed this wrapper to add a dev time warning about text children. Text children became supported and this warning was removed in https://github.com/facebook/react-native/pull/23195
This check is no longer necessary and we can reduce the overhead and improve the performance of View by removing this.
Reviewed By: rickhanlonii
Differential Revision: D15914658
fbshipit-source-id: 6456a9cb356245fa8104036b2948aa5c5bf39e0f
Summary:
view config RCTStickerViewNativeComponent
had to get one view config in before I left London lol
Reviewed By: rickhanlonii
Differential Revision: D15825774
fbshipit-source-id: 846d9ee1d15f6ec64d88a1af7b72fd863ae10afc
Summary: Trying to mitigate animation-related crashes in T43628589. Clues: all the crashes are off the main thread, and most operations in this class happen explicitly in blocks executed on the main thread. I think there's a category of race conditions caused by animations not being allocated yet when this code runs / being deallocated as it's running. We shouldn't need to add locks if everything just runs on the main thread.
Reviewed By: PeteTheHeat
Differential Revision: D15924310
fbshipit-source-id: d82f5434e53fd394c4a7548d52f59a0f63961779
Summary:
Previously SwipeRefreshLayout (RefreshControl on Android) required taking an int as the size. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
We will change the type of size from:
```
size?: ?(
| typeof RefreshLayoutConsts.SIZE.DEFAULT
| typeof RefreshLayoutConsts.SIZE.LARGE
),
```
to:
```
size?: ?('default' | 'large')
```
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android] [Added] - RefreshControl now supports strings and not just numbers for size.
Reviewed By: mdvacca
Differential Revision: D15909582
fbshipit-source-id: 1849edc980e1698de147e88d710e0f28d0fdc8d8
Summary:
[Android] [Added] - Release underlying resources when JS instance is GC'ed on Android
D15279651 introduced a crash for Oculus Twilight on Android (T45199437), so it was reverted by D15611385.
This diff fixes the crash and re-applies D15279651. The problem was that ProGuard renamed BlobModule.remove() to BlobModule.release(), but the C++ code in `BlobCollector.cpp` still expected the old name. I confirmed this by looking at the Extracted Symbols file for the build which introduces the crash (https://fburl.com/mobile/ud40od3i):
```
com.facebook.react.modules.blob.BlobModule -> com.facebook.react.modules.blob.BlobModule:
...
8190:8193:void remove(java.lang.String):190:193 -> release
...
```
See the full log file here: https://fburl.com/pn02bwkb.
The solution is to annotate the method with `DoNotStrip` so that ProGuard doesn't rename it.
Reviewed By: mdvacca, cpojer
Differential Revision: D15826082
fbshipit-source-id: f7470d394666cd34c1acae5c6ffaecc84d5ca5a3
Summary:
It's unclear why, but the introspection infra is enabled somehow in prod.
It must be some kind of misconfiguration somewhere. Until we figure it now, we have to disable it completly.
Reviewed By: mdvacca
Differential Revision: D15908765
fbshipit-source-id: 2b17c61938731d43eaef51b070a4ec1ae9e5e1df
Summary:
This diff removes an option from the codegen and replaces it with two new options
Removes:
- `isDeprecatedPaperComponentNameRCT`
Adds:
- `paperComponentName`: a better version of the removed option that allows more than just adding RCT
- `paperComponentNameDeprecated`: a new option that allows migrating native code to a new name
```
// Use for components with no current paper rename in progress
// Does not check for new name
paperComponentName?: string,
// Use for components currently being renamed in paper
// Will use new name if it is available and fallback to this name
paperComponentNameDeprecated?: string,
```
For example, Slider uses `paperComponentName: 'RCTSlider'` because it has a different name in fabric but is not currently being migrated to a new name. Because of other work in progress, we don't want to use UIManager check if we don't need to
Reviewed By: shergin
Differential Revision: D15857629
fbshipit-source-id: ca0d3b7dc4a75e00d136ae1f5c84f7423960399d
Summary:
When a synchronous call from JS to native code throws an error, it doesn't include a useful stack trace from the native side. To improve error attribution, this diff pops the frames in `MessageQueue.js` and `NativeModules.js` from the stack traces of such errors. This uses the `error.framesToPop` convention understood by RN's global error handler.
For now we limit this to errors converted from C++ exceptions in host functions, since those are not likely to ever contain further JavaScript frames at the point where we catch them; if they did, it would violate our assumption that the top two frames of the stack are in the JS bridge code.
Reviewed By: cwdick
Differential Revision: D15805054
fbshipit-source-id: 8c1dd7c81b00b6a88e31473271889af1f88f7263
Summary: Adds a test for synchronous methods (`type === 'sync'`) in NativeModules. This doesn't modify any behaviour.
Reviewed By: amnn
Differential Revision: D15804757
fbshipit-source-id: 4db76dbd0b0b111ed9311d4b7ec35a077c377f01
Summary: Adds a test for promise-returning methods (`type === 'promise'`) in `NativeModules`. This doesn't modify any behaviour.
Reviewed By: cwdick
Differential Revision: D15802452
fbshipit-source-id: 8dc1f862d33742ef4ba355ca36338e0dbabf8edb
Summary:
Types the last 3 members of the `ModuleConfig` tuple (functions, promise method IDs, and sync method IDs) as nullable and immutable arrays. This is in line with how they are used in the code; one debug-only call site had to be fixed to account for nullability.
Also updates the test data in `MessageQueueTestConfig` to explicitly conform to this type.
Reviewed By: amnn
Differential Revision: D15899159
fbshipit-source-id: b6955ba92efc73253de48e2ce7c3034fa91adce3
Summary:
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/15611
Test Plan: Added a Slider (it used RCTBubblingEventBlock for it's onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15896806
Pulled By: cpojer
fbshipit-source-id: c0ae463f4c3f890062238575e813ed7ab3b7a7e6
Summary: For better perf with TurboModule, cache the return value of NativePlatformConstants*.getConstants() in JS so that we avoid going back into native (from JS) for each call. This specific method is called very frequently throughout RN codebase.
Reviewed By: mdvacca
Differential Revision: D15893289
fbshipit-source-id: ce8016ed7d3efb420df93e27dbfa77d7d4f06cf8
Summary: Previously, we didn't provide any LayoutContext to the very first commit (aka startSurface); apparently it causes problems.
Reviewed By: mdvacca
Differential Revision: D15891472
fbshipit-source-id: b2a785bdad5764eb97b41f5bf5679807107bd8a0
Summary: Some TM lookup from native will fail assertion if done too early, because TM Manager is not initialized yet.
Reviewed By: mdvacca
Differential Revision: D15872776
fbshipit-source-id: 7616c1424816f73a45aa1d9723e7807ae10392a7
Summary:
To avoid unnecessary class loads, and better modularity, let's use string keys (enum) to access JSIModule's. For now all JSIModule's are all known inside the core infra (only FabricUIManager and TurboModuleManager right now), so let's keep it simple and explicitly list them out.
The only problem here is we lose some form of type safety...
Reviewed By: JoshuaGross
Differential Revision: D15872777
fbshipit-source-id: 9c2de7ef1e88ef3a6dff5888d644f9d8963af2a3
Summary: I added this function in D15810990, not sure why lint didn't complain about this...
Reviewed By: zackargyle
Differential Revision: D15880129
fbshipit-source-id: 4d207ba26be46186dc3904c82d82a4a83d4d4eb7
Summary:
ComponentName is used by many core component of React Native, such as ComponentDescriptor, ShadowNode, ShadowView and so on. In all those cases this value represents the actual name of the component which came from `concreteComponentName` template parameter of ConcreteShadowNode. In all of those cases, it's raw `char const *` type. So, we don't need to use owning representation of the string (std::string) in all those places.
The only exception from this is a part where we receive the name of the component from JS side. In this case, the source string comes from JS and has to be analyzed as a character sequence to find corresponding ComponentDescriptor.
In my experiments, 20% of the time during diffing is spent on copying (this) `std::string`.
Reviewed By: mdvacca
Differential Revision: D15844407
fbshipit-source-id: a2e71505e22d09107e001bdf661d4a826bcf2dea
Summary:
It is possible that race conditions exist in access of scheduler and UIManager in Binding.cpp, such that deallocated or null schedulers/UIManagers could be passed as arguments into various functions, causing strange and exotic crashes down the line once garbage memory (or null pointers) are dereferenced.
I think it's possible that navigating away from a Fabric screen while there's high memory pressure could cause things to get deallocated more aggressively and cause scheduler and/or UIManager to disappear while mounting instructions are being created, for instance.
Reviewed By: mdvacca
Differential Revision: D15863193
fbshipit-source-id: a85cb71d88ea54826b40f44e788931dfc422f045
Summary:
The problem happens only from native debug build, i.e.
`NATIVE_BUILD_TYPE=Debug ./gradlew ...`
During Java exception happens, [only limited methods are allowed](https://developer.android.com/training/articles/perf-jni#exceptions_1).
RN uses smart pointer to manage JNI reference.
There is an assert() in smart pointer constructor that will call other JNI method and lead to VM crash.
Since assert() do things in debug build by default, the problem will not happens on native release build.
### Crash backtrace
Java exception happens:
```
java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION: JNI GetObjectRefType called with pending exception com.facebook.react.uimanager.IllegalViewOperationException: No ViewManager defined for class Text
java_vm_ext.cc:534] at com.facebook.react.uimanager.ViewManager com.facebook.react.uimanager.ViewManagerRegistry.get(java.lang.String) (ViewManagerRegistry.java:57)
java_vm_ext.cc:534] at com.facebook.react.uimanager.ViewManager com.facebook.react.uimanager.UIImplementation.resolveViewManager(java.lang.String) (UIImplementation.java:134)
java_vm_ext.cc:534] at com.facebook.react.bridge.WritableMap com.facebook.react.uimanager.UIManagerModule.computeConstantsForViewManager(java.lang.String) (UIManagerModule.java:325)
java_vm_ext.cc:534] at com.facebook.react.bridge.WritableMap com.facebook.react.uimanager.UIManagerModule.getConstantsForViewManager(java.lang.String) (UIManagerModule.java:319)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.NativeRunnable.run() (NativeRunnable.java:-2)
java_vm_ext.cc:534] at void android.os.Handler.handleCallback(android.os.Message) (Handler.java:790)
java_vm_ext.cc:534] at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:99)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(android.os.Message) (MessageQueueThreadHandler.java:29)
java_vm_ext.cc:534] at void android.os.Looper.loop() (Looper.java:164)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run() (MessageQueueThreadImpl.java:232)
java_vm_ext.cc:534] at void java.lang.Thread.run() (Thread.java:764)
```
Native crash backtrace:
```
#00 pc 00000000000276f8 /system/lib64/libc.so (syscall+24)
https://github.com/facebook/react-native/issues/01 pc 0000000000027905 /system/lib64/libc.so (abort+101)
https://github.com/facebook/react-native/issues/02 pc 000000000052f32e /system/lib64/libart.so (art::Runtime::Abort(char const*)+558)
https://github.com/facebook/react-native/issues/03 pc 00000000006341a8 /system/lib64/libart.so (android::base::LogMessage::~LogMessage()+1016)
https://github.com/facebook/react-native/issues/04 pc 0000000000399339 /system/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1657)
https://github.com/facebook/react-native/issues/05 pc 00000000003994c2 /system/lib64/libart.so (art::JavaVMExt::JniAbortV(char const*, char const*, __va_list_tag*)+82)
https://github.com/facebook/react-native/issues/06 pc 0000000000178aab /system/lib64/libart.so (art::ScopedCheck::AbortF(char const*, ...)+187)
https://github.com/facebook/react-native/issues/07 pc 00000000001785b8 /system/lib64/libart.so (art::ScopedCheck::CheckThread(_JNIEnv*)+472)
https://github.com/facebook/react-native/issues/08 pc 0000000000176871 /system/lib64/libart.so (art::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::JniValueType*)+801)
https://github.com/facebook/react-native/issues/09 pc 000000000017614a /system/lib64/libart.so (art::CheckJNI::GetObjectRefType(_JNIEnv*, _jobject*)+778)
https://github.com/facebook/react-native/issues/10 pc 0000000000123831 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_JNIEnv::GetObjectRefType(_jobject*)+49)
https://github.com/facebook/react-native/issues/11 pc 00000000001236b1 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (facebook::jni::LocalReferenceAllocator::verifyReference(_jobject*) const+81)
https://github.com/facebook/react-native/issues/12 pc 0000000000046f40 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::base_owned_ref<_jthrowable*, facebook::jni::LocalReferenceAllocator>::base_owned_ref(_jthrowable*)+64)
https://github.com/facebook/react-native/issues/13 pc 0000000000046ef7 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::basic_strong_ref<_jthrowable*, facebook::jni::LocalReferenceAllocator>::basic_strong_ref(_jthrowable*)+39)
https://github.com/facebook/react-native/issues/14 pc 000000000003648b /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (_ZN8facebook3jni11adopt_localIP11_jthrowableEENS0_16basic_strong_refIT_NS0_23LocalReferenceAllocatorEEES5_+27)
https://github.com/facebook/react-native/issues/15 pc 0000000000036333 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::throwPendingJniExceptionAsCppException()+99)
https://github.com/facebook/react-native/issues/16 pc 000000000018652f /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (facebook::react::MethodInvoker::invoke(std::__ndk1::weak_ptr<facebook::react::Instance>&, facebook::jni::alias_ref<facebook::jni::detail::JTypeFor<facebook::react::JBaseJavaModule, facebook::jni::JObject, void>::_javaobject*>, folly::dynamic const&)+4559)
https://github.com/facebook/react-native/issues/17 pc 00000000001616fa /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react16JavaNativeModule26callSerializableNativeHookEjON5folly7dynamicE+954)
https://github.com/facebook/react-native/issues/18 pc 000000000021bbd6 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react14ModuleRegistry26callSerializableNativeHookEjjON5folly7dynamicE+486)
https://github.com/facebook/react-native/issues/19 pc 000000000022d90b /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react16JsToNativeBridge26callSerializableNativeHookERNS0_10JSExecutorEjjON5folly7dynamicE+75)
https://github.com/facebook/react-native/issues/20 pc 000000000004a6fa /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so (facebook::react::JSIExecutor::nativeCallSyncHook(facebook::jsi::Value const*, unsigned long)+202)
https://github.com/facebook/react-native/issues/21 pc 000000000004b7a2 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so
https://github.com/facebook/react-native/issues/22 pc 0000000000056475 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so
https://github.com/facebook/react-native/issues/23 pc 00000000000c3a0a /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjsc.so
```
Java exception code from [ViewManagerRegistry.java](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/uimanager/ViewManagerRegistry.java#L45-L58) :
```java
public ViewManager get(String className) {
ViewManager viewManager = mViewManagers.get(className);
if (viewManager != null) {
return viewManager;
}
if (mViewManagerResolver != null) {
viewManager = mViewManagerResolver.getViewManager(className);
if (viewManager != null) {
mViewManagers.put(className, viewManager);
return viewManager;
}
}
throw new IllegalViewOperationException("No ViewManager defined for class " + className);
}
```
It is an expected exception as [legacy JS try to find view manager](https://github.com/facebook/react-native/blob/master/Libraries/ReactNative/PaperUIManager.js#L44-L50) and Text has no ViewManager registered in fact.
From C++ assert:
`adopt_local` will call to base_owned_ref() and [there is an assert to ensure JNI reference type](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/first-party/fb/include/fb/fbjni/References-inl.h#L203-L209).
```C++
template<typename T, typename Alloc>
inline facebook::jni::base_owned_ref<T, Alloc>::base_owned_ref(
javaobject reference) noexcept
: storage_(reference) {
assert(Alloc{}.verifyReference(reference));
internal::dbglog("New wrapped ref=%p this=%p", get(), this);
}
```
In the verifyReference(), [there is a GetObjectRefType() call which is an invalid call at exception pending state](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/first-party/fb/include/fb/fbjni/ReferenceAllocators-inl.h#L57-L62).
```C++
inline bool LocalReferenceAllocator::verifyReference(jobject reference) const noexcept {
if (!reference || !internal::doesGetObjectRefTypeWork()) {
return true;
}
return internal::getEnv()->GetObjectRefType(reference) == JNILocalRefType;
}
```
The fix moves `adopt_local()` wrapping after `ExceptionClear()` and we could call `GetObjectRefType()` without problems.
## Changelog
[Android] [Fixed] - Fix Android native debug build assert crash
NOTE this might be ignored in RN release changelog.
Since the problem should exist for years and no user tried native debug build.
Pull Request resolved: https://github.com/facebook/react-native/pull/25263
Test Plan:
Try to run RNTester from native debug build and make sure no crash happens.
(It is a launch crash and should be easy to verify)
`NATIVE_BUILD_TYPE=Debug ./gradlew clean :RNTester:android:app:installDebug`
Differential Revision: D15873691
Pulled By: cpojer
fbshipit-source-id: fb93b85daa1136cdf44e7fd7f217a2767391d8dd
Summary:
HTTPS is good and this prevents a HTTP redirect
## Changelog
[Internal] [Fixed] - https link to EditorConfig.org
Pull Request resolved: https://github.com/facebook/react-native/pull/25267
Differential Revision: D15873696
Pulled By: cpojer
fbshipit-source-id: 2d769fe163816c75d1461d09837ec9c06a929e04
Summary: This diff forces the method: scheduler.constraintSurfaceLayout to run on the JS thread.
Reviewed By: JoshuaGross
Differential Revision: D15845768
fbshipit-source-id: de2aa69f301770aaf6cb7c3f5670548a3b6110df
Summary: Seems RCTImageLoader is not thread-safe, so we need to compensate for this for now. Classic RN mostly accesses the loader from the main thread (non-concurrently), so it mostly works for Paper.
Reviewed By: mdvacca
Differential Revision: D15867574
fbshipit-source-id: 4aad5570b57a136aa0bbe31d65f1afe2ae6e380e
Summary: We should not use `self.contentView` accessor to insert container views (views that might be used as a container for nested views) into component view otherwise it causes double applying of padding values.
Reviewed By: mdvacca
Differential Revision: D15862075
fbshipit-source-id: aad834aeca06f66b19c2f7bbaa0b58f937e66994
Summary: Requiring legacy native modules fails in bridgeless mode because they use the batched bridge, so we need to check for turbomodules first to avoid crashing. In D15703655 I reversed the order of this check for everyone, but this had some unintended side effects (everyone got turbomodules). This time I'm just using my flag to check for bridgeless mode so we can bail out of legacy native modules instead.
Reviewed By: fkgozali
Differential Revision: D15857106
fbshipit-source-id: 9d33161ae059e7a357f135c82b6865f4d2a57add
Summary: Scheduler.startSurface accepts LayoutConstraints and LayoutContext, but for some reason we don't use these on Android. This diff adds new methods to Binding and FabricUIManager to start a surface with the provided measurespecs. I created new methods to avoid affecting the functionality of any surfaces already using Fabric, but if we want this behavior everywhere then I can just add it to the existing `addRootView` and `startSurface`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D15810990
fbshipit-source-id: 6cd9a58b125461f91253458905405298cfb723ce
Summary:
This adds the Fresh Babel plugin and runtime to React Native dependencies. **They're not actually being used or enabled yet**. This is purely additive and just gets the deps setup out of the way for future diffs.
The `react-refresh` source of truth is in the React repo.
Reviewed By: cpojer
Differential Revision: D15828330
fbshipit-source-id: 67ec2dea8c896477ff8b434445f1730e388ea67a
Summary: This diff adds the generated view config for View (in DEV)
Reviewed By: ejanzer
Differential Revision: D15780039
fbshipit-source-id: 1ec8ed1b57fd2341552746051980129848cb8e85
Summary:
## Context
At the moment, the codegen process does not expect any types defined in a native component (*NativeComponent.js) to be exported. For example, the `NativeProps` type may be defined as:
```
// RCTSegmentedControlNativeComponent.js
type NativeProps = $ReadOnly<{|
...
onChange?: ?(event: BubblingEvent<Event>) => mixed,
|}>;
```
However, it would be helpful to be able to reuse `NativeProps` in the user facing component:
```
// SegmentedControlIOS.js
type Props = $ReadOnly<{|
...NativeProps
onValueChange?: ?(value: number) => mixed,
|}>;
```
## Changes
- updates the `getTypes` function to unwrap the type declaration inside exported declarations
- add test to verify that exported types are parsed as expected
Reviewed By: rickhanlonii
Differential Revision: D15851693
fbshipit-source-id: a9cd375c69cbb8fe9a38be3d2a681227444fb33d
Summary:
Adds the ability to `MarkerSection` to end the marker before it goes out of scope.
This unlocks two scenarios:
- reuse the data associated with a marker after ending it.
- end markers in the middle of a function without adding arbitrary blocks.
Reviewed By: SidharthGuglani
Differential Revision: D15837840
fbshipit-source-id: c0afaeeabd169c65189b5028be54ea7dac3e3b84
Summary: Counts how many times measure callbacks have been invoked during a layout pass. This is made available via the marker and event APIs.
Reviewed By: SidharthGuglani
Differential Revision: D15836983
fbshipit-source-id: 3835bef94e497375821c9f2ad8209447b4f11518
Summary: Just adding a few systrace sections to add perf visibility in a few more areas.
Reviewed By: ejanzer
Differential Revision: D15823394
fbshipit-source-id: 6ac1773cbd8e01a747ad015726e16c0bf0e8596b
Summary:
There's an issue with TextInput on Android where if you have TalkBack enabled, double tapping doesn't focus the text input. It turns out this is because we ignore all focus events that aren't from JS in ReactEditText. This diff makes an exception for the accessibility click event.
I think this should also fix https://github.com/facebook/react-native/issues/17624
Reviewed By: lunaleaps
Differential Revision: D15818103
fbshipit-source-id: 354728b58f1023c4d44edd48337c8daa8ea15c0c