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
Summary:Changing app state back to 'background' for UIApplicationWillEnterForegroundNotification.
On iOS we use the 'background' app state to determine whether a notification was tapped to foreground the app vs. received while app was already active. The PR https://github.com/facebook/react-native/pull/6379 changed RCTAppState so that it returned 'active' when app was being foregrounded from a notification; this changes it back to 'background' so that we can distinguish between the two cases again
Reviewed By: hedgerwang
Differential Revision: D3078746
fb-gh-sync-id: 8b5e9118a7e14f15871bfb68e9f85d20108b1faf
shipit-source-id: 8b5e9118a7e14f15871bfb68e9f85d20108b1faf
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: For RAM bundling we don't want to hold the entire bundle in memory as that approach doesn't scale. Instead we want to seek and read individual sections as they're required. This rev does that by detecting the type of bundle we're dealing with by reading the first 4 bytes of it. If we're dealing with a RAM Bundle we bail loading.
Reviewed By: javache
Differential Revision: D3026205
fb-gh-sync-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
shipit-source-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
Summary:Because the source of truth for backgroundColor is the shadow view, it's possible for the default RCTView backgroundColor to get overwritten by the current shadowView backgroundColor when the view is first created. This overridden value will then be used as the default whenever the background color is reset, which may not be be appropriate for other components that use RCTView.
This diff fixes the bug by ensuring that the view props (and therefore the default color) are set *before* the background color is propagated from the shadowView.
Reviewed By: furdei
Differential Revision: D3064128
fb-gh-sync-id: ac36007c094c7201a5c4fd93399dee4d3eb9a043
shipit-source-id: ac36007c094c7201a5c4fd93399dee4d3eb9a043
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: This is causing issues for some internal layouts. Will fix upstream and then pull this in again.
Reviewed By: majak
Differential Revision: D3058597
fb-gh-sync-id: 2e9499d2fd0322ddd87b11f285eeb08fd51977b7
shipit-source-id: 2e9499d2fd0322ddd87b11f285eeb08fd51977b7
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:The AlertViewIOS component takes in a 'defaultValue' for the text input but never actually sets it, this PR actually sets the value.
Closes https://github.com/facebook/react-native/pull/6257
Differential Revision: D3052412
Pulled By: nicklockwood
fb-gh-sync-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
shipit-source-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
Summary:I've tested this manually, but I'm not sure how to write a test for this. Hopefully someone can help out there. The least I could do is provide a starting point for a PR to be accepted.
Additionally, I've renamed the existing `NSLineBreakMode` enum converter (inside `RCTConvert`) to use dashes in the names instead of camelcase (eg: `word-wrapping` instead of `wordWrapping`).
Fixes#6338
Closes https://github.com/facebook/react-native/pull/6339
Differential Revision: D3052391
Pulled By: nicklockwood
fb-gh-sync-id: 1536dfc139d7995095e9ee9d5f13ca86f90783c5
shipit-source-id: 1536dfc139d7995095e9ee9d5f13ca86f90783c5
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
Pieter De Baets
Martin Kralik
Alex Kotliarskyi
Tisho Georgiev
Alexey Lang
Jason Prado
Walter Luh
Tadeu Zagallo
Marc Horowitz
Adam Ernst
Martín Bigio
Jakub Woyke
Satish Sampath
Emily Janzer
Nick Lockwood
Michelle Hwang
Thomas Beverley
Oleg Lokhvitsky
Morgan Pretty
aleclarsoniv
