Summary: This can be used to create a JavaScript thread and `JSContext` in advance, then supply them to the `RCTJSCExecutor` at creation time later.
Reviewed By: javache
Differential Revision: D3534553
fbshipit-source-id: 99ccf711928cd12e84c9fbe142c6d19a7af55d07
Summary: This was left over from a previous change.
Reviewed By: javache
Differential Revision: D3534376
fbshipit-source-id: 6932364d1c32d8fbdf56c642893f9ea5e6dc1fee
Summary:
https://github.com/facebook/css-layout/pull/199
- Nodes were measured with the assumption of being text nodes (height depends on width) when determining flex basis. This is not always true. Even when we are just interested in the main axis (flex basis) we need to correctly constrain the cross axis.
- Some tests were wrong. Measuring texts.big and expecting it to have textSizes.smallHeight which doesn't make a lot of sense.
Reviewed By: vjeux
Differential Revision: D3510163
fbshipit-source-id: ee53b548dd078005fdd153d279e4c7fef3dd02d0
Summary:
In practice, it *MUST* be the call to `self.context` within `setUp` that triggers the creation of the context:
- It can't come before that point because `_jscWrapper` has not been set up yet
- It can't come after that point since `self.context` would create the context there.
Just move the creation to be inline, enforced by assert. This makes it easier to reason about where the context is created, and easier to change how it is created later.
Reviewed By: javache
Differential Revision: D3529843
fbshipit-source-id: 8ed5a9861ebefd4b9e0f7155db8587dcf0442b7a
Summary: There's no reason for this; setUp is once-and-done. Probably just trying to ignore the incorrect clang warning.
Reviewed By: javache
Differential Revision: D3528494
fbshipit-source-id: e4f986df8d097e4720dfd4a51e7fb6c9c9b5108f
Summary:
https://github.com/facebook/css-layout/pull/200
Make use of max dimension styles to allow root to be measured with AT_MOST measure mode
Reviewed By: IanChilds
Differential Revision: D3513505
fbshipit-source-id: 169f49717e896eb6270b52fb7115ce005aa0e3a8
Summary: I think this obscures more than it helps. Remove it.
Reviewed By: javache
Differential Revision: D3528677
fbshipit-source-id: d90a636a6e34b66563d9a02e255c6ebc4cee1294
Summary:
Ideally, native hooks should not require any sort of reference to self. Pull all those that fulfill this criteria into a class method (to make it impossible to accidentally capture self).
Future diffs will pull more and more hooks into this category.
Reviewed By: javache
Differential Revision: D3528558
fbshipit-source-id: 270c5bec53674a91ec2129d55e5cad59440a51da
Summary: It's just a simple helper. It's actually more readable and performant when inlined.
Reviewed By: javache
Differential Revision: D3528540
fbshipit-source-id: 8086770f7fd88b40623dc943c715deb4f9fd9262
Summary: This leaves no optional methods on `RCTJavaScriptExecutor`, which is certainly a good thing.
Reviewed By: majak
Differential Revision: D3518915
fbshipit-source-id: e606b9076c3299f81a225a181ea244148a1832cb
Summary: It's not widely used, and you can do something equivalent anyway by using existing public API.
Reviewed By: javache
Differential Revision: D3518896
fbshipit-source-id: 6995a5d840aecfff4ffd78ac43f3f592a4f47f91
Summary: Reading four bytes is not slow. Don't bother dispatching for that.
Reviewed By: javache
Differential Revision: D3518405
fbshipit-source-id: 910079cec2a1f624dd71760438765bd035055229
Summary: No need to have these way at the top; they're not used until later.
Reviewed By: majak
Differential Revision: D3518364
fbshipit-source-id: 3e7461665e90dea5c6d323d45b1ffb11fb610b09
Summary: No need to keep it open; it just makes it harder to reason about error handling.
Reviewed By: majak
Differential Revision: D3518200
fbshipit-source-id: dc1af6eb0f75de7e9f73513ed1dd522048f76670
Summary:
Delete the bridge functions(isRTL, allowRTL()) in internal module and move to OSS.
Create bridge for RCTI18nUtil
Reviewed By: fkgozali
Differential Revision: D3519224
fbshipit-source-id: 3853edcfcc78777d957874448117de72ae0700b5
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/mas
Closes https://github.com/facebook/react-native/pull/7535
Differential Revision: D3509757
fbshipit-source-id: 70ff6c9c137c766ccb1173921f08571f48cb4f0b
Summary:
I used the reproducible steps as described in origin bug ticket #7987 as test plan.
This has the same contents as PR #8130 but then against master per janicduplessis request.
Closes https://github.com/facebook/react-native/pull/8134
Differential Revision: D3491126
fbshipit-source-id: a22669dc998f82b36fbe31d882d0a29f0912e2ee
Summary: Rename the forceRTL to allowRTL so that make it much clear to read. And change a typo.
Reviewed By: fkgozali
Differential Revision: D3489235
fbshipit-source-id: b9803dfbcda2f764b7e752c9810cfc7a0b9fe39b
Summary: Provide function that could read the language currently used in the app, so the isRTL is using the app current using language to set isRTL.
Reviewed By: fkgozali
Differential Revision: D3480654
fbshipit-source-id: dea3ef4769296f594f7f32da2961b4fec1b99a7a
Summary: Create isDeviceLanguageRTL function to connect the OS language with isRTL. Now even if a new app could support RTL language, without setting forceRTL at JS side it won't directly change into RTL layout.
Reviewed By: fkgozali
Differential Revision: D3473109
fbshipit-source-id: ac1410c910e980d44750bb88cad7615febb9e076
Summary:
88c6e7a22b / D3446871 broke the OSS version of React where React.xcodeproj isn't autogenerated.
**Test plan:** UIExplorer example works again.
Closes https://github.com/facebook/react-native/pull/8288
Differential Revision: D3466246
Pulled By: javache
fbshipit-source-id: 1240b755b0df54ddfde016d0122640293e50caeb
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: Create a module for React Native to get IsRTL information and set ForceRTL function.
Reviewed By: fkgozali
Differential Revision: D3446871
fbshipit-source-id: 736edf138a89d222818071370ac49dc54bda63b7
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:
We already do this on Android, and it allows uw to avoid doing this global object lookup for every call. Since there's only a couple of global functions we ever call, we should consider caching all of them in the new bridge.
I didn't ValueProtect/ValueUnprotect since these are already globals, and those methods are not exposed on the JSC wrapper.
Reviewed By: mhorowitz
Differential Revision: D3411487
fbshipit-source-id: 7feaf8803665b77d649e84edad875d31c5acee4b
Summary:
Implemented automatic IP detection for iOS, based on #6345 and #6362.
As the previous pull requests did, this works by writing the IP address of the host to a file.
Closes https://github.com/facebook/react-native/pull/8091
Differential Revision: D3427657
Pulled By: javache
fbshipit-source-id: 3f534c9b32c4d6fb9615fc2e2c3c3aef421454c5
Summary: Expose the ability to provide extra information to Systrace events from JS. This is specifically useful for instrumenting generic recursive method that are defined completely through their params.
Reviewed By: tadeuzagallo
Differential Revision: D3423595
fbshipit-source-id: 7f2dedf02bf901401a6b391b85b1a0bb6782349c
Summary:
Fix a bug that happens when views are added and removed in the same manageChildren block with a delete animation. What happens is that the inserted view is not inserted at the proper index if the deleted view index is smaller than the inserted one. This is because the view is not immediately removed from the subviews array so we need to offset the insert index for each view that is going to be deleted with an animation and is before the inserted view.
To do this I separated `_removeChildren` into 2 different functions, one for animated delete and one for normal delete. The animated one returns an array of `RCTComponent` that are going to be animated. We can then use this array to offset the insert index.
**Test plan (required)**
Tested that this fixed the bug in an app where I noticed it, also tested the UIExplorer example to make sure LayoutAnimations still worked properly.
Closes https://github.com/facebook/react-native/pull/7942
Differential Revision: D3417194
Pulled By: bestander
fbshipit-source-id: 9145a783e520c6718dd023a1e006646acb09cb7c
Summary:
Fix a bug that happens when views are added and removed in the same manageChildren block with a delete animation. What happens is that the inserted view is not inserted at the proper index if the deleted view index is smaller than the inserted one. This is because the view is not immediately removed from the subviews array so we need to offset the insert index for each view that is going to be deleted with an animation and is before the inserted view.
To do this I separated `_removeChildren` into 2 different functions, one for animated delete and one for normal delete. The animated one returns an array of `RCTComponent` that are going to be animated. We can then use this array to offset the insert index.
**Test plan (required)**
Tested that this fixed the bug in an app where I noticed it, also tested the UIExplorer example to make sure LayoutAnimations still worked properly.
Closes https://github.com/facebook/react-native/pull/7942
Differential Revision: D3417194
Pulled By: nicklockwood
fbshipit-source-id: 790f4ac15a8552323b359e6466cecfa80418c63c
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:
After cleaning up JS SourceMap code, these native methods are not needed anymore.
On iOS it saves another 30+ Mb during development.
Reviewed By: javache, astreet
Differential Revision: D3348975
fbshipit-source-id: a68ae9b00b4dbaa374b421029ae676fc69ae5a75
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:
This is a followup for "Add Shortcut "Double R" to Reload JS in iOS".
Please see the previous two revisions:[[ D3371536 | D3371536 ]], [[ D3343907 | D3343907 ]]
In previous revisions, we only tested with the iOS UIExplorer app, without testing in the iOS Catalyst app, where the key shortcuts we added are always invoked in TextInput components. It's due to a bug with the `UIApplicationDelegate`. Just fix this bug in this revision and successfully tested in the Catalyst app.
Reviewed By: mkonicek
Differential Revision: D3391045
fbshipit-source-id: 8b76fbfe7592218b02dd22502d25eebbc59f3cbc
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:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
Enable double tap R on iOS, consistent with Android.
Keep the existing Cmd+R on iOS because people are already used to it.
Make Cmd+Key and Double Key both invalid when focus is in textview or textfield.
Also try to add Cmd+R in Android, but seems no good.
Reviewed By: nicklockwood
Differential Revision: D3343907
fbshipit-source-id: 68f7e3b0393711c137e1d932db33e1b6a2a19e09
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: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
Reviewed By: javache
Differential Revision: D3365346
fbshipit-source-id: d9cbf2865421f76772c1761b13992d40ec3675f0
Summary: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
Reviewed By: javache
Differential Revision: D3253073
fbshipit-source-id: abbf2a910aeb536050c3a83513fb542962ce71a5
Summary: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
Reviewed By: javache
Differential Revision: D3253073
fbshipit-source-id: 3e1520c27b88bc1b44ddffcaae3218d7681b2cd2
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: This will make error messages more helpful.
Reviewed By: javache
Differential Revision: D3292400
fbshipit-source-id: d1e0bb24593058b75422824c0d351ede1320029e
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:
Added a button to the iOS Red Box to enable copying of the error and stack trace to the clipboard to make it easier to paste the error and stack into bug reports or other text windows. Clicking the Copy button on the bottom of the RedBox screen or pressing Cmd-Option-C keyboard shortcut in the simulator will copy the full stack trace as text to the iOS pasteboard and when in the simulator you can then hit Command-C to get the text to the Mac's pasteboard for pasting in your favorite reporting/tracking app.
No tests for this change - I don't see any tests to extend for the RCTRedBoxWindow class. No impact on APIs or core React Native functionality. I validated it by running test React Native apps with red box errors and both hitting the copy button or using the command key shortcut in the emulator to get the text of the stack to the iOS pasteboard.
Closes https://github.com/facebook/react-native/pull/7557
Differential Revision: D3311743
Pulled By: javache
fbshipit-source-id: 76d1ac8ab93f40696c6a2369dae2245194db095a
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:
The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.
This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.
This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.
I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.
Reviewed By: vjeux
Differential Revision: D3292361
fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
Summary:
Currently, `7 << 16` is used as the animation easing function for both the showing and hiding of the keyboard.
Instead, `7 << 16` should be used for showing the keyboard and `6 << 16` for hiding the keyboard.
For details, see: http://stackoverflow.com/questions/18870447/how-to-use-the-default-ios7-uianimation-curve/19439283#19439283
**Test plan (required)**
Testing animating the position of a view to coordinate with the keyboard hiding and showing and it looks good.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7372
Differential Revision: D3300464
Pulled By: nicklockwood
fbshipit-source-id: 3fdc161f709de11deb7de511aad28767f5d80bd6
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:
On iPad we may get two touch cancel events in direct succession. They would have the same coalescing key, which would result in unsuccesful attempt to coalesce them.
This diff fixes it by making sure two cancel events cannot have the same coalescing key.
(An alternative fix would be implementing coalescing logic for cancel events, but that sounds more complicated. It would be neccessary if there is a legit scenario where big number of cancel events are emitted in succesion.)
Reviewed By: javache
Differential Revision: D3292405
fbshipit-source-id: 1f269771dc81fdd637cf6ac3ee4725e5e2fec679
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
as apple states, all UIKit methods should execute on main thread, while FPSGraph is not.
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests"
Closes https://github.com/facebook/react-native/pull/7500
Differential Revision: D3287011
Pulled By: tadeuzagallo
fbshipit-source-id: 23c4248c8dc65d337afb12626e597dfb6a621e96
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:
fixes#7337
`ldr reg, =symbol` will cause a text relocation, which will fail to link if that's not allowed (which is the default for dynamic libraries).
Reviewed By: jspahrsummers
Differential Revision: D3281518
fbshipit-source-id: a057b4b9a54d568c8753a9dcd00365a86c7d93b0
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:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
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:
Hi,
I noticed touching stack frames from the red box when running from an iOS device wouldn't open my editor (was working fine from the simulator).
Here's a fix.
Let me know if everything looks correct.
Thanks,
Closes https://github.com/facebook/react-native/pull/7088
Differential Revision: D3235102
Pulled By: javache
fb-gh-sync-id: 06e6c3f9164e987ea9bf71d16fe360dc37036c8d
fbshipit-source-id: 06e6c3f9164e987ea9bf71d16fe360dc37036c8d
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: The notification was previously sent from a block that only existed if RCT_DEV. This makes us always send this notification.
Reviewed By: majak
Differential Revision: D3235070
fb-gh-sync-id: bf3488d439bc2253fd12cbb10f670f54bb37eb6e
fbshipit-source-id: bf3488d439bc2253fd12cbb10f670f54bb37eb6e
Summary:
Now that we support initializing the bridge off the main thread, some of the assumptions in the bridge setup process are no longer safe.
In particular we were assuming that the JS executor and injected modules could always be synchronously initialized within bridge init, but that is only safe if those modules don't need to be set up on the main thread.
The setup for those modules was sync-dispatching to the main thread if bridge init happened on a background thread, and this lead to a deadlock under certain circumstances.
Reviewed By: javache
Differential Revision: D3224162
fb-gh-sync-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
fbshipit-source-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
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:This adds support for delete view animations in LayoutAnimation for iOS. It supports the same properties as the create animation (alpha, scale).
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
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:Hey,
I have been going through some UIAlert related issues in the repo trying to fix them, and one of the steps to start reproducing them was to put `Alert.alert()` call right inside `componentDidMount`.
However, I've started noticing strange bugs as long as I didn't set 1second timeout.
Started digging in deeper, and I've noticed the `UIAlert` gets attached to the `RCTWindow()` mainViewController.
However - since RCTDevLoadingView adds a `keyWindow`, that is the window that will be returned at the time of the call and the window `UIAlert` will be attached to.
To visualise that better - you can take a look at these two frames when app is being loaded:
<img width="371" alt="screen shot 2016-04-20 at 22 02 45" src="https://cloud.githubusercontent.com/assets/2464966/14688596/ae8d292c-0743-11e6-8aeb-e45da391b5b5.png">
<img width="371" alt="screen shot 2016-04-20 at 22 02 58" src="https://cloud.githubusercontent.com/assets/2464966/14688599/b30798e8-0743-11e6-951a-463fe7324c56.png">
AFAIK we do
Closes https://github.com/facebook/react-native/pull/7098
Differential Revision: D3207395
Pulled By: javache
fb-gh-sync-id: f8dca063573ac6f2a0ec497138b2ed0a7b27788b
fbshipit-source-id: f8dca063573ac6f2a0ec497138b2ed0a7b27788b
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
Nathan Azaria
Pieter De Baets
Emil Sjolander
Adam Ernst
Skotch Vail
Alexey Lang
Mengjue Wang
Michael McKinley
Marc Horowitz
Redmar Kerkhoff
alvaromb
Philipp von Weitershausen
Alex Kotliarskyi
Martin Kralik
Siqi Liu
Clement Genzmer
Yinan Na
Konstantin Raev
Janic Duplessis
Sokovikov
Fabian Eichinger
Nick Lockwood
Gerald Monaco
Adam Comella
Martin Konicek
Li Jie
Blair Vanderhoof
Anoop Chaurasiya
Urban Cvek
David Aurelio
Mike Grabowski
Chris Evans
Arno Fortelny
Reem Helou
Ben Roth
楚怀
Tadeu Zagallo
Digeff
Sebastian Markbage
Jesse Sessler
Jean Regisser
Labeeb Panampullan
Andrew Gray
