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
Summary:When JSC throws an error on startup (e.g. a SyntaxError) or when invoking a method that is not caught by RCTExceptionsManager, we previously just reported is a native error, with a (useless) native stack trace in the redbox. This changes that behaviour to report a JS stacktrace.
The same issue was previously reported here: https://github.com/facebook/react-native/pull/5677
Reviewed By: majak
Differential Revision: D3037387
fb-gh-sync-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
fbshipit-source-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
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:All UIManager operations that affect the view hierarchy are executed via the `addUIBlock:` method, which queues them up to be executed after layout has been completed on the shadow queue.
One of the most expensive view operations is view creation, but since this doesn't actually depend on layout, there's no reason to delay it until the shadow operations have finished.
This diff modifies the `createView` method to dispatch view creation directly to the main thread instead of adding it to the UIBlock queue. This seems to result a measurable improvement in TTI.
(Credit to astreet, for implementing the same idea on Android, and thanks to oli for telling me about it!)
Reviewed By: javache
Differential Revision: D3155709
fb-gh-sync-id: 3ad1da9a8fee687aa7e0e023d668192d94dba340
fbshipit-source-id: 3ad1da9a8fee687aa7e0e023d668192d94dba340
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:* Add ability to configure the app that should open when starting debugging
axemclion discussed this feature with tadeuzagallo and martinbigio on: https://github.com/facebook/react-native/issues/5051
Closes https://github.com/facebook/react-native/pull/5683
Reviewed By: martinbigio
Differential Revision: D2971497
Pulled By: mkonicek
fb-gh-sync-id: 91c3ce68feed989658124bb96cb61d03dd032599
fbshipit-source-id: 91c3ce68feed989658124bb96cb61d03dd032599
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Turns our using the same coalescing key until a person removes all fingers off screen is not ideal.
It doesn't work in a case where the first finger starts moving on screen and then a second finger joins it later (almost any pinch gesture),
since we would try to coalesce move events from the start when only one finger was touching screen with events where two fingers were moving on screen.
That doesn't work and results in a crash.
I've changed the logic for generating the coalescing key in order to prevent this.
We no longer have a single key for a single gesture, but we change the key each time amount of fingers increases ("touchStart") or decreases ("touchEnd").
Reviewed By: javache
Differential Revision: D3138275
fb-gh-sync-id: c32230ba401819fe3a70d1752b286d849520be89
fbshipit-source-id: c32230ba401819fe3a70d1752b286d849520be89
Summary:Immediate jumps on arm cannot jump further than 32mb, which might be a problem for large binaries.
+ add the missing `.thumb_func` directive.
Reviewed By: michalgr
Differential Revision: D3121148
fb-gh-sync-id: a53ad0ac70af9df84437b37f19b8a1cb49dd6fa2
fbshipit-source-id: a53ad0ac70af9df84437b37f19b8a1cb49dd6fa2
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:D3092867 / 1d3db4c5dc caused deadlock when chrome debugging was turned on, so it was reverted as D3128586 / 144dc30661.
The reason: I was calling `[_bridge dispatchBlock:^{ [self flushEventsQueue]; } queue:RCTJSThread];` from main thread and expecting it will `dispatch_async` to another,
since a held lock was being accessed the dispatched block and was released after the dispatch.
Turns out `RCTWebSocketExecutor` (which is used when chrome debugger is turned on) executes all blocks dispatched this way to `RCTJSThread` synchronously on the main thread.
This resulted in a deadlock. The "dispatched" block was trying to acquired lock which held by the same thread in the dispatching phase.
A fix for this is pretty simple. We will release the lock before dispatching the block.
However it's not super straightforward to see this won't introduce some race condition in a case with two threads where we would end up with events not being processed.
My thinking why that shouldn't happen goes like this: We could get in a bad state if `flushEventsQueue` would run on JS thread while `sendEvent:` is running on MT.
(I don't have a specific example how, maybe it's not possible. However when I show this case is safe we know we are good.)
The way how locking is setup in this diff the only possible scenario where these two threads would execute in these methods concurrently is JS holding the lock and MT going to enqueue another block on JS thread (since that's outside of "locked" zone).
But this scenarion can never happen, since if MT is about to enqueue the block on JS thread it means there cannot be a not yet fully executed block on JS thread.
Therefore nothing bad can happen.
So this diff brings back the reverted diff and adds to it the fix for the deadlock.
Reviewed By: javache
Differential Revision: D3130375
fb-gh-sync-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
fbshipit-source-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
Summary:If you're working on an app that needs to support landscape, reloading the app causes the iPhone simulator to reset its orientation to portrait every time the `RCTDevLoadingView` shows up. This is because it sets the root VC to `RCTModalHostViewController`, which currently supports only portrait orientations on iPhone. Changing the root view to a vanilla `UIViewController` fixes the issue.
**Steps to Reproduce**
1. Create a blank RN project: `react-native init RNTest`
2. Open it up and run it.
3. Rotate to landscape `Cmd+Right Arrow`.
4. Reload by pressing `Cmd+R`.
**Expected**
The simulator stays in landscape mode.
**Actual**
The simulator goes back to portrait.
Closes https://github.com/facebook/react-native/pull/6765
Differential Revision: D3127339
Pulled By: javache
fb-gh-sync-id: e2543c90c8d116307dcefa89a417447c1f1a327f
fbshipit-source-id: e2543c90c8d116307dcefa89a417447c1f1a327f
Summary:The 200ms timeout was causing resource issues and causing a lot of overhead when you're not running the devtools, since it will basically create a new socket every 200ms.
Also clean up the way we do logging so it's completely compiled out in prod, and standardize all the names we use for threading to lowercase react.
Reviewed By: frantic
Differential Revision: D3115975
fb-gh-sync-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
fbshipit-source-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
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:Previously, (mostly touch and scroll) event handling on iOS worked in a hybrid way:
* All incoming coalesce-able events would be pooled and retrieved by js thread in the beginning of its frame (all of this happens on js thread)
* Any non-coalesce-able event would be immediately dispatched on a js thread (triggered from main thread), and if there would be pooled coalesce-able events they would be immediately dispatched at first too.
This behavior has a subtle race condition, where two events are produced (on MT) in one order and received in js in different order.
See https://github.com/facebook/react-native/issues/5246#issuecomment-198326673 for further explanation of this case.
The new event handling is (afaik) what Android already does. When an event comes we add it into a pool of events and dispatch a block on js thread to inform js there are events to be processed. We keep track of whether we did so, so there is at most one of these blocks waiting to be processed. When the block is executed js will process all events that are in pool at that time (NOT at time of enqueuing the block).
This creates a single way of processing events and makes it impossible to process them in different order in js.
The tricky part was making sure we don't coalesce events across gestures/different scrolls. Before this was achieved by knowing that gestures and scrolls start/end with non-coalesce-able event, so the pool never contained events that shouldn't be coalesced together. That "assumption" doesn't hold now.
I've re-added `coalescingKey` and made touch and scroll events use it to prevent coalescing events of the same type that should remain separate in previous diffs (see dependencies).
On top of it it decreases latency in events processing in case where we get only coalesce-able events. Previously these would be processed at begging of the next js frame, even when js would be free and could process them sooner. This delay is done, since they would get processed as soon as the enqueued block would run.
To illustrate this improvement let's look at these two systraces.
Before: https://cloud.githubusercontent.com/assets/713625/14021417/47b35b7a-f1d3-11e5-93dd-4363edfa1923.png
After: https://cloud.githubusercontent.com/assets/713625/14021415/4798582a-f1d3-11e5-8715-425596e0781c.png
Reviewed By: javache
Differential Revision: D3092867
fb-gh-sync-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
fbshipit-source-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
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:Interface to `RCTBatchedBridge` was being declared in two different implementation files. This is suboptimal, since it makes it hard to mock that class in a test.
So I've merged and moved these two definitions in `RCTBridge+Private.h`, so it's still obvious it's a private class, but can be included if you really need it.
Reviewed By: javache
Differential Revision: D3126135
fb-gh-sync-id: 173e4c5c2925be387b92deb7f99952ca7bf28588
fbshipit-source-id: 173e4c5c2925be387b92deb7f99952ca7bf28588
Summary:The packager url for the persistent connection relied on a port
in the bundleURL, so we need to insert a sensible default. Otherwise,
issues occur: https://github.com/facebook/react-native/issues/6581
Reviewed By: bestander
Differential Revision: D3113034
fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
Summary:We were calling `CFRunLoopStop` from `-dealloc` in the `JSCExecutor`, but dealloc
is not guaranteed to run in the same thread. Move it to `-invalidate` instead.
Reviewed By: javache
Differential Revision: D3092645
fb-gh-sync-id: 94b51fec4a9fe0784feeb83d1b0c41de1cd7c052
fbshipit-source-id: 94b51fec4a9fe0784feeb83d1b0c41de1cd7c052
Summary:`flowIDMap` lives on the bridge to map from the IDs used for the flow events in
JS and the ones generated by `RCTProfile` in the native side.
It was being accessed from multiple threads (the various modules' queues in the
bridge and the JS thread), so we lock before touching it.
Reviewed By: javache
Differential Revision: D3102745
fb-gh-sync-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
fbshipit-source-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
Summary:We found that moving the preloaded modules to the startup section of the RAM Bundle improves TTI quite a bit by saving lots of through the bridge calls and injecting multiple modules at once on JSC. However, doing this on a non hacky way required a lot of work. The main changes this diff does are:
- Add to `BundleBase` additional bundling options. This options are fetched based on the entry file we're building by invoking a module that exports a function (`getBundleOptionsModulePath`).
- Implement `BundleOptions` module to include the `numPreloadedModules` attribute as a bundle additional option. This value is computed by getting the dependencies the entry file has and looking for the first module that exports a module we don't want to preload. The `numPreloadedModules` attribute is then used to decide where to splice the array of modules.
- Additional kung fu to make sure sourcemaps work for both preloaded and non preloaded modules.
Reviewed By: davidaurelio
Differential Revision: D3046534
fb-gh-sync-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
shipit-source-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
David Aurelio
Mike Grabowski
Chris Evans
Adam Comella
Nick Lockwood
Marc Horowitz
Arno Fortelny
Reem Helou
Martin Kralik
Ben Roth
楚怀
Tadeu Zagallo
Pieter De Baets
Digeff
Urban Cvek
Sebastian Markbage
Jesse Sessler
Jean Regisser
Janic Duplessis
Labeeb Panampullan
Andrew Gray
Alexey Lang
Li Jie
Sokovikov
Oleg Lokhvitsky
Ian Yu-Hsun Lin
skellyb
Justin Zeus
Emil Sjolander
Jonathan Ballerano
Mart?n Bigio
Nick
Alex Kotliarskyi
Tisho Georgiev
Jason Prado
Walter Luh
Adam Ernst
Jakub Woyke
