Summary:
react-native-cookie-store wants the ability to set custom cookies on Android. We use ForwardingCookieHandler to mange the cookies. Exposing the `addCookies` method will allow the module to provide the same functionality on Android.
https://github.com/safaiyeh/react-native-cookie-store/issues/1
## Changelog
[Android] [Changed] - Expose addCookies method
Pull Request resolved: https://github.com/facebook/react-native/pull/27512
Test Plan: N/A
Differential Revision: D19236309
Pulled By: cpojer
fbshipit-source-id: bf1a0730165456c34c5bf432ac370176a881cbcf
Summary:
In other part of the hello world, this replacement has been made already. The only place left this way (which make sense) is in `HelloWorld.xcodeproj/project.pbxproj`.
## Changelog
[General] [Fixed] - Adjust HelloWorld-tvOSTests/Info.plist `CFBundleIdentifier` to use PRODUCT_BUNDLE_IDENTIFIER
Pull Request resolved: https://github.com/facebook/react-native/pull/27601
Test Plan: I made this change locally on a project. No big deal as this is a test piece, not going to go on any kind of real world environment.
Differential Revision: D19235760
Pulled By: cpojer
fbshipit-source-id: 95b9936acc1eaddf3f5a86c733f46c5a80ac6423
Summary:
In https://fb.workplace.com/groups/rn.support/permalink/3132785890103338/?comment_id=3132873900094537 we identified that when Metro restarts but the app keeps the main bundle alive, the next request for a split bundle will always produce an invalid bundle. This is because we rely on module ids being stable while Metro is running and when Metro is restarted, those module ids will likely be assigned to different modules.
The fix applied here simply forces a full reload when downloading (registering) a new split bundle if the connection to Metro disappeared.
Another way to mitigate this is to use stable module ids. That's a more involved change in Metro that I'm not planning on making right now.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D19235555
fbshipit-source-id: b8ff10590655952a2af1379bbf4e930f9eb95c1b
Summary:
This diff removes the findShadowNodeByTag_DEPRECATED method from class UIManagerBinding. This method was created on D17175953 to implement findNodeHandle in Fabric. Recently we decided that we don't need to expose findNodeHandle anymore. This diff cleans up thi code.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19216996
fbshipit-source-id: 07c16aeed28851afc09b0f5d6be338bb4440f813
Summary:
This diff implements the findNodeAtPoint API into UIManagerBinding to allow JS to call this method
changeLog: [Internal]
Reviewed By: shergin
Differential Revision: D19190284
fbshipit-source-id: 3a65a2238f964ce031b12c8cf264cdacb6cc8f2e
Summary:
This diff implements the findNodeAtPoint method to return the ShadowNode that is positioned into a Point of the screen.
What's not supported:
- Scroll position
- Transform
- return layoutable nodes that are contained inside a non-layoutable node
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19190285
fbshipit-source-id: fdc0358dc21312e9950a4eb16c36020e9e43e33f
Summary:
This diff extends Geometry class with methods to substract points and to determine if a Rect contains a Point or not
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D19190283
fbshipit-source-id: 7c7dd73be2cd644081ed9af8eeef7e137c618ae4
Summary:
This diff exposes eventTarget on the EventEmitter API
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19190281
fbshipit-source-id: 00dc8cf64f42b1fe176ecb7beefad59e61bd53ca
Summary:
It's not fully clear why it happens but sometimes UIKit cancels (calling some UIGersureRecognizer interface) some UITouch events that seem never previously started. That might be a bug in UIKit or in our local registry.
That happens extremely rarely but happens.
After this change, RCTSurfaceTouchHandler will ignore those touches in production but crash in debug mode (I hope we can find a repro case and fix it).
Anyway, ignoring canceling of touches that RCTSurfaceTouchHandler is not aware of should not be a big deal.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19221204
fbshipit-source-id: 77ce773f7bcc31725bf90a182a91789fd5deeedb
Summary:
Trivial. I need this to make the next diff readable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19221205
fbshipit-source-id: 0f8b608866ea974272901b2b2e208e9cd88c8e0a
Summary:
Diff 1/N explained how calls to `[_bridge enqueueJSCall:]` can be replaced with `_invokeJS` in a bridgeless world.
This diff replaces RCTEventEmitter's usage of `enqueueJSCall` if the bridge isn't available.
Changelog: [Internal][iOS] Make RCTEventEmitter a RCTJSInvokerModule
Reviewed By: RSNara
Differential Revision: D18941955
fbshipit-source-id: 1b81e46585432e005cff5aa0ab4d151f50ea051b
Summary:
Problem: Certain turbo modules use the bridge to access JS directly by calling something like `[_bridge enqueueJSCall:]`. In a bridgeless world, this API no longer works.
Solution: These turbo modules can implement the new protocol defined here. This protocol provides a block during module init which can be used to call JS directly (using `ReactContext`) instead of going through the bridge.
Changelog: [Internal][iOS] - Introducing RCTJSInvokerModule, a new protocol for turbo modules which call js
Reviewed By: RSNara
Differential Revision: D18941933
fbshipit-source-id: 8d581df06be59debf83575124e7d221145c5afb8
Summary:
The concept of the class cannot guarantee that the set of delegates cannot be removed as a side-effect of calling a delegate, so we must make a copy of the delegates before calling on them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19213549
fbshipit-source-id: 7040b2994433d83e3148ec73820e051729be9e29
Summary:
This diff changes the signature of ComponentDescriptor constructor to make it simpler and easier to support: now all arguments are passed via struct that contains all these arguments as fields.
Now the ComponentDescriptor constructor accepts three arguments one of which is optional. This causes some confusion and the possibility of bugs in all subclasses that needs to implement a custom constructor. Mostly because in every case we need to ensure that the constructor:
* Accepts and pass down all parameters/arguments;
* Accepts the right types of those parameters (shared vs weak pointers, references vs values).
* Accepts all thee arguments and pass them (including flavor!). We failed this point several times.
Overal that makes the code simpler and allows changing the set of parameters relatively easy. (There is no plan for it!)
Look at the LOC balance: less code!
Changelog: [INTERNAL]
Reviewed By: sammy-SC
Differential Revision: D18548173
fbshipit-source-id: 5d038b135e004f6c054026b3235ed57db99c086d
Summary:
This diff fixes the rendering of TextInput component for Android 4 devices.
This bug was caused by D18196901, when we changed the base class of ReactEditText from EditText to AppCompatEditText.
The root of the problem is that AppCompatEditText wraps the ReactContext received as a parameter in the construction of the View into a ContextWrapper object. This break the implicity assumption that the method View.getContext will return the same context that was used during the construction of the view.
https://android.googlesource.com/platform/frameworks/support/+/dd55716/v7/appcompat/src/android/support/v7/widget/AppCompatEditText.java#55
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19204032
fbshipit-source-id: eefb562b1da22e6cc58c75845c87dd032d727f49
Summary:
We currently use `UIManager.getViewManagerConfig()` in a few places to check if a view manager exists at runtime; right now these checks fail for Venice because our DummyUIManager returns null. We don't yet have a replacement for this API for Fabric (see T59411524) so for now let's just hard code the view managers that we know exist to return something truthy here. This is hacky, but it works ok for now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19185957
fbshipit-source-id: e3135b45db4c9ff27fd95362deaa3c1b4340bf48
Summary:
React-native server-device connection must be via Wi-Fi. But if the OS-X server has LAN & Wi-Fi interfaces, then device bundle can be incorrectly configured to use LAN interface instead of Wi-Fi. This patch fix this issue. It greps for "baseT" (e.g. media: autoselect (1000baseT <full-duplex>)) and skip interface if it is.
## Changelog
[iOS] [Fixed] - Fix LAN instead of Wi-Fi device bundle configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/27575
Test Plan:
To reproduce an issue setup Mac OS 10.15.1 with LAN and Wi-Fi active interfaces. And connect
real device (not simulator).
And "ifconfig en0" in console should display LAN interface e.g.:
```
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
ether 78:7b:8a:d8:61:42
inet 10.15.61.16 netmask 0xffffff00 broadcast 10.15.61.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
```
"ifconfig eg1" in console should display WiFi interface e.g.:
```
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 14:20:5e:03:5b:2a
inet6 fe80::10e6:1cb6:54ec:1b41%en1 prefixlen 64 secured scopeid 0x5
inet 10.15.91.27 netmask 0xffffff00 broadcast 10.15.91.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
```
In this case device bundle in react-native-xcode.sh script wood be incorrectly configured to use en0 (LAN interface) instead of en1(Wi-Fi) interface.
My patch fixes this issue.
fragment of script output before patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ '[' -z 10.15.61.16 ']
+ '[' -z 10.15.61.16 ']'
+ echo 10.15.61.16
+ [[ -n '' ]]
...
```
After start project ob device we have time lag about 20s then debug out:
`
2019-12-20 16:58:57.530538+0300 AwesomeProject[4590:1923358] Task <164D9AB0-8473-4BA3-BD1A-EC0E92887C17>.<1> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSUnderlyingError=0x2838dc2d0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, NSErrorFailingURLStringKey=http://10.15.61.16:8081/status, NSErrorFailingURLKey=http://10.15.61.16:8081/status, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSLocalizedDescription=The request timed out.}
`
fragment of script output after apply patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ [[ -z 10.15.61.16 ]]
++ ifconfig
++ grep baseT
+ [[ -n media: autoselect (1000baseT <full-duplex>)
media: autoselect (100baseTX <full-duplex>) ]]
++ ipconfig getifaddr en1
+ IP=10.15.91.27
+ '[' -z 10.15.91.27 ']'
+ echo 10.15.91.27
+ [[ -n '' ]]
...
```
App start OK.
On iPhone /iPad simulator works too.
Differential Revision: D19200334
Pulled By: hramos
fbshipit-source-id: 22d791b657abd16a92d075515682b4fa961b489c
Summary:
This diff disables accessibility state changes of the focused view for Android API < 21.
This is necessary because the method view.isAccessibilityFocused was introduced in Android API 21
Users in Android API < 21 will not be able to hear accessibility state changes of the focused view (feature introduced by D17903205)
Changelog: disables accessibility state changes of the focused view for Android API < 21, see PR: 26624
Reviewed By: fkgozali
Differential Revision: D19199096
fbshipit-source-id: 12b349f0ac94b77e9e7328ae40e1ae1a278e8b24
Summary:
In order to enable more fine-grained control of theming in brownfield apps, this adds RCTOverrideAppearancePreference to RCTAppearance.
## Changelog:
[iOS] [Added] - Adds RCTOverrideAppearancePreference to the iOS Appearance module
Reviewed By: sammy-SC
Differential Revision: D19187657
fbshipit-source-id: 52783c497d32d36af2523fce6f040d6cfb5aac3c
Summary:
## Problem
For efficiency reasons, we'd only check whether the current class or its superclass implemented the `TurboModule` interface. However, it's possible for NativeModules to exist that use inheritance, and have their base class extend a code-generated spec. In this case, the superclass of the superclass of the NativeModule will implement `TurboModule`.
## Solution
To fix this problem, I'm relying on the `Types.isAssignable` API and checking whether the NativeModule can be assigned to the `TurboModule` interface. This is a more reliable way of knowing whether a NativeModule is a TurboModule or not.
**Note:** Had to adjust the buck dependencies of FrescoModule to make the `mTypes.isAssignable` check work.
Changelog:
[Android][Fixed] - Correct TurboModule detection logic in ReactModuleSpecProcessor
Reviewed By: fkgozali
Differential Revision: D19183671
fbshipit-source-id: ad21881453fe7027d9432048108f6ba344fd7e63
Summary:
## Problem
`DebugCorePackage` is a `TurboReactPackage`. To register a `TurboReactPackage`s NativeModules, the `NativeModuleRegistryBuilder` loops over all `ReactModuleInfo`s in the package's auto-generated `ReactModuleInfo` list. This list is generated from the `ReactModuleList` annotation of the package using our annotation processors. Because `JSDevSupport` was in its package's `ReactModuleList` annotation, we generated a `ReactModuleInfo` object for it. Therefore, `NativeModuleRegistryBuilder` registered `JSDevSupport` twice (once in `DebugCorePackage` and twice in `Fb4aReactPackage`).
## How did this work before?
`JSDevSupport` was always a part of the `ReactModuleList` annotation of `DebugCorePackage`. However, before D18974084 landed, there were two key things that made this work:
1. `DebugCorePackage` was a `LazyReactPackage`,
2. The `DebugCorePackage.getNativeModules()` did not return a `ModuleHolder` for `JSDevSupport`.
For `LazyReactPackage`s, `NativeModuleRegistryBuilder` calls `LazyReactPackage.getNativeModuleIterator()` to register NativeModules. The iterator returned from `LazyReactPackage.getNativeModuleIterator()`, in this case, loops over the NativeModules returned from `DebugCorePackage.getNativeModules()`. Therefore, we don't register any NativeModules that aren't in `DebugCorePackage.getNativeModules()`. Since `DebugCorePackage.getNativeModules()` didn't contain `JSDevSupport`, it wasn't registered for the second time.
Changelog:
[Android][Fixed] - Unregister JSDevSupport from DebugCorePackage
Reviewed By: ejanzer
Differential Revision: D19187664
fbshipit-source-id: 34141c60542179567d75705937ba09ec8a3dfc2b
Summary:
The logic in the method is only relevant if the sourceType is `UIImagePickerControllerSourceTypeCamera`. So we guard it here, to prevent NSInvalidArgumentException.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19184818
fbshipit-source-id: 5c99dabfaed23629e22fdc888263bd09e8768c88
Summary:
If building a JSError causes a JSError, this would lead to infinite recursion. This changes the error handling path so the problem is visible to JS. There's also a few related cleanups included, and a new test case.
Changelog: [General] [Fixed] - If Error global is not callable when building an error, jsi will throw a JS exception back to JS code. #158
Reviewed By: tmikov, dulinriley
Differential Revision: D18796269
fbshipit-source-id: 57a45d144fa2ea5e78d18c27d3130611737dda96
Summary:
Test results were being written to ~/reports/, while Circle CI was configured to look for these in ~/react-native/reports/.
This simple fix makes it so that Circle CI's test result tab can now display line-by-line results without the need to dig through log spew to understand which tests failed.
## Changelog
[Internal] [Fixed] - Generate test results in discoverable location (CI)
Pull Request resolved: https://github.com/facebook/react-native/pull/27435
Test Plan:
See https://app.circleci.com/jobs/github/hramos/react-native/7112/tests
Compare with any other run, where this tab would show an error message due to lack of test results.
Differential Revision: D19185408
Pulled By: hramos
fbshipit-source-id: 5481a13874bd078deba4a58ddb83dfdfe6845151
Summary:
React Native ScrollViews are flipped upside down when the prop inverted is set to true. This is the root of a bug: tapping on the status bar in iOS should scroll the Flatlist up to the top but currently it does to the bottom.
The solution proposed is to detect natively if the ScrollView is inverted, on such case, prevent it from scrolling it to the beginning of the ScrollView (as a non-inverted ScrollView would do) and force a scroll to the end of it.
I've been careful enough not to force the scroll if the user explicitly selected not to do it or if it's happening in a nested ScrollView, as it is the default behaviour in iOS.
Fixes https://github.com/facebook/react-native/issues/21126
## Changelog
[iOS] [Fixed] - Inverted ScrollViews scroll to their bottom when the status bar is pressed
Pull Request resolved: https://github.com/facebook/react-native/pull/27574
Test Plan:
- on iOS, add a ScrollView and put enough content to overflow the screen size so it can be scrolled
- add the prop `inverted={true}` to the ScrollView
- go to the screen the Scrollview is in and press the status bar
- it should scroll to top (previously it scrolled to the bottom)
Differential Revision: D19185270
Pulled By: hramos
fbshipit-source-id: 5445093ff38f4ba4082f1d883d8ed087e9565eaf
Summary:
GitHub still marks some dependencies as vulnerable. Updating them.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D19183702
fbshipit-source-id: 9c9c815816c4fc591c77d811058234a63aeda727
Summary:
As part of the plan is splitting ShadowNodeFragment into two parts. ShadowNodeFamilyFragment is already in place. This diff removes use of `ShadowNodeFragment::eventEmitter` and goes over all call sites to change it to `ShadowNodeFamilyFragment::surfaceId`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19146697
fbshipit-source-id: 22cae5404b0f3098feb86c0437a4aa256d5b773e
Summary:
As part of the plan is splitting `ShadowNodeFragment` into two parts. `ShadowNodeFamilyFragment` is already in place. This diff removes use of `ShadowNodeFragment::surfaceId` and goes over all call sites to change it to `ShadowNodeFamilyFragment::surfaceId`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19115785
fbshipit-source-id: 5972332c3360b88ca935581ed36070f26e678b22
Summary:
As part of the plan is splitting `ShadowNodeFragment` into two parts. `ShadowNodeFamilyFragment` is already in place. This diff removes use of `ShadowNodeFragment::tag` and goes over all call sites to change it to `ShadowNodeFamilyFragment::tag`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19115781
fbshipit-source-id: 6ab3464a063c220d0924bf5a69b75449ca178650
Summary:
The header role is being said twice in android. Stopped that from happening.
## Changelog
[General] [Added] - removed code that would cause accessibility header role to be spoken twice
Pull Request resolved: https://github.com/facebook/react-native/pull/27496
Test Plan:
Test plan is testing in RNTester making sure the examples work
## Note:
generatedComponentApiDocs.js was modified by lint commands. I can submit a PR without it if preferred.
Differential Revision: D18973520
Pulled By: hramos
fbshipit-source-id: 9a7cc2d3fac1d0fc79dedb443d5ca365026b3b15
Summary:
I moved towards C function to return component class instead of delegate.
We need this in order to register components that are optimistically registered, such as View, Image and Text.
In D19088558, we need this in order to register Image.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19088559
fbshipit-source-id: 061f3ba15dfb44b9acce7be2dc6828b9afbecbfa
Summary:
This diff fixes two issues with LogBox in OSS.
Changelog: [Internal]
Reviewed By: mmmulani
Differential Revision: D19165696
fbshipit-source-id: 4dd9c480ea3d2b205f8e65cb32203949b1e32e8a
Summary:
`msggen` has dependencies on some npm packages with vulnerabilities.
This diff updates the dependency list.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D19107926
fbshipit-source-id: 0526f6fe430c162322ec9ecb84f3d78604cd76bc
Summary:
Having automatic defaults/an optional arg for `convertRawProp` has caused way more problems than it is worth. Remove the default argument.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19151594
fbshipit-source-id: 839ec8d138b2c3c083f221a2871582454004648c
Summary:
Files that are inside `xcshareddata` are meant to be "shared", and that means committed to git. These files are for example `ios/RnDiffApp.xcodeproj/xcshareddata/xcschemes/RnDiffApp.xcscheme`, and if ignored that means they are removed from the repo or are missing when cloning. These should be present. They are the shared schemes so Xcode knows what and how to build, on everyone's machine.
I noticed it being there in a new project on 0.62.0-rc.0.
## Changelog
[iOS] [Changed] - Remove the xcshareddata from .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/27563
Differential Revision: D19166364
Pulled By: TheSavior
fbshipit-source-id: 0377dc5b08ba04d121f9ed5e4027942a7a9f463f
Summary:
I stumbled on this comment where the task was closed
Changelog: [Internal]
Reviewed By: lunaleaps, RSNara
Differential Revision: D18933260
fbshipit-source-id: 8d35e0fa19dc9aec7b811131318858c27c34accd
Summary:
This implements propagation of ScrollView's contentOffset value on Android. That allows `LayoutableShadowNode::getRelativeLayoutMetrics` (and some measure functions) return values that take that info into account.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19027433
fbshipit-source-id: 023ff9642d023971b3d24d5cc5f7c2f4b443031e
Jason Safaiyeh
Max Thirouin
Christoph Nakazawa
Jason Safaiyeh
David Vacca
Valentin Shergin
Peter Argany
Samuel Susla
Emily Janzer
Jakub
Oleg E. Bakharev
Will Holen
Zack Argyle
Ramanpreet Nara
Kevin Gozali
Marc Horowitz
Héctor Ramos
Emilio
Héctor Ramos
Héctor Ramos
Kevin Gonzales
sunnylqm
Spencer Ahrens
Rick Hanlon
Joshua Gross
Pavlos Vinieratos
