Summary: This diff build the connection between the native code and js code so that the js could get IsRTL value and us ForceRTL function.
Reviewed By: fkgozali
Differential Revision: D3447013
fbshipit-source-id: 9f6c7f71cef0add7bd5beb0ba2b1543f0cabc2b3
Summary:
Issue we were seeing: scrollview would clip its cells when it was resized to 0 height and moved offscreen, but it wouldn't add it back when it was resized and moved back
Why this was happening: scrollview wouldn't rerun its un/clipping logic after the first run unless 1/it has 0x0 frame or 2/it has been scrolled. Neither was happening here.
Fix: run the un/clipping logic when scrollview's frame has been changed since the last clipping.
Reviewed By: javache
Differential Revision: D3436996
fbshipit-source-id: 1a8cfeb72b425fcc80815d30743fa308b9c75ab6
Summary: Converted the zIndex property on iOS to NSInteger instead of double. This is consistent with the CSS spec, and helps to simplify the Android implementation.
Reviewed By: javache
Differential Revision: D3411491
fbshipit-source-id: 902ebc29aac39a65f7e8707a28607655f9f5052c
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
The `removeClippedSubviews` feature works by umounting views from the hierarchy if they move outside the bounds of their parent.
This was previously restricted to clipping views which had `overflow: hidden`, since we cannot efficiently check whether the subviews of a view go outside its bounds, and so clipping a view that has potentially overflowing children becomes an expensive recursive operation.
The problem with this is that `overflow: visible` is the default, and it's not well documented nor easy to tell that `removeClippedSubviews` has been set up correctly (i.e. with all children having `overflow: hidden`).
When I checked, I found that `removeClippedSubviews` was not working on any of the examples in UIExplorer, nor in several of our internal apps, because the views inside the ListView has `overflow: visible`. This was probably caused by an infra change at some point, but I'm not sure how long it's been broken.
It's vanishingly unlikely that anyone would ever deliberately want subviews to overflow their bounds in this scenario, so I've updated the logic to simply ignore the `overflow` property and assume that views should be clipped if you are using the `removeClippedSubviews` property on the parent.
Cons / Breaking changes: in some rare circumstances, a view might get clipped prematurely if its parent is outside the scrollview bounds, but it itself is inside. This doesn't occur in practice in any of our products, and could be worked around with additional wrapper views if it did.
Pros: removeClippedSubviews is now much easier to use, and much more likely to work as intended, so most list-based apps should see a performance improvement.
Reviewed By: javache
Differential Revision: D3385316
fbshipit-source-id: 1c0064a4c21340a971ba80d794062a356ae6cfb3
Summary:
RCTScrollView was calling `dockClosestSectionHeader` in `reactBridgeDidFinishTransaction`, which triggers a layout update. The reason for this was in case the `stickyHeaderIndexes` property was updated, which would require the headers to be adjusted.
However, doing this in `reactBridgeDidFinishTransaction` had the affect of causing `layoutSubviews` to be called repeatedly every frame even if nothing had changed and the scrollview wasn't moving, which was especially expensive when combined with the `removeClippedSubviews` logic, that loops through every view to calculate if it needs to be clipped.
This fix moves the `dockClosestSectionHeader` call into `didUpdateProps`, and checks that the stickyHeaderIndexes have actually changed before calling it.
Reviewed By: javache
Differential Revision: D3387607
fbshipit-source-id: c71e00c6fac48337a63d7fee7c7c23e016acf24e
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
Hey,
I've created a PR a few weeks ago #7264. It got merged in and then I received some emails and got mentioned in a few issues that it doesn't use renderAsOriginal prop on selectedIcon. Instead the app would use tint color.
The problem can be seen here #7467.
I've now added a method in TabBarItem that sets selectedIcon to renderAsOriginal if the prop is set.
I added a "relay" icon to UIExplorer TabBarIOS example so you can see the item is now rendered in color as the image supplied.
Oh and also should this PR be made from master. Had to work on this issue from 0.27 because the master was broken for me.
Closes https://github.com/facebook/react-native/pull/7709
Differential Revision: D3339795
fbshipit-source-id: d8d4699bb617ecae8996a6627f3774c6473c19e0
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
The default itemPositioning is `automatic` (referred to `auto` in this pull request) - you can check its behaviour in the docs attached.
Sometimes that value has to be modified to have more predictable appearance as described in #4136.
Closes https://github.com/facebook/react-native/pull/7217
Differential Revision: D3220958
Pulled By: mkonicek
fbshipit-source-id: d4bf648b16e71825cd31c06d6b6396479767d19f
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary: Having UI modules access the shadowQueue via UIManager.methodQueue is fragile and leads to race conditions in startup, sometimes resulting in an error where the methodQueue is set twice, or not at all.
Reviewed By: javache
Differential Revision: D3304890
fbshipit-source-id: 7198d28314dbec798877fcaaf17ae017d50157e9
Summary:
There's an edge case in the `RefreshControl` which causes it to show as refreshing when the state is set to false. When the component is initialized with `refreshing` set to `true` on initial render but set to `false` before `layoutSubviews` is called, it will call `beginRefresh` and ignore its state. That's because `layoutSubviews` never checks if `_currentRefreshingState` is in fact still `true`, it merely assumes it is.
This is fixed by simply doing a check for `_currentRefreshingState` before entering `beginRefresh` from `layoutSubviews`.
Closes https://github.com/facebook/react-native/pull/7556
Differential Revision: D3300124
fbshipit-source-id: d1dce8612e2c03b1f14284d513803d00af4b5c8a
Summary: We are deprecating nativeScrollDelegate property in RCTScrollableProtocol in favor of a scrollListener api. To register/unregister from scroll events use the addScrollListener/removeScrollListener methods
Reviewed By: javache
Differential Revision: D3278218
fbshipit-source-id: 54373cae8e9f8efa7cdbd40c51bcf21d368acf75
Summary:
Previously we had an issue where we would clip visible views during an animation, like swiping back a VC.
The root cause was mismatch between a view's frame and what is visible on screen. This happens because during an animation the frame (and other properties) of the animated view has final values, even that it's not yet rendered at that position.
This diff fixes this issue by not looking for a clippingView above the react root view, since the animation for VC transitions happens at view higher above the root view.
Reviewed By: javache
Differential Revision: D3281655
fbshipit-source-id: 996b1a9f223c5b2274dd3d7c05b8936612af05ba
Summary:
When throttling scroll events with `scrollEventThrottle`, `onScroll`
is not guaranteed to be fired for the final scroll position
of the `ScrollView`. This can cause a component to render UI that
is consistent with the resting scroll position of the `ScrollView`.
This commit guarantees that an `onScroll` event will be fired for
the resting scroll position of the `ScrollView`.
**Test plan (required)**
Verified commit fixes a reduced repro. Also tested fix in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7366
Differential Revision: D3269303
Pulled By: javache
fb-gh-sync-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
fbshipit-source-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
Summary:
Previously, the back swipe navigation gesture would be enabled when the navigation bar is shown and disabled when the navigation bar is hidden.
This change enables developers to control the back swipe gesture independently of the visibility of the navigation bar. An example use case would be that an app wants to render a custom navigation bar so it sets `navigationBarHidden` to true and it wants to enable the back swipe gesture so it sets `interactivePopGestureEnabled` to true.
**Test plan (required)**
- Created a test app to verify setting `interactivePopGestureEnabled` to `true` and `false` with the navigation bar both hidden and shown.
- Verified prop works in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7369
Differential Revision: D3269304
Pulled By: javache
fb-gh-sync-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
fbshipit-source-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
Summary:
Previously, if a module implemented `setBridge:` we assumed that it needs to be initialised on the main thread. This assumption was not really warranted however, and it was a barrier to deferring module initialization.
This diff tweaks the rules so that only modules that override `init` or `constantsToExport**` are assumed to require main thread initialization, and others can be created lazily when they are first used.
WARNING: this will be a breaking change to any 3rd party modules that are assuming `setBridge:` is called on the main thread. Those modules should be rewritten to move any code that requires the main thread into `init` or `constantsToExport` instead.
`**` We will also be examining whether `constantsToExport` can be done lazily, but for now any module that uses it will still be created eagerly when the bridge starts up.
Reviewed By: javache
Differential Revision: D3240682
fb-gh-sync-id: 48f309e3158bbccb52141032baf70def3e609371
fbshipit-source-id: 48f309e3158bbccb52141032baf70def3e609371
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
Or change it to yellow for demonstrating purposes
works cross platform.
decomposedMatrix could technically be passed on Android but it wasn't document and explicitly flagged as not working.
My goal is to deprecate both uses and then the only supported API is the `transform: [{ matrix: ... }]` form.
The only difference is that on Android the matrix gets decomposed.
Currently there is some special cased magic that renames transform -> transformMatrix or decomposedMatrix depending on platform.
https://github.com/facebook/react/blob/master/src/renderers/native/ReactNative/ReactNativeAttributePayload.js#L50
Therefore I'm adding an alias for both native platforms called just "transform".
Next I'll swap over the JS to always target the name "transform". The only difference is how the value is marshalled over the bridge in processTransform.
To do this, I have to clean up a few callers. Mostly that's just swapping to the new API.
For buildInterpolator this is a bit trickier but this fixes it for all our use cases (which is only the Navigator in AdsManager).
Reviewed By: vjeux
Differential Revision: D3239960
fb-gh-sync-id: 838edb6644c6cdd0716834f712042f226ff3136f
fbshipit-source-id: 838edb6644c6cdd0716834f712042f226ff3136f
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary: Creating a view instance just to get the default view size is quite expensive, and affects startup time for the bridge as it must be done on the main thread. I've removed these cases and simply hard-coded the sizes in the JS file. This will need to be updated if the view sizes ever change, but in practice that's very unlikely.
Reviewed By: javache
Differential Revision: D3218917
fb-gh-sync-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
fbshipit-source-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
Summary: fixed a case where MapView could crash due to a race condition
Differential Revision: D3207304
fb-gh-sync-id: a63918d160258d76fce5d56994100a63f4c5fb68
fbshipit-source-id: a63918d160258d76fce5d56994100a63f4c5fb68
Summary:**Motivation:** In my app, I'm using a WebView that loads content from my mobile site. What I want to do is when a user presses a link on the loaded page, I want to stop the WebView's request, hijack the URL and open the URL in a new WebView, pushed to the top of the navigator stack. To me, this gives the overall app a more native feel, instead of implementing a rudimentary navbar on the main WebView to go back.
**Attempted Workarounds:** I've attempted to get similar functionality by capturing the onNavigationStateChange event in the WebView, and then within calling goBack + pushing the new view to the navigator stack. From a functionality standpoint, this works. However, from a UI standpoint, the user can clearly see the webview change states to a new page + go back before having the new view pushed on top of their nav stack.
Closes https://github.com/facebook/react-native/pull/6886
Differential Revision: D3212447
Pulled By: mkonicek
fb-gh-sync-id: 05911e583d9ba54ddbd54a772153c80ed227731e
fbshipit-source-id: 05911e583d9ba54ddbd54a772153c80ed227731e
Summary:We had an issue where a rendered modal would not end up using the full screen size, but a size computed based on its initial content.
Which is a small spinner in case of RelayContainer. So rarely we would end up with cut off view like this:
{F60650629}
This diff fixes this behavior by wrapping the content in another view. That makes the modal's wrapping VC's view resize just once when it's initially created. (Resize for the wrapping VC's view happened previously when the modal's content resized, which got us in the bad state.)
Reviewed By: javache
Differential Revision: D3202299
fb-gh-sync-id: 7c4dc1dbb27654292d07aef5916aa31df5cd4302
fbshipit-source-id: 7c4dc1dbb27654292d07aef5916aa31df5cd4302
Summary: Under some circumstances, the calloutIndex might be > number of callout views, (possibly due to a race condition?). This prevents that from crashing.
Reviewed By: tadeuzagallo
Differential Revision: D3196010
fb-gh-sync-id: 6485e64c682937431cb8598d7f3f42e8d37eeff1
fbshipit-source-id: 6485e64c682937431cb8598d7f3f42e8d37eeff1
Summary: `RCTComponentData` needs `RCTConvert` class, but it doesn't import it directly. This diff is changing it. Should be noop.
Reviewed By: fkgozali
Differential Revision: D3185141
fb-gh-sync-id: f845e3555d30c9fd9b39579194590ddf103a5a19
fbshipit-source-id: f845e3555d30c9fd9b39579194590ddf103a5a19
Summary:To use a ScrollView and RefreshControl with a translucent navigation bar you have to set the top inset to the height of that bar, allowing the content to scroll underneath. After changes to RCTRefreshControl in **v0.22**, `endRefreshing` always animates the offset to 0, hiding content behind the navigation bar. What you'd expect on iOS is for it to return to the bottom of the bar.
**Test plan**
To see this in action, refer to the UIExplorerApp. In RefreshControlExample.js if you set the ScrollView's `contentInset={{top: 100}}` you'll see the refresh control UI is where you'd expect, and after refresh the list returns to the correct position.
Closes https://github.com/facebook/react-native/pull/6848
Differential Revision: D3157934
Pulled By: mkonicek
fb-gh-sync-id: c2186a4541fb3988677f0851eb12c259cd003750
fbshipit-source-id: c2186a4541fb3988677f0851eb12c259cd003750
Summary:On iOS, `WebView` will get stuck when the first request fails to load. The most common case where this could happen is when a user has limited or no connectivity.
Here's a repo with a sample app that demonstrates the problem and this fix: [https://github.com/jballer/react-native-webview-reload-example](https://github.com/jballer/react-native-webview-reload-example).
**Attempted workarounds**
- `WebView.reload()` fails internally because the `UIWebView`'s `currentRequest` doesn't have its `URL` set
- Setting `WebView.source.uri` won't do anything; the JS value value is unchanged and therefore doesn't cross the native bridge.
- Unmounting and remounting the `WebView` component would lose history and context if an error occurs on a request that's not the first request.
**Test plan (manual testing)**
1. Disable network connection
1. Relaunch application or reload JS
1. Enable network connection
1. Tap "reload" button
1. Observe whether page reloads
Closes https://github.com/facebook/react-native/pull/6873
Differential Revision: D3159219
Pulled By: javache
fb-gh-sync-id: 8893dd20dc9f4a1a00d14a488ce657cc50287a29
fbshipit-source-id: 8893dd20dc9f4a1a00d14a488ce657cc50287a29
Summary:Update to latest master version of css-layout. Update integration in RCTShadow(Root)View to match.
This solves the issue with items not strechting vertically in column layouts (https://github.com/facebook/css-layout/issues/127)
Reviewed By: vjeux
Differential Revision: D3120699
fb-gh-sync-id: beba162e1255d3527e1160e9bd414a712cb10713
fbshipit-source-id: beba162e1255d3527e1160e9bd414a712cb10713
Summary:A need for sending a scroll events outside of scrollview made D3092854 a bit clunky. This diff kinda fixes it by tightening up emitting of fake scroll events just to the only usecase we have right now.
Why not just simply construct the event in `RCTNavigator`, so we can drop the code from `RCTScrollView` altogether?
`RCTScrollEvent` is private to `RCTScrollView`, and that's good. We don't want anyone have an ability to make up scroll events. Even this existing functionality should be sunset one day when we better integrate with native gesture recognizers.
Depends on D3092867.
Reviewed By: javache
Differential Revision: D3120751
fb-gh-sync-id: 6519c055b983cfd48c4b4a9d619c4452e12efda1
fbshipit-source-id: 6519c055b983cfd48c4b4a9d619c4452e12efda1
Summary: This was previously removed in D2884587, but we will need it going forward. See D3092867 for reasons why it's necessary again.
Reviewed By: javache
Differential Revision: D3092848
fb-gh-sync-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
fbshipit-source-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:Just added a pass through to the `WebView` for `mediaPlaybackRequiresUserAction` and `setMediaPlaybackRequiresUserGesture` to allow auto-playing audio and video elements
Closes https://github.com/facebook/react-native/pull/5956
Differential Revision: D3053554
Pulled By: mkonicek
fb-gh-sync-id: a1f362c1551de1a0218f5d23c70668e4c8078993
shipit-source-id: a1f362c1551de1a0218f5d23c70668e4c8078993
Summary: In my recent refactor to remove defaultViews, I added a check for null json values to determine if defaultView needed to be created. Unfortunately this was checking for nil instead of NSNull.
Reviewed By: javache
Differential Revision: D3058383
fb-gh-sync-id: 2a21dd0beb0302a94ed5379d39a102cde1316a9d
shipit-source-id: 2a21dd0beb0302a94ed5379d39a102cde1316a9d
Summary:In order to ensure that the docked sticky header in a ListView receives touches correctly, RCTScrollView has a custom hitTest implementation that checks the sticky headers for touches prior to checking any other views.
There was a bug in this implementation that meant that sticky views would get touch priority even if the touch was outside the bounds of the scrollView. This meant that sticky headers that scrolled off the top of the list would intercept touches intended for views placed above the scrollView.
This diff fixes that bug by checking that the touch is inside the scrollview before checking for sticky header touches. I've also limited the custom hit test logic to just the currently docked header, as the other sticky header views do not require special treatment.
Reviewed By: javache
Differential Revision: D3041236
fb-gh-sync-id: a2a3474dda03d5b51688bd575195a67956184bbe
shipit-source-id: a2a3474dda03d5b51688bd575195a67956184bbe
Summary:Currently, an empty `<ScrollView />` on iOS always throws the warning "Sticky header index 0 was outside the range {0, 0}".
This is because the error-reporting code relies on the assumption that `stickyHeaderIndices` exists, and when it doesn't the error check thinks there's an index when there really isn't.
Note that this only changes error reporting and won't affect apps out of debug mode.
**Test plan**
I created a sample app and included an empty `<ScrollView />`. Without this change the "Sticky header..." warning was displayed on every run through. With this change implemented, the warning went away.
Closes https://github.com/facebook/react-native/pull/6417
Differential Revision: D3042178
Pulled By: nicklockwood
fb-gh-sync-id: 7afefd428a5fcb03867bcb69e46c46fe1ae9151e
shipit-source-id: 7afefd428a5fcb03867bcb69e46c46fe1ae9151e
Summary: The exportedConstants method incurrs a penalty at bridge startup time for every module that implements it. This diff removes exportedConstants from a few modules that don't really need to use it.
Reviewed By: majak
Differential Revision: D2982341
fb-gh-sync-id: be016187d7b731a073311daacfcf88a0402e1688
shipit-source-id: be016187d7b731a073311daacfcf88a0402e1688
Summary:When a component prop is set to null/undefined, and doesn't have a default value specified in `getDefaultProps`, the null value is sent over the bridge as a sentinel to reset to the original native value.
On iOS this is handled by creating a default view instance for each view type. The default view is then used to look up the unmodified value for any prop that is reset.
This is rather expensive however, as it means that for complex views (e.g. WebView, MapView), a minimum of two instances will be created even if only one is needed, and the default view will remain even after all actual view instances have been released.
This diff replaces the default view mechanism with a system where the default value of each prop is recorded the first time it is set. This avoids the need to keep an extra copy of the whole view.
The only exception is for props that use the `RCT_CUSTOM_VIEW_PROPERTY` macro, which includes the default view as part of the interface. To avoid a breaking change, a default view will still be created for views that use this macro, but only if they are sent a null value (so very rarely, in practice). In a future update we may deprecate or replace `RCT_CUSTOM_VIEW_PROPERTY` if there are significant benefits to doing so.
Reviewed By: javache
Differential Revision: D3012115
fb-gh-sync-id: 259348e54aa8342f444ad182b6f883d2dd684973
shipit-source-id: 259348e54aa8342f444ad182b6f883d2dd684973
Summary:Fixes the RefreshControl layout after a screen rotation. See #6311 for a more detailed explanation. I fixed it by adjusting the frame of the RefreshControl in `layoutSubviews` of the parent ScrollView.
While working on fixing this I noticed that when doing a 'pull to refresh' and then not scrolling and wait for it to end the next one will not behave like the first one (it will require pulling further down for the spinner to start spinning). I fixed that too by scrolling the scrollview back to 0 manually before calling `UIRefreshControl.endRefreshing`.
**Test plan (required)**
Tested using the UIExplorer RefreshControl example.
When doing a pull to refresh and then rotating the screen the RefreshControl must stay positioned properly.
Doing multiple consecutive pull to refresh without scrolling after should all behave the same.
Fixes#6311
Closes https://github.com/facebook/react-native/pull/6359
Differential Revision: D3023727
fb-gh-sync-id: f50ae52ea769c2b3e5025c362544a8809a71aa00
shipit-source-id: f50ae52ea769c2b3e5025c362544a8809a71aa00
Summary: This diff adds support for initializing the bridge on an arbitrary thread. This is helpful if you want to defer bridge creation, or prevent it from delaying your app startup.
Reviewed By: javache
Differential Revision: D2965725
fb-gh-sync-id: 8065fa89e850031c72ee4427351300986985e9de
shipit-source-id: 8065fa89e850031c72ee4427351300986985e9de
Summary: Added ability to include a callback to the modal. The callback is invoked when the modal is shown.
Reviewed By: javache
Differential Revision: D3005212
fb-gh-sync-id: 12648e17bd1cf831daf65529b87ae8cfdb901c65
shipit-source-id: 12648e17bd1cf831daf65529b87ae8cfdb901c65
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:The UICollectionView example is actually my use-case, which is discussed in a
bit more detail [here](https://github.com/alloy/ReactNativeExperiments/issues/2).
----
This is useful when wrapping native iOS components that determine their
own suggested size and which would be too hard/unnecessary to replicate
in the shadow view. For instance a `UICollectionView` that after layout
will update its `contentSize`, which could be used to suggest a size to
the shadow view.
The reason for adding it to -[RCTShadowView setFrame:] is mainly so it
can be used via the existing -[RCTUIManager setFrame:forView:] API and
because it might not be a feature you want to expose too prominently.
An origin of `{ NAN, NAN }` is used as a sentinel to indicate that the
frame should be used as a size suggestion. The size portion of the rect
may contain a `NAN` to skip that dimension or a suggested value for the
dimension which will be used if no explicit styling has been assigned.
Examples:
* Without any expl
Closes https://github.com/facebook/react-native/pull/6114
Differential Revision: D2994796
Pulled By: nicklockwood
fb-gh-sync-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
shipit-source-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
Summary: Fixed broken scaling logic in Webview example for iOS. Pages must be reloaded after toggling `scalesPageToFit`, but that wasn't happening.
Reviewed By: javache
Differential Revision: D2982371
fb-gh-sync-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
shipit-source-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
Summary:The `uiBlockToAmendWithShadowViewRegistry:` is called on every single view manager, on every single layout pass. This causes all view managers to be eagerly intiialized, even if not being used.
In practice very few modules actually use this method, so by checking if the method is implemented before calling it, we can eliminate most of this work.
(Hopefully in future we can get ride of this method altogether, but right now it's integral to the way that text layout is implemented).
Reviewed By: majak, javache
Differential Revision: D2982181
fb-gh-sync-id: 818d0aac61197df89263c919c2c80a003e293ac5
shipit-source-id: 818d0aac61197df89263c919c2c80a003e293ac5
Summary: When rotating on iPad, the dev loading view just looks clowny since it doesn't rotate properly.
Reviewed By: majak
Differential Revision: D2939721
fb-gh-sync-id: 7f1926f5cee4761cde8881e9387ae6e0063c5d6c
shipit-source-id: 7f1926f5cee4761cde8881e9387ae6e0063c5d6c
Summary: When rotating a modal view we should adjust the root view's frame.
Reviewed By: majak
Differential Revision: D2939712
fb-gh-sync-id: 974634276d2c0ad22b46976020d0a21e1dac9026
shipit-source-id: 974634276d2c0ad22b46976020d0a21e1dac9026
Summary:The bug is caused by a weird race condition. What happens is that when calling `UIRefreshControl#endRefreshing` the `UIScrollView` delegate `scrollViewDidScroll` function is called synchronously and then `dockClosestSectionHeader` crashes because the sticky header indexes are updated but not the contentView children.
I fixed it by adding an updating property on `RCTRefreshControl` and setting it before calling `endRefreshing` so we can know not to call `dockClosestSectionHeader` at that moment.
Tested with both `RefreshControl` and `onRefreshStart` prop.
I reproduced the bug by replacing ListViewExample.js in UIExplorer with https://gist.github.com/janicduplessis/05fc58e852f3e80e51b9Fixes#5440
cc nicklockwood
Closes https://github.com/facebook/react-native/pull/5445
Differential Revision: D2953984
Pulled By: nicklockwood
fb-gh-sync-id: c17a6a75ab31ef54d478706ed17a8115a11d734e
shipit-source-id: c17a6a75ab31ef54d478706ed17a8115a11d734e
Summary:New prop `hitSlop` allows extending the touch area of Touchable components. This makes it easier to touch small buttons without needing to change your styles.
It takes `top`, `bottom`, `left`, and `right` same as the `pressRetentionOffset` prop. When a touch is moved, `hitSlop` is combined with `pressRetentionOffset` to determine how far the touch can move off the button before deactivating the button.
On Android I had to add a new file `ids.xml` to generate a unique ID to use for the tag where I store the `hitSlop` state. The iOS side is more straightforward.
terribleben worked on the iOS and JS parts of this diff.
Fixes#110
Closes https://github.com/facebook/react-native/pull/5720
Differential Revision: D2941671
Pulled By: androidtrunkagent
fb-gh-sync-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194
shipit-source-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194
Summary:
RefreshControl did not start refreshing when refreshing was set to true initially. It also did not start refreshing on iOS when setting the prop from false to true without doing a pull to refresh gesture.
This was a pain in the ass to make work on iOS because UIRefreshControl seems super sensitive to when beginRefreshing can be called, for the initial render I need to call it in layoutSubviews. I also have to manually adjust the scrollview content offset when calling beginRefreshing. The code is a bit hacky but it was the only solution I found that was actually working.
Fixes#5716
Closes https://github.com/facebook/react-native/pull/5745
Reviewed By: svcscm
Differential Revision: D2910716
Pulled By: nicklockwood
fb-gh-sync-id: d60e73bcfe8d86bb01249ba5f17e6a23c5a5aff6
Summary:
When scrolling while RefreshControl is refreshing the sticky headers are offset by the height of the UIRefreshControl. This simply removes the height of the UIRefreshControl while it is refreshing and fixes the problem.
You can repro the bug using this example in UIExplorer by doing a pull to refresh and scrolling the ListView immediately after.
https://gist.github.com/janicduplessis/26b4f2758e90b2aa1620Fixes#5405
Closes https://github.com/facebook/react-native/pull/5517
Reviewed By: svcscm
Differential Revision: D2895623
Pulled By: nicklockwood
fb-gh-sync-id: 81df36cccfc3e7b973c2be78565f8b8408c9fc12
Summary:
I want to use the `RCTEvent` protocol for touch events as well. That's why I'm removing not very well defined `body` property and replacing it with `arguments` method, which will return an array that will be passed directly to the js call.
I think this makes sense because there is no unified arguments format for all events and and the called js method (`moduleDotMethod`) is already event specific.
This way touch events and scroll events can result in calling a completely different js function with a completely different arguments (what they indeed currently do).
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884590
fb-gh-sync-id: 2c1885c3414e255d8572c0fbbbfe62a23d94dd06
Summary:
This property was never used, so I'm removing it.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: javache
Differential Revision: D2884587
fb-gh-sync-id: acd5e576cd13a02e77225f3b308232f8331d3b61
Summary:
public
https://github.com/facebook/react-native/pull/5494 added a new `source` property to WebView on Android that provides a better API, as well as allowing for request headers to be set.
This diff ports that functionality over to iOS, so we can have a consistent API cross-platform.
I've also extended the API to include `method` (GET or POST) and `body` when setting the WebView content with a URI, and `baseUrl` when setting static HTML.
Reviewed By: javache
Differential Revision: D2884643
fb-gh-sync-id: 83f24494bdbb4e1408aa8f3b7428fee33888ae3a
Summary:
public
My refactor to unify the scrollTo() apis on iOS + Android broke iOS. Oops.
Reviewed By: jingc
Differential Revision: D2886305
fb-gh-sync-id: de287cba8df7cf14c8049d91621cd7f86aa4e92c
Summary:
For my project it was required to receive a notification when the MapView annotation was deselected.
So I renamed `onAnnotationPress` to `onAnnotationSelected` and added a new method `onAnnotationDeselected`, this names was "inspired" by the underlaying iOS API. The old API was still called and marked as deprecated.
But maybe you have an idea for a better naming (onAnnotationFocus/-Blur?) -- or should a deselected call the press method again without an annotation (undefined)?
Closes https://github.com/facebook/react-native/pull/5167
Reviewed By: svcscm
Differential Revision: D2869695
Pulled By: nicklockwood
fb-gh-sync-id: 91795ac3f1e4533b250af8901534d8870729d9db
Summary:
Expose a `decelerationNormalEnabled` flag on WebView, which, when enabled, will WebView's ScrollView's `decelerationRate` to `UIScrollViewDecelerationRateNormal`. This gives the WebView the same "momentum" style scrolling as other iOS views.
This was discussed with ide in #5447. Please let me know if there's anything I'm missing, or anything else you'd like to see in this pull request.
Closes https://github.com/facebook/react-native/pull/5527
Reviewed By: svcscm
Differential Revision: D2870312
Pulled By: nicklockwood
fb-gh-sync-id: 7dbfd06a349e3365a5df40c3bacf25a4fdb306cf
Summary:
An initial implementation was done on css-layout but isn't working correctly on many cases. The binding from React Native has been removed a long time ago. Let's not confuse people and remove it from the docs :)
Closes https://github.com/facebook/react-native/pull/5522
Reviewed By: svcscm
Differential Revision: D2859665
Pulled By: vjeux
fb-gh-sync-id: 4aa008dd93a6cea6b79a7bce444c94148791eee4
Summary:
public
This diff improves the implementation of 3D touch by adding a `forceTouchAvailable` constant to View that can be used to check if the feature is supported.
I've also added an example of how you can use the `force` property of the touch event to measure touch pressure in React Native.
Reviewed By: vjeux
Differential Revision: D2864926
fb-gh-sync-id: 754c54989212ce4e4863716ceaba59673f0bb29d
Summary:
I am using ReactNative in a hybrid App.
We have a setup like so:
Native Navigation Controller
Native Tab Controller
Native View Controller wrapping React
React Navigation Controller
React View Controller 1
React View Controller 2
Native View Controller 2.
When I pop Native View Controller 2 off the Navigation stack, I get a seg fault on this line:
NSUInteger indexOfFrom = [_currentViews indexOfObject:fromController.navItem];
I believe what's happening:
Your code is listening to Nav Controller transitions, assuming that they are all from React Native Nav Controllers.
You are catching this one instead, which is actually a Native Nav Controller transition.
You start trying to access the pushed/popped view controllers as if they were react native view controllers.
In this case, the view controllers are not react native -> no navItem field -> seg fault.
Solution: if we are catching this transition but it isn't from our react native nav controller, just
Closes https://github.com/facebook/react-native/pull/5495
Reviewed By: svcscm
Differential Revision: D2857473
Pulled By: nicklockwood
fb-gh-sync-id: cc7f0a16e2e0cea56ca9e49bcb87db4ebd3a0905
Summary:
public
Standardises the image decoding logic for all image sources, meaning we get the benefits of efficient downscaling of images from all sources, not just ALAssets.
Reviewed By: javache
Differential Revision: D2647083
fb-gh-sync-id: e41456f838e4c6ab709b1c1523f651a86ff6e623
Summary:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
public
React Native currently exposes the iOS layer shadow properties more-or-less directly, however there are a number of problems with this:
1) Performance when using these properties is poor by default. That's because iOS calculates the shadow by getting the exact pixel mask of the view, including any tranlucent content, and all of its subviews, which is very CPU and GPU-intensive.
2) The iOS shadow properties do not match the syntax or semantics of the CSS box-shadow standard, and are unlikely to be possible to implement on Android.
3) We don't expose the `layer.shadowPath` property, which is crucial to getting good performance out of layer shadows.
This diff solves problem number 1) by implementing a default `shadowPath` that matches the view border for views with an opaque background. This improves the performance of shadows by optimizing for the common usage case. I've also reinstated background color propagation for views which have shadow props - this should help ensure that this best-case scenario occurs more often.
For views with an explicit transparent background, the shadow will continue to work as it did before ( `shadowPath` will be left unset, and the shadow will be derived exactly from the pixels of the view and its subviews). This is the worst-case path for performance, however, so you should avoid it unless absolutely necessary. **Support for this may be disabled by default in future, or dropped altogether.**
For translucent images, it is suggested that you bake the shadow into the image itself, or use another mechanism to pre-generate the shadow. For text shadows, you should use the textShadow properties, which work cross-platform and have much better performance.
Problem number 2) will be solved in a future diff, possibly by renaming the iOS shadowXXX properties to boxShadowXXX, and changing the syntax and semantics to match the CSS standards.
Problem number 3) is now mostly moot, since we generate the shadowPath automatically. In future, we may provide an iOS-specific prop to set the path explicitly if there's a demand for more precise control of the shadow.
Reviewed By: weicool
Differential Revision: D2827581
fb-gh-sync-id: 853aa018e1d61d5f88304c6fc1b78f9d7e739804
Summary:
public
This diff deprecates `scrollResponderScrollWithoutAnimationTo` and replaces it with an optional `animated` param in `scrollResponderScrollTo`. This is more consistent with our other APIs.
Using the old `ScrollResponder.scrollResponderScrollWithoutAnimationTo` or `ScrollView.scrollWithoutAnimationTo` functions will still work, but will trigger a warning.
Reviewed By: javache
Differential Revision: D2823479
fb-gh-sync-id: 259966512104ca7b3995c9586144812a91b8d3e9
Summary:
public
The fix for border smearing introduced a bug where borders + background would sometimes not be rendered if the view was created at a small size (e.g. zero) and then resized.
This diff fixes that by redrawing the border if the view size changes. There is some opportunity to optimize this in future by performing some logic up-front to detect if the redrawing is necessary, but I thought I'd keep it simple for this bug fix rather than risk introducing further bugs.
Reviewed By: jingc
Differential Revision: D2817365
fb-gh-sync-id: eca164e8ce03a66598677c9e05496791230b5210
Summary:
public
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just `<Image/>` and `<Text/>` components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except `<Text/>` nodes. It might still be useful for `<Image/>` nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
Note that this diff does not prevent you from eliminating blending on image components by manually setting an opaque background color, nor does it stop you from disabling color propagation on text components by manually setting a transparent background.
Reviewed By: javache
Differential Revision: D2811031
fb-gh-sync-id: 2eb08918c9031c582a3dd2d40e04b27a663dac82
Summary:
public
The iOS border rendering code did not follow the CSS spec in cases where the sum of adjacent border radii was greater than the width of the view, resulting in drawing glitches such as pixel smear and borders appearing stretched or squashed.
This diff brings our implementation closer to spec-compliance in these cases. I also fixed a longstanding issue with ghostly diagonal lines appearing at the corners due to antialiasing rounding errors!
Fixes
https://github.com/facebook/react-native/issues/1572https://github.com/facebook/react-native/issues/2089https://github.com/facebook/react-native/issues/4604
Reviewed By: tadeuzagallo
Differential Revision: D2811249
fb-gh-sync-id: c3dd2721e0a01a432fa4dc78daa05680595edd08
Summary:
Both iOS and Android currently support some sort of native pull to refresh control but the API was very different. I tried implementing a component based on PullToRefreshViewAndroid but that works on both platforms.
I liked the idea of wrapping the ListView or ScrollView with the PullToRefreshView component and allow styling the refresh view with platform specific props if needed. I also like the fact that 'refreshing' is a controlled prop so there is no need to keep a ref to the component or to the stopRefreshing function.
It is a pretty rough start so I'm looking for feedback and ideas to improve on the API before cleaning up everything.
On iOS we could probably deprecate the onRefreshStart property of the ScrollView and implement the native stuff in a PullToRefreshViewManager. We could then add props to customize the look of the UIRefreshControl (tintColor). We could also deprecate the Android only component and remove it later.
Closes https://github.com/facebook/react-native/pull/4915
Reviewed By: svcscm
Differential Revision: D2799246
Pulled By: nicklockwood
fb-gh-sync-id: 75872c12143ddbc05cc91900ab4612e477ca5765
Pieter De Baets
alvaromb
Mengjue Wang
Martin Kralik
Clement Genzmer
Nick Lockwood
Gerald Monaco
Adam Comella
Emil Sjolander
Janic Duplessis
Urban Cvek
Mike Grabowski
Arno Fortelny
Reem Helou
Sebastian Markbage
Jesse Sessler
Labeeb Panampullan
Andrew Gray
Li Jie
Sokovikov
skellyb
Jonathan Ballerano
Satish Sampath
Thomas Beverley
Kyle Corbitt
Eric Lo
Eloy Durán
Jesse Ruder
Ian Cervantez
Christoph Jerolimov
August Flanagan
Christopher Chedeau
Jean Regisser
tuyou
DougBanksPersonal
Gaëtan Renaudeau
Quentin Valmori
Jason Brown
