Summary:
Fixes#20774
The new Xcode build system uses parallel execution to run build steps that don't have an obvious dependency. Our Xcode project was written with the assumption that the **Install Third Party** build step is run _before_ compiling the `third-party` libraries. To address this issue, this PR adds dependency information to the project to teach Xcode that `ios-install-third-party.sh` is generating the files under `third-party`. With this additional information, Xcode correctly waits for `ios-install-third-party.sh` to finish before advancing to the compile step.
In addition to the Xcode project changes, I had to make some changes to the script `ios-install-third-party.sh` so that
1. it would always execute the `ios-configure-glog.sh` script regardless of how it was invoked
2. it would always install the libraries even if Xcode had partially created the tree or if a previous install was interrupted
Pull Request resolved: https://github.com/facebook/react-native/pull/21458
Differential Revision: D10365495
Pulled By: hramos
fbshipit-source-id: c88042583f21d2447a16f6ae2b6abb929c659a26
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary:
This adds a synchronous method that JS can call to load view managers.
Notably, we don't have an exact way to go from a JS name to the native view manager, so this naively adds 'Manager' to the end.
After lazily loading the view, it makes sure to cache all its values in native and JS, as further calls from JS will fail.
Reviewed By: PeteTheHeat
Differential Revision: D10204314
fbshipit-source-id: ebf42a85dcc467f3b4c5d6e18e49e04f9e8aa4f9
Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
Reviewed By: sahrens
Differential Revision: D10081501
fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
Summary:
This PR splits and renames all references of ViewAccessibility to DeprecatedViewAccessibility
Related to #21342
Pull Request resolved: https://github.com/facebook/react-native/pull/21422
Reviewed By: yungsters
Differential Revision: D10132659
Pulled By: RSNara
fbshipit-source-id: 68c371230c69ed37c3e44bf8a36043adb04afc78
Summary: The current buffer size isn't enough even to capture a short TTI trace.
Reviewed By: mhorowitz
Differential Revision: D10112538
fbshipit-source-id: 266fa6ffa916049245b21d7725a364d75589c776
Summary:
This PR fixes an obscure rendering bug on iOS for borders with asymmetric radii. It appears to be a problem with the custom drawing that React Native performs when it cannot use native UIKit/CoreAnimation border drawing.
Pull Request resolved: https://github.com/facebook/react-native/pull/21208
Differential Revision: D10130120
Pulled By: hramos
fbshipit-source-id: d9fbc5c622c060db15658d038a068216b47bb26d
Summary:
Update several files to use the proper copyright header:
```
// Copyright (c) Facebook, Inc. and its affiliates.
//
// This source code is licensed under the MIT license found in the
// LICENSE file in the root directory of this source tree.
```
In the case of Xcode project files, I used the shortform version, `Copyright (c) Facebook, Inc. and its affiliates.`
Reviewed By: axe-fb
Differential Revision: D10114529
fbshipit-source-id: a1f2d5a46d04797c1cf281ea9ab80d3a2caa6fb4
Summary:
Don't ask.
Really, all those descriptions from official docs like below are useless:
* `__bridge_transfer` Moves a Core Foundation pointer to Objective-C with transfer of the ownership to ARC.
* `__bridge` Transfers a pointer between Objective-C and Core Foundation with no transfer of ownership
All that is totally confusing and useless. At the end of the day, we only have to think about which additional `CFRetain` and `CFRelease` ARC will add or will not add for our pointers.
So, following official docs recommendation, we would like to add `__bridge_transfer` because of course, we do want to ARC managing the variable after we introduced it to ARC here. But we also want to have shared ownership of this. That's the key. If we use `__bridge_transfer` ARC will assume that this variable already retained once (because it exists) and will call CFRelease at the end of the scope. Right before that when we pass this variable down to call stack ARC will retain and then manage the variable according to the rest of the code. But still, from this point, we will have zero-balanced reference counter; the owning by `shared_ptr` bump is already compensated with `CFRelease` at the end of the scope. As soon as the rest of the code release the object, it will be incorrectly deallocated.
So, instead of using `__bridge_transfer` we have to use `__bridge`. That will indicate that *in this block* ARC does not manage the reference counter of the variable (which is kinda true because having `shared_ptr` inside the block already retains that) and will not add `CFRelease` at the end of the block.
Reviewed By: mdvacca
Differential Revision: D10054241
fbshipit-source-id: 6e82c5270fe5d53f1ed68e167b94f70dc4367a9f
Summary: Apparently, after updating CALayer props we have to request redrowing on top of it manually.
Reviewed By: mdvacca
Differential Revision: D10053340
fbshipit-source-id: f87311399bab809c9e13a3076f526bbe3f7f3fb4
Summary:
Instead of wrapping all public methods into The controller you requested could not be found. blocks/mutexes, RCTSurfacePresenter utilizes a different thread-safety pattern where all instance variable are granularly thread-safe.
The names of all internal methods were prefixed by '_'.
Reviewed By: mdvacca
Differential Revision: D10033407
fbshipit-source-id: 97fd2879c879dd9ef8d9ece24e25af00f749a871
Summary:
There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
Reviewed By: mdvacca
Differential Revision: D9999336
fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
Summary: Besides that it's more simple and straight-forward now, we need that to always instantiate Scheduler with a context full of fresh valid objects derived from the new instance of the bridge.
Reviewed By: mdvacca
Differential Revision: D9995780
fbshipit-source-id: 534a314152d93562b08dd7857962f174b0d06886
Summary:
The original design of RCTSurface implied that the Surface starts on initialization and stops on deallocation. Recently I realized that this not sufficient API in some cases when the application uses ARC with autorelease pools (that can postpone object deallocations, which is highly undesirable).
And that's simply handy to have those methods sometimes.
Reviewed By: mdvacca
Differential Revision: D9982356
fbshipit-source-id: baa3bd24804d3708606ebd00b8795f2d5c9d4de9
Summary: We call this method in a constructor before the actual object is beeing constructed, so it's incorrect; it should be class method.
Reviewed By: mdvacca
Differential Revision: D9931315
fbshipit-source-id: 304ba8e2354f3f408cfa2bf1729266525a08f951
Summary: All integration with Bridge was removed from RCTFabricSurface, now it's Surface's responsibility to start and stop JS app and register the ShadowTree in the Scheduler.
Reviewed By: mdvacca
Differential Revision: D9931317
fbshipit-source-id: 55a682f0afb1c542a904e1a8570029e4690967cc
Summary: Now we have a way to enumerate surfaces stored in RCTSurfaceRegistry.
Reviewed By: mdvacca
Differential Revision: D9931316
fbshipit-source-id: 6b886c4b52cebddf15fef0239190fb2730d682cc
Summary:
Several reasons:
* We are fulfilling a promise that RCTScheduler is just a very thin interop proxy between C++ and Objective-C;
* We have to pass all parameters down to Scheduler anyway, so instead of creating all of them separately and then passing one-by-one, we consolidate them into Context created where we have all those values.
In the future, we probably will move it to some dedicated place.
Reviewed By: mdvacca
Differential Revision: D9884892
fbshipit-source-id: f1d5744e4044bc4bdfe53ec9a97ee61dcf0c60c2
Summary:
RCT_DEBUG is always defined - it is just rather 0 or 1 so
```#ifndef RCT_DEBUG is always true```
Pull Request resolved: https://github.com/facebook/react-native/pull/21232
Differential Revision: D9982316
Pulled By: hramos
fbshipit-source-id: 5408bfcf95a6ed2beae38217a6ad1ee43950857d
Summary:
This PR exposes the `onScrollToTop` event on iOS using the same event-forwarding infrastructure as other ScrollView events. (As such, its `nativeEvent` object reflects the same fields as other ScrollView events.)
Motivation:
----------
If your app is only interested in knowing the position of a ScrollView after a scroll has completed, it can use `onScrollEndDrag` and `onMomentumScrollEnd` to inspect the `contentOffset` after a drag-initiated scroll has finished. (This is much less expensive than observing the `onScroll` event if you only want to know the end position.) However, neither of these `End` events fire if the ScrollView is scrolled to the top by tapping the status bar.
By exposing `onScrollToTop`, it is now possible for an app to cheaply know when such a scroll has completed.
Pull Request resolved: https://github.com/facebook/react-native/pull/21204
Differential Revision: D9943618
Pulled By: hramos
fbshipit-source-id: ac5ee42b7f12d94655ffda617f8f811138da7f6f
Summary: WKWebViews aren't available on Apple TV. When I landed [the WKWebView stack](https://our.intern.facebook.com/intern/diff/D9362001/), I inadvertently broke the RNTester osTV build. This diff fixes it.
Reviewed By: shergin
Differential Revision: D9844322
fbshipit-source-id: 6de0fbfd13aba38cca7530c9fb486c7cde0afc82
Summary: Actual sizes can be found on the offical website.
Reviewed By: fkgozali
Differential Revision: D9837072
fbshipit-source-id: 38b3f2177629e82740eecc8df4566febbe20815a
Summary:
To dispatch events synchonously on the main thread we still have to block the Message Queue.
We actually dispatch events on the Message Queue while the main thread is waiting.
Reviewed By: mdvacca
Differential Revision: D9799853
fbshipit-source-id: 8033be36f27371ad2f1dc7210d564fbca1174910
Summary: In some cases, the custom implementation of this prop is undesirable, so this allows to turn it off.
Reviewed By: yungsters
Differential Revision: D9759228
fbshipit-source-id: 4f61cd900c2da9046977c11a61606a4f5f961177
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Instead of asking existing modules to implement `+allowJSIBinding`, introduce a temporary "empty" protocol so modules can just adopt it for migration purpose.
Eventually this protocol may just go away.
Modules need to adopt both `RCTBridgeModule` and `RCTJSINativeModule` for time being for backward compatibility.
p.s. the entire system isn't enabled yet, this is just some of the pre-reqs for NativeModule improvements.
Reviewed By: mmmulani
Differential Revision: D9762913
fbshipit-source-id: 470f640f11a5991e5cfa9c48a1931da660ebfcd2
Summary:
These files support backing a `WebView` component with the WebKit-based
`WKWebView` on iOS. These files need to be included in the Xcode
build target so that they are compiled, linked and ultimately available
to the UIManager at runtime, so that the correct views can be instantiated
when a `WebView` is passed the prop `useWebKit={true}`.
Pull Request resolved: https://github.com/facebook/react-native/pull/21031
Differential Revision: D9762185
Pulled By: hramos
fbshipit-source-id: 0d699e40afd56041cbbb76d77f11ba6932403d6d
Summary:
* Now all `RCTViewComponentView` subclasses are required to set `_props` instance variable in the constructor with a default value;
* `RCTViewComponentView`'s `_props` instance variable now has `ShadredViewProps` type (that enforced by `static_assert` in `ConcreteViewShadowNode` template);
* New we use `static_pointer_cast` instead of `dynamic_pointer_cast` for casting props.
Reviewed By: mdvacca
Differential Revision: D9734199
fbshipit-source-id: b0a0939c936f8b5b540fa5fa1e4a2f1037346fc5
Summary:
When text nodes are nested, as below, `onPress` handlers need to be correctly invoked:
```
render() {
return (
<Text onPress={() => console.warn('hi')}>
hi
<Text onPress={() => console.warn('ramanpreet')}>ramanpreet</Text>
</Text>
);
}
```
In the above example, clicking on "hi" should warn "hi", and clicking on "ramanpreet" should warn "ramanpreet". This diff implements that behaviour.
Reviewed By: shergin
Differential Revision: D9696905
fbshipit-source-id: 2daf24e76c3b3c37aa36cd1540e54876a367faf7
Summary:
This diff includes two changes:
1. Even though `RCTViewComponentView` conforms to `RCTTouchableComponentViewProtocol`, it never implemented this protocol. This diff makes the correction.
2. Make the necessary changes to `RCTSurfaceTouchHandler` required by the changes in `RCTTouchableComponentViewProtocol`. This means modifying the `ActiveTouch` struct to hold `SharedTouchEventEmitter`s. It also means passing in the touch point to the `componentView`'s `touchEventEmitterAtPoint` method.
Reviewed By: shergin
Differential Revision: D9696909
fbshipit-source-id: 3d4a833f7dbae6d0238a0807eb2220250ccbae3d
Summary:
@public
Besides `pointerEvents` there are other two props that affect hit-testing mechanism: `zIndex` and `clipToBounds`.
The default UIKit implementation does not take this into an account (it always assume that `clipToBounds` is true and `zIndex` is same). `betterHitTest` does it right.
Reviewed By: sahrens
Differential Revision: D9688876
fbshipit-source-id: dadfd5e5541ddd1a744fbd8c6b10949c0e266069
Summary:
@public
In RN we have special `pointerEvents` prop that controls whether the View can be the target of touch events.
This is a pretty straight-forward implementation of that.
Reviewed By: sahrens
Differential Revision: D9688877
fbshipit-source-id: 1524647b0a33e4dd14563f531d636469bf3bdef7
Summary:
@public
Apparently, we have to call `ReactFabric.unmountComponentAtNode(tag)` instead of `AppRegistry.unmountApplicationComponentAtRootTag(tag)`.
Reviewed By: sahrens
Differential Revision: D9652730
fbshipit-source-id: f56dba7dbe5421a7d939b91178db5104476fe550
Summary:
@public
RCTSurfaceRegistry always promised this in the documentation but never actually did.
Reviewed By: sahrens
Differential Revision: D9652732
fbshipit-source-id: f3d06b95192e024273dc0e3a1c2753ca92370338
Summary: Follow up for 0df92afc1c -- the file refences need to be removed from Xcode project.
Reviewed By: shergin
Differential Revision: D9728433
fbshipit-source-id: ed4e69ff14413b1c4e64250c3f9716375d95fbc2
Summary:
@public
Apperently, we don't need to store and parse this because we are already doing this for `yogaStyle` field.
Reviewed By: sahrens
Differential Revision: D9649549
fbshipit-source-id: a84a5518674f4c2d574a060cdbebb9562121f5f4
Summary:
@public
Now all configurations or border styles are supported by RCTViewComponentView (and all subclasses).
Reviewed By: sahrens
Differential Revision: D9631868
fbshipit-source-id: 3a5b141ac5ffa9c28f4ebb0718f2fc935b8f1a75
Summary:
@public
We will use that in RCTFabric module.
Reviewed By: sahrens
Differential Revision: D9631866
fbshipit-source-id: a8e4074189359ad6014d0506d6a1e020b5d0d330
Summary:
@public
Previously, ViewProps class coundn't represent whole spectre of possible values of border metrics (e.g. the border color was unified).
Now it's complete and direction-specific.
Reviewed By: sahrens
Differential Revision: D9628361
fbshipit-source-id: 6d3b3d4d7e3008e2168cbca732ff99fe5ea595e8
Summary:
Legacy navigator impl. There are other alternatives that should be used instead.
Part of the slimmening effort as described here: https://github.com/react-native-community/discussions-and-proposals/issues/6
Reviewed By: TheSavior
Differential Revision: D9677824
fbshipit-source-id: 24ae500751d2a8c398f246d36604a58f0b3c113b
Summary:
D8842691 split AccessibilityTraits into multiple RN properties. However, the accessor code did not support REMOVING traits.
This results in buttons that were disabled (AccessibilityTraits & NotEnabled === true) never being enabled.
Fix the issue by making the split accessors properly mask in the bits, allowing you unset them without disturbing bits managed by the other accessor.
NOTE: setting AccessibilityTraits and AccessibilityRole or AccessibilityStates will still result in bugs.
Reviewed By: shergin
Differential Revision: D9661970
fbshipit-source-id: 77d70dd0754f2eaf8cbf895bfc13757c697a76d8
Summary:
@public
This is quite a big diff but the actual meaningful change is simple: now we use ShadowView class instead of ShadowNode in mutation instructions.
Note:
* In some places (especially during diffing) we have to operate with ShadowNodeViewPair objects (which represents a pair of ShadowNode and ShadowView). The reason for that is that we cannot construct child ShadowViews from parent ShadowViews because they don't have any information about children.
* `ShadowTree::emitLayoutEvents` is now much simpler because ShadowView better represents the specifics of this kind of object.
* The code in RCTMountingManager also became simpler.
This change will allow us to implement more cool tricks soon.
Reviewed By: mdvacca
Differential Revision: D9403564
fbshipit-source-id: dbc7c61af250144d6c7335a01dc30df0005559a2
Summary: Added `snapToStart` and `snapToEnd` props to ScrollView which work together with `snapToOffsets` and determine whether the beginning and end of the list automatically count as snap offsets or not. If not, the list is allowed to free-scroll between its start/end and the first/last snap offset.
Reviewed By: sahrens
Differential Revision: D9442386
fbshipit-source-id: 47a5fdb20f884542434b01b1f0a486ed2b478c6e
Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.
* Fixed pagingEnabled not being overridden by snapToInterval on iOS.
* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.
* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
* Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).
* Added support for snapToInterval.
* Resolves https://github.com/facebook/react-native/issues/19552
Reviewed By: yungsters
Differential Revision: D9405703
fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
