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
Summary:This rev adds support for production sourcemaps on RAM.
When we inject a module into JSC we use the original `sourceURL` and specify the `startingLineNumber` of the module relative to a "regular" bundle. By doing so, when an error is thrown, JSC will include the provided `sourceURL` as the filename and will use the indicated `startingLineNumber` to figure out on which line the error actually occurred.
To make things a bit simpler and avoid having to deal with columns, we tweak the generated bundle so that each module starts on a new line. Since we cannot assure that each module's code will be on a single line as the minifier might break it on multiple (UglifyJS does so due to a bug on old versions of Chrome), we include on the index the line number that should be used when invoking `JSEvaluateScript`. Since the module length was not being used we replaced the placeholder we have there for the line number.
Reviewed By: javache
Differential Revision: D2997520
fb-gh-sync-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
shipit-source-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
Summary:At the moment, to initialize a React Native app, the entire JS bundle needs to be loaded. Parsing JS code takes a while which makes paying for every feature the app has very expensive on start up. Even worse, as the bundle gets bigger and bigger because the app has more and more features, start up time becomes slower.
This rev introduces the few remaining pieces of infrastructure to load JS modules incrementally. This way, on start up we only inject into JSC the modules we actually need. More importantly, by using this piece of infrastructure, the app start up time won't be affected as the JS bundle increases it's size.
Props to davidaurelio and tadeuzagallo for the original work. I'm just wrapping their work.
Differential Revision: D2995425
fb-gh-sync-id: caaaa880b5370c3bb36a11ae694dc303cd53d0e2
shipit-source-id: caaaa880b5370c3bb36a11ae694dc303cd53d0e2
Summary:Currently, an empty `<ScrollView />` on iOS always throws the warning "Sticky header index 0 was outside the range {0, 0}".
This is because the error-reporting code relies on the assumption that `stickyHeaderIndices` exists, and when it doesn't the error check thinks there's an index when there really isn't.
Note that this only changes error reporting and won't affect apps out of debug mode.
**Test plan**
I created a sample app and included an empty `<ScrollView />`. Without this change the "Sticky header..." warning was displayed on every run through. With this change implemented, the warning went away.
Closes https://github.com/facebook/react-native/pull/6417
Differential Revision: D3042178
Pulled By: nicklockwood
fb-gh-sync-id: 7afefd428a5fcb03867bcb69e46c46fe1ae9151e
shipit-source-id: 7afefd428a5fcb03867bcb69e46c46fe1ae9151e
Summary:Add a couple functions to show and hide a small window with buttons to start/stop
systrace and reload the current bridge. After stop profiling, the results will
be saved to a temporary file, and a share sheet will show up with the file attached
so that you can send it to your computer whatever way is more convenient.
Depends on D2700069
Reviewed By: jspahrsummers
Differential Revision: D2811560
fb-gh-sync-id: 5e91ece3a7ea748d4cb5fbc612a9b76ab80fc8f3
shipit-source-id: 5e91ece3a7ea748d4cb5fbc612a9b76ab80fc8f3
Summary: The exportedConstants method incurrs a penalty at bridge startup time for every module that implements it. This diff removes exportedConstants from a few modules that don't really need to use it.
Reviewed By: majak
Differential Revision: D2982341
fb-gh-sync-id: be016187d7b731a073311daacfcf88a0402e1688
shipit-source-id: be016187d7b731a073311daacfcf88a0402e1688
Summary:**Motivation**
AppStateIOS never currently returns `inactive` as a possible state. I had a requirement that when inactive, certain portions of the app should be blacked out in accordance with compliance rules. This is not possible currently, due to `inactive` never being returned. This PR fixes that.
**Test plan**
All base tests are passing. Are there AppState specific tests in place at the moment that I'm missing?
**Demonstration**
Closes https://github.com/facebook/react-native/pull/6379
Differential Revision: D3035530
Pulled By: nicklockwood
fb-gh-sync-id: 93deccc8184816809926dca8a95f2bebd1434987
shipit-source-id: 93deccc8184816809926dca8a95f2bebd1434987
Summary:When a component prop is set to null/undefined, and doesn't have a default value specified in `getDefaultProps`, the null value is sent over the bridge as a sentinel to reset to the original native value.
On iOS this is handled by creating a default view instance for each view type. The default view is then used to look up the unmodified value for any prop that is reset.
This is rather expensive however, as it means that for complex views (e.g. WebView, MapView), a minimum of two instances will be created even if only one is needed, and the default view will remain even after all actual view instances have been released.
This diff replaces the default view mechanism with a system where the default value of each prop is recorded the first time it is set. This avoids the need to keep an extra copy of the whole view.
The only exception is for props that use the `RCT_CUSTOM_VIEW_PROPERTY` macro, which includes the default view as part of the interface. To avoid a breaking change, a default view will still be created for views that use this macro, but only if they are sent a null value (so very rarely, in practice). In a future update we may deprecate or replace `RCT_CUSTOM_VIEW_PROPERTY` if there are significant benefits to doing so.
Reviewed By: javache
Differential Revision: D3012115
fb-gh-sync-id: 259348e54aa8342f444ad182b6f883d2dd684973
shipit-source-id: 259348e54aa8342f444ad182b6f883d2dd684973
Summary: If we're compiling with `-Wunused-variable` and `__IPHONE_OS_VERSION_MIN_REQUIRED` >= 8.0, this would cause an build error.
Reviewed By: javache, majak
Differential Revision: D3019904
fb-gh-sync-id: d4482d7d070f8d896acd44b03ebc70bacd9f2f3f
shipit-source-id: d4482d7d070f8d896acd44b03ebc70bacd9f2f3f
Summary:Fixes the RefreshControl layout after a screen rotation. See #6311 for a more detailed explanation. I fixed it by adjusting the frame of the RefreshControl in `layoutSubviews` of the parent ScrollView.
While working on fixing this I noticed that when doing a 'pull to refresh' and then not scrolling and wait for it to end the next one will not behave like the first one (it will require pulling further down for the spinner to start spinning). I fixed that too by scrolling the scrollview back to 0 manually before calling `UIRefreshControl.endRefreshing`.
**Test plan (required)**
Tested using the UIExplorer RefreshControl example.
When doing a pull to refresh and then rotating the screen the RefreshControl must stay positioned properly.
Doing multiple consecutive pull to refresh without scrolling after should all behave the same.
Fixes#6311
Closes https://github.com/facebook/react-native/pull/6359
Differential Revision: D3023727
fb-gh-sync-id: f50ae52ea769c2b3e5025c362544a8809a71aa00
shipit-source-id: f50ae52ea769c2b3e5025c362544a8809a71aa00
Martin Kralik
Jason Prado
Walter Luh
Tadeu Zagallo
Pieter De Baets
Marc Horowitz
Adam Ernst
Martín Bigio
Jakub Woyke
Satish Sampath
Alexey Lang
Emily Janzer
Nick Lockwood
Michelle Hwang
Thomas Beverley
Oleg Lokhvitsky
Morgan Pretty
aleclarsoniv
Kyle Corbitt
Mike Grabowski
Ken Wheeler
Mark Wang
Janic Duplessis
