Summary:
UITextView is accessible by default (some nested views are) and disabling that is not supported.
The problem happened because JS side sets `isAccessible` flag for UITextView and UITextField to `true` (with good intent!), which actually disables (surprise!) bult-in accessibility of TextInput on iOS.
On iOS accessible elements cannot be nested, so enabling accessibily for some container view (even in a case where this is view is a public API of TextInput on iOS) shadows some features implemented inside the component.
(Disabling accessibility of TextInput via `accessible=false` was never supported.)
Reviewed By: JoshuaGross
Differential Revision: D15280667
fbshipit-source-id: 72509b40383db6ef66c4263bd920f5ee56a42fc1
Summary: Right now TurboModuleManager gets the JSCallInvokerHolder from the bridge in its constructor; this diff changes the constructor to make the JSCallInvokerHolder a required argument so that TurboModuleManager doesn't directly depend on the bridge.
Reviewed By: axe-fb, RSNara
Differential Revision: D15227184
fbshipit-source-id: b16e6abaa727587986a132d0e124163acdf55408
Summary:
This diff changes the condition in `ViewShadowNode::isLayoutOnly()` removing checking for `onLayout` event listener.
We needed that before because the mechanism of emitting events was based on analyzing mutation instructures (we needed those to be generated for nodes with `onLayout`).
Recenly we changed that algorithm deeply integrating in layout infra, so we don't need this anymore.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15273491
fbshipit-source-id: 2d43f00d1b87369d5993fe5ba70c2de36b8ce0c5
Summary: RCTBridge does not need to retain RCTSurfacePresenter, so we enforce that using `OBJC_ASSOCIATION_ASSIGN`.
Reviewed By: mdvacca
Differential Revision: D15273325
fbshipit-source-id: f223192ff5f781d9e905b004907739a36882bb63
Summary:
Fixes an issue introduced in https://github.com/facebook/react-native/pull/15894 that can cause events to be dispatched out of order.
Also reverted `viewTag` moved to optional property as it didn't actually work and makes code more complex.
[iOS] [Fixed] - Fix event ordering when combining coalescable and non-coalescable events
Pull Request resolved: https://github.com/facebook/react-native/pull/24693
Differential Revision: D15279513
Pulled By: shergin
fbshipit-source-id: 3c64aba6d644ea9564572e6de8330b59b51cf4a9
Summary:
If `$buildDir/generated/res/react/${flavorPathSegment}release/raw` contains files during `gradle assembleRelease` script will fail with `Error: Duplicate resources` error.
This patch is based on this issue [22234](https://github.com/facebook/react-native/issues/22234) and pull request [24518](https://github.com/facebook/react-native/pull/24518).
[Android] [Fixed] - Fix duplicate resource error for raw folder in Android build
[CC from Mike Hardy PR]
Reports of success on the linked issue via use of the patch + patch-package for a couple months, I personally use it full time with all gradle builds (./gradlew clean assembleRelease or if you have a 'staging' flavor, e.g. ./gradlew clean assembleStagingRelease)
Related reading, also cross-links with the linked issue here:
https://stackoverflow.com/questions/53239705/react-native-error-duplicate-resources-android
Pull Request resolved: https://github.com/facebook/react-native/pull/24778
Differential Revision: D15277766
Pulled By: cpojer
fbshipit-source-id: 0ccd76d2aa2e13f7c8bfac07d4ef23b74945807a
Summary:
Issue #22234 includes a number of people (myself included) suffering with duplicate resource errors while building in Android. We have been collectively using a patch there but I don't believe any attempt has been made to PR it upstream.
I am not excellent at gradle, so I may have approached this in completely the wrong way, but it works for me in the standard init templates, as well as my current work project which has a complicated 2 buildType + 4 productFlavor configuration. If there is a better way to achieve the result I am happy to learn
The approach here is to determine the generated path the resources land in, then move them into the main build output tree. If they remain in the generated path android merging fails with duplicate resource errors, so that move (vs copy) is important.
[Android] [Fixed] - Fix duplicate resource error in Android build
Pull Request resolved: https://github.com/facebook/react-native/pull/24518
Differential Revision: D15276981
Pulled By: cpojer
fbshipit-source-id: 3fe8c8556e4dcdac5f96a2d4658ac9b5d9b67379
Summary:
@public
`YGNodeGetInstanceCount` was only ever meant for tests, and caused data races in multi-threaded environments.
It was completely replaced with event-based counting for tests.
Here we remove public API around the counter, and the counter itself.
Reviewed By: SidharthGuglani
Differential Revision: D15174857
fbshipit-source-id: 228e85da565bac9e8485121e956a2e41910b11c8
Summary:
@public
Test utility on top of the new event system that maintains a counter of instantiated nodes. Meant to replace the global node counter.
Reviewed By: SidharthGuglani
Differential Revision: D15174855
fbshipit-source-id: 6998472f95a09b8da652257a26596164bdcf43d6
Summary:
@public
Publish two events, `NodeAllocation` and `NodeDeallocation`, in the same places where the global node counter is changed.
Reviewed By: SidharthGuglani
Differential Revision: D15174858
fbshipit-source-id: 6e4e9add88513b9e987189ca5035d76da2a1de55
Summary:
Eliminate the regression template, as it is hardly used and it is already served by the bug report template. Triagers can add the Regression label selectively, or we can do so through the bot.
Eliminate the discussion template, as it is not meant to be used and we can point people in the right direction using the existing questions template.
Rename the document bug template, and point people to the website repo.
Update the bug report template, and be less prescriptive about how an issue is reported. As long as the issue is well-described and the steps to repro can be reasonably followed by someone who is investigating the bug, we'll be happy.
[Internal] [Changed] - Consolidated issue templates.
Pull Request resolved: https://github.com/facebook/react-native/pull/24765
Differential Revision: D15276866
Pulled By: cpojer
fbshipit-source-id: d99a174982d2454d8cad3a195dfd627a07438611
Summary:
@public
Reduces measure cache size to a number that is enough for 95% of nodes, according to our (FB-internal) measurements.
Node size: 776b -> 584b
Reviewed By: SidharthGuglani
Differential Revision: D15183567
fbshipit-source-id: 9ae8cc78074271a015e7618b931ba0356de87a0c
Summary: Reverting cb7e26ab6a to see if this fixes the accessibility issue we are seeing in text inputs.
Reviewed By: shergin
Differential Revision: D15271883
fbshipit-source-id: e956f93af539e146ac5a7948fdae020c99a1301e
Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Reviewed By: fkgozali
Differential Revision: D15272951
Pulled By: hramos
fbshipit-source-id: aa78f229e05cb553f75cdf6fb4f926829e20a557
Summary: Apparently, Yoga has a "quirks mode" and we have to enable that for Fabric. Which is probably a mistake that we have to make one more time.
Reviewed By: davidaurelio
Differential Revision: D15267852
fbshipit-source-id: 88a910fafc9ff64fb19376f4b74a2f2fd5827eba
Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Differential Revision: D15240810
Pulled By: hramos
fbshipit-source-id: 76f498222b6ac05131b3820d8356bfee696f46b8
Summary:
Continuation of #24687
> Issue: [Polish the "new app screen"](https://github.com/react-native-community/discussions-and-proposals/issues/122)
> This is the pull request for the new intro screen proposal in react native as directed by cpojer
This PR was created because the previous one could not be pushed to for some reason. I cleaned up a few small things and added the component as an example to RNTester so we can keep iterating. My plan is to land this, and then polish it and make it the default in a follow-up.
[General][Added] - New Intro screen, Icons
Removed Lottie Integration
100% React Native 💥
Pull Request resolved: https://github.com/facebook/react-native/pull/24737
Differential Revision: D15259092
Pulled By: cpojer
fbshipit-source-id: bc141fb1425cf354f29deffd907c37f83fd92c75
Summary:
Our Blob implementation was very problematic because it didn't release its underlying resource when the JS instance was dealocated. The main issue is that the fetch polyfill uses blobs by default if the module is available, which causes large memory leaks.
This fixes it by using the new jsi infra to attach a `jsi::HostObject` (`BlobCollector`) to `Blob` instances. This way when the `Blob` is collected, the `BlobCollector` also gets collected. Using the `jsi::HostObject` dtor we can schedule the cleanup of native resources. This is definitely not the ideal solution but otherwise it would require rewriting the whole module using TurboModules + jsi.
Fixes#23801, #20352, #21092
[General] [Fixed] - [Blob] Release underlying resources when JS instance in GC'ed
Pull Request resolved: https://github.com/facebook/react-native/pull/24745
Reviewed By: fkgozali
Differential Revision: D15248848
Pulled By: hramos
fbshipit-source-id: 1da835cc935dfbf4e7bb6fbf2aea29bfdc9bd6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/24764
The `test_android` CI build was failing:
```
./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Not using buckd because watchman isn't installed.
Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
PARSING BUCK FILES: FINISHED IN 1.1s
No build file at ReactAndroid/src/main/libraries/fbjni/BUCK when resolving target //ReactAndroid/src/main/libraries/fbjni:java.
This error happened while trying to get dependency '//ReactAndroid/src/main/libraries/fbjni:java' of target '//ReactAndroid/src/main/java/com/facebook/react/turbomodule/core:jscallinvokerholder'
Exited with code 1
```
The problem was that I was using `react_native_dep("libraries/fbjni:java")` to access JNI classes like `HybridData`. In open source this target translates to the path `//ReactAndroid/src/main/libraries/fbjni`, which doesn't exist. Instead, the actual classes are available at the path `//ReactAndroid/src/main/java/com/facebook/jni`. Therefore, I changed the target to `react_native_dep("java/com/facebook/jni:jni")`. This is exactly how the bridge (i.e: `//ReactAndroid/src/main/java/com/facebook/react/bridge:bridge`) accesses JNI clases.
Reviewed By: hramos
Differential Revision: D15261218
fbshipit-source-id: 659a5627389bbca3603db7de347618cd400d4ffc
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in Jest's setup script have been rewritten to use relative requires. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
[General] [Changed] - Migrate Jest setup scripts from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24753
Differential Revision: D15258238
Pulled By: cpojer
fbshipit-source-id: aa05dc8ea2e4ba195226e8ec7ba6482b7de03240
Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary:
React Native Gesture Handler uses a `RCTViewManager` subclass to manage `UIControl` so the cast to set accessibility props is not safe. This moves the accessibility props we set to `UIView+React` so they can be used safely on any `UIView`.
[General] [Fixed] - Move accessibility props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/24743
Differential Revision: D15258062
Pulled By: cpojer
fbshipit-source-id: 4a25b79407e5cb7b3b368c7506161e989794bb26
Summary:
So far we have only officially supported "iOS" and "Android" as categories, with a "General" catch all for everything else.
Let's add a "JavaScript" category for changes that only affect JavaScript, and an "Internal" category for things that do not make sense in a changelog (e.g. CI changes).
[Internal] [Added] - Added JavaScript and Internal categories to changelog regex
Pull Request resolved: https://github.com/facebook/react-native/pull/24744
Differential Revision: D15258061
Pulled By: cpojer
fbshipit-source-id: 8b6cb193adf602d3bd6639b550e04775b201fe59
Summary:
Solves #15961 - [ANDROID] Linking.getInitialURL() returns null after exiting the app with back button and using deep linking again (only in production!)
As the issue says, it seems that `currentActivity` is null in [IntentModule#getInitialURL](1e8f3b1102/ReactAndroid/src/main/java/com/facebook/react/modules/intent/IntentModule.java (L50)). So I used the `InteractionManager` to wait until current activity to finish initializing.
[Android] [Fixed] - In `Linking.getInitialURL` method, use the `InteractionManager` to wait for the current activity to finish initializing.
Pull Request resolved: https://github.com/facebook/react-native/pull/24748
Differential Revision: D15258046
Pulled By: cpojer
fbshipit-source-id: 0ec1c873766ae90955d47e5e023556eb6c5d5fbb
Summary:
Fix crash in XMLHttpRequest example because `groupTypes` is not supported on android.
[Android] [Fixed] - Fix crash in XMLHttpRequest example on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24747
Differential Revision: D15258037
Pulled By: cpojer
fbshipit-source-id: 73086dc92ceb065200e0faafaf100fa742b387bb
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in `IntegrationTests` have been rewritten to use relative requires. This commit uses requires that are relative to `react-native/...` assuming that IntegrationTests are meant to try consuming RN rather than being part of it.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate IntegrationTests from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24750
Differential Revision: D15258019
Pulled By: cpojer
fbshipit-source-id: 01ac01ba4699f8ba424353f74e745b4057f79b59
Summary:
See #24316 for the motivation. This commit rewrites a couple more new imports in the RNTester project so they use path-based requires.
[General] [Changed] - Migrate TurboModule example in RNTester to use path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24754
Differential Revision: D15258015
Pulled By: cpojer
fbshipit-source-id: adb298cb3006ea0afcd3b813a2e2fe85017764d2
Summary:
There are 2 issues:
* RCTTurboModuleManager may be initialized too late, so the module lookup from native via `[bridge moduleForClass:]` may end up going to the old system incorrectly
* In the case where JS is asking for a nativemodule, we may be incorrectly registering modules that are marked as RCTTurboModule - they should be ignored instead
Reviewed By: mmmulani, RSNara
Differential Revision: D15247632
fbshipit-source-id: 4e0fae33923810c74966b38276b206ac00723012
Summary: I don't recall why the mutation function return rvalue reference, but it is totally incorrect (the function cannot own the object, so returning a reference introducing a dungling pointer and will crash).
Reviewed By: mdvacca
Differential Revision: D15156312
fbshipit-source-id: 497d10de22a41906efe71cd10139e3710ae11a79
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
When using `scrollToLocation` together with `stickySectionHeadersEnabled` in a `SectionList`, the length of the section header is not accounted for when scrolling to any item except the header.
[General] [Fixed] - Adjust scrollToLocation when using sticky section headers
Pull Request resolved: https://github.com/facebook/react-native/pull/24735
Differential Revision: D15240953
Pulled By: cpojer
fbshipit-source-id: fd7121d990c5b01533e456bdfa39bebf6245fa80
Summary:
packagingOptions.pickFirst is unreliable that we could not specify which library will be used.
If user have other third party libraries, the story is more complicated.
From the framework point of view, it is better to drop the pickFirst.
In jsc-android 241213.1.0, we did two things:
1. Remove libc++_shared.so in AAR to prevent the conflict with RN.
2. Build by NDK r17c, which aligned with current RN NDK version.
In this commit, I also revert the pickFirst for JSC.
pickFirst JSC also makes upgrade JSC unreliable.
Currently a lot of user report JSC crash issues, those crash issues may relate to JIT and hard to reproduce in-house.
My plan is to make sure user could choose another JSC build easier,
i.e. only to `yarn add 'jsc-android@latest'`.
We could then propose some experimented JSC build for user to check
if the build could help them to fix the crash issue.
[Android] [Fixed] - Remove unreliable packagingOptions.pickFirst for libc++_shared.so and libjsc.so
NOTE that this may not need to add the changelog, as RN 0.59 does not have pickFirst.
This will also reduce a breaking change for upgrade from RN 0.59 or before.
Pull Request resolved: https://github.com/facebook/react-native/pull/24672
Differential Revision: D15164536
Pulled By: cpojer
fbshipit-source-id: 9fc897a77409173a5841f325b38e2836bb07f599
Summary: Adds disabled kebab case modal props now that we can safely generate them to cpp
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15218837
fbshipit-source-id: d712e53f53d91ae14bba9956321530907f67d2e8
Summary: This diff adds support for kebab-case enum properties by transforming them to KebabCase in cpp
Reviewed By: mdvacca
Differential Revision: D15218781
fbshipit-source-id: 0ec6d28f3ca0e5b8187fc7026e12a8d76be73a7c
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
`UITextField` don't have delegate to observe the selection changes of users(multiline text input `UITextView` have it), so we can add a KVO to observe selection changes.
cpojer shergin
[iOS] [Fixed] - Fixes selection of single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/24714
Differential Revision: D15238379
Pulled By: cpojer
fbshipit-source-id: f149721d6b4df28e90f5a9405c74e01fde7c7d10
Summary:
In #24095, we removed the code that changes the underlying Android view's enabled state to false when "disabled" is included in the accessibility states, which seems correct. The Android view's state shouldn't mirror the accessibility state, it should be the other way round-- the accessibility state should represent the state of the view.
It seems that the existing test is brokenly setting the disabled state in the Javascript object, and then querying the Android view's enabled state to confirm the change. If the Button implementation is actually the culprit, then IMHO, the correct fix would be to have the Button implementation manipulate the Android View's enabled state, not the accessibilityStates code.
[android] [fix] - Fix internal test case around disabled state of buttons
Pull Request resolved: https://github.com/facebook/react-native/pull/24678
Differential Revision: D15237590
Pulled By: cpojer
fbshipit-source-id: d7ebefbcba9d4d9425da4285175302e4b6435df7
