Summary:
1. Make "Remote JS Debug" and "Start/Stop Profile" options persist across app restarts.
2. Check and confirm:
- All options in the Android dev menu are persisted now.
- The behavior is the same on Android and iOS now.
Reviewed By: mkonicek
Differential Revision: D3340097
fbshipit-source-id: 4087b6605031c650e164282244cedb006f8f6fd3
Summary:
As for symbolicated stack trace in the red box in Android, make column number not shown if it's zero.
Format Before:
{F61180667}
Format After:
{F61180666}
Reviewed By: mkonicek
Differential Revision: D3358317
fbshipit-source-id: 87981e678e22ab9f483727002175c8835941ceee
Summary:
When the activity hosting a Modal goes away, we should dismiss the dialog from the stack and then reconstitute it when the activity comes back. This means that if an activity is paused because another activity is placed on top of it but our ui operation was delayed, it will not blow up finding no window since it is gone.
Also fixes a place where we should remove a listener for lifecycle events which we were not doing.
Reviewed By: halfjuice
Differential Revision: D3357286
fbshipit-source-id: c5c6dd8e5ef299762ed9aa15a6910ce9c0b111dc
Summary:
The API for `ActivityIndiatorIOS` and `ProgressBarAndroid` is very similar and can be merged in a cross platform component that displays a circular indeterminate loading indicator.
This deprecates `ActivityIndiatorIOS` and non-horizontal `ProgressBarAndroid` in favor of this new component.
**Test plan (required)**
Tested with the ActivityIndicator example in UIExplorer on android and ios. Also made sure that `ActivityIndicatorIOS` still works and displays a deprecation warning. Also tested that `ProgressBarAndroid` with `indeterminate == true` and `styleAttr != 'Horizontal'` displays a deprecation warning.
Closes https://github.com/facebook/react-native/pull/6897
Differential Revision: D3351607
Pulled By: dmmiller
fbshipit-source-id: b107ce99d966359003e8b3118cd97b90fa1d3d7d
Summary:
- TestIdTestModule instrumentation tests is responsible for too many occasional crashes, e.g. https://circleci.com/gh/facebook/react-native/7054.
This should fix the problem (will monitor over next week)
- Made file naming more consistent
- 5 retries don't make e2e tests more stable, reduced back to 3 but I need to investigate how to make it more reliable
Closes https://github.com/facebook/react-native/pull/7784
Differential Revision: D3354444
fbshipit-source-id: d058362edbec09522a4828998e01988a82a74487
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:
Java loadApplicationScript changed, but the C++ code in the
debug ProxyExecutor which called it did not. This fixes the fbjni
method lookup.
fixes#7659
Reviewed By: AaaChiuuu
Differential Revision: D3331472
fbshipit-source-id: 33312dccc3c7687f51742e42f9e0397f9c925e76
Summary:
Improved version of #7317.
`setRefreshing` and `setProgressViewOffset` needs to be called after the view has been layed out. Instead of using `post` to do that we update the `refreshing` and `progressViewOffset` values in the first call to `onLayout`.
I also noticed that `progressViewOffset` default value wasn't exactly the same as when not calling `setProgressViewOffset` at all. Tweaked the values to match android defaults.
**Test plan (required)**
Make sure the integration test passes,
In UIExplorer: test RefreshControl with `refreshing = true` initially, test `progressViewOffset`.
Closes https://github.com/facebook/react-native/pull/7683
Differential Revision: D3334426
fbshipit-source-id: ddd63a5e9a6afe2b8b7fe6a25e875a40f4e888c6
Summary:
Developing with react-native on Linux, I found myself facing this message:
![chpao3jwuaehr_p jpg large](https://cloud.githubusercontent.com/assets/1598317/15032665/ae90ee88-1263-11e6-9acd-3fe261c08c28.jpeg)
The problem is actually quite simple: I hadn't used `react-native start` before starting `react-native run-android`, which caused this error, both on an emulator and a real Android device. As the message is currently unhelpful, but can be shown because of a simple mistake, I updated it.
~~Additionally, I clarified the fact that `react-native start` is still necessary on Linux, updating a title on the Linux and Windows Support documentation page.~~
Closes https://github.com/facebook/react-native/pull/7396
Differential Revision: D3305078
fbshipit-source-id: 2d87e02ff2ad15d8239fbcc0ada4a4e67b982e94
Summary:
The JSCExecutor API gets passed script data and a URL, but
the proxy's purpose in life is to load from the network, so the script
data is useless. The code was failing to handle null script data, so
rather than just passing nullptr all the time, I removed the argument.
if there's a use case in the future for it, we can put it back.
Reviewed By: steveluscher
Differential Revision: D3312467
fbshipit-source-id: 986c48f1ef3c24e6b5569046ccb08d7864cdcd3d
Summary:
Update to [OkHttp](https://github.com/square/okhttp) to [OkHttp3](https://publicobject.com/2015/12/12/com-squareup-okhttp3/)
We must also update:
- Fresco to 0.10.0
- okio to 1.8.0
**Motivation**
Reasons for upgrading:
* Issue #4021
* "We discovered that RN Android sometimes fails to connect to the latest stable version of NGINX when HTTP/2 is enabled. We aren't seeing errors with other HTTP clients so we think it's specific to RN and OkHttp. Square has fixed several HTTP/2 bugs over the past eight months." - ide
* OkHttp3 will be maintained & improved, but OkHttp2 will only receive [security fixes](https://publicobject.com/2016/02/11/okhttp-certificate-pinning-vulnerability/)
* Cleaner APIs - "Get and Set prefixes are avoided"
* Deprecated/Removed - HttpURLConnection & Apache HTTP
* React Native apps are currently being forced to bundle two versions of OkHttp (v2 & v3), if another library uses v3
* Improved WebSocket performance - [CHANGELOG.md](https://github.com/square/okhttp/blob/master
Closes https://github.com/facebook/react-native/pull/6113
Reviewed By: andreicoman11, lexs
Differential Revision: D3292375
Pulled By: bestander
fbshipit-source-id: 7c7043eaa2ea63f95854108b401c4066098d67f7
Summary:
Hi,
This changelist is for fixing a crash issue on Android devices. For detail please see, https://github.com/facebook/react-native/issues/7080
In short, the crash occurred when a RN app with a Alert dialog shown at front switches back after it is destroyed at background due to lack of phone memory.
My fix is to let those Alert fragment classes accessible from android.support.v4.app.Fragment instantiate() function, so that it won't crash. And since other UI will be reloaded whatever, mListener is set to null to avoid any callback happen.
Closes https://github.com/facebook/react-native/pull/7105
Differential Revision: D3212435
Pulled By: mkonicek
fbshipit-source-id: d900a33a4f0fd49258be94c277def55555ec8d73
Summary:
Got this error when trying to run instrumentation tests locally with `./scripts/run-android-local-integration-test.sh`
```
C:\Users\janic\Developer\react-native\ReactAndroid\src\androidTest\java\com\facebook\react\tests\DatePickerDialogTestCase.java:110: error: cannot access com.facebook.react.modules.core.DefaultHardwareBackBtnHandler
return (DialogFragment) getActivity().getSupportFragmentManager()
^
class file for com.facebook.react.modules.core.DefaultHardwareBackBtnHandler not found
C:\Users\janic\Developer\react-native\ReactAndroid\src\androidTest\java\com\facebook\react\tests\ViewRenderingTestCase.java:82: error: cannot access com.facebook.react.touch.ReactInterceptingViewGroup
assertEquals("Incorrect (or not applied) opacity", expectedOpacity, view.getAlpha());
^
class file for com.facebook.react.touch.ReactInterceptingViewGroup not found
C:\Users\janic\Developer
Closes https://github.com/facebook/react-native/pull/7575
Differential Revision: D3306330
fbshipit-source-id: a6d8afd060b54d56f9e2b97f45b642d7b7f46209
Summary:
We want to give people the ability to log scroll performance (including Fb).
This adds an interface that can be enabled and disabled from the react scroll views.
This is a prerequisite to implementing the actual framerate logger that will log dropped
frames while scrolling in prod.
Reviewed By: astreet
Differential Revision: D3283588
fbshipit-source-id: ed9736cb9ed3f441511647f36b1460092bd91e56
Summary:
More instrumentation tests in OSS means less work for FB engineers to investigate if a PR breaks some internal tests.
+ increased timeouts and retries for OSS tests runner
Reviewed By: andreicoman11
Differential Revision: D3292582
fbshipit-source-id: 3f8aa4d3536450ea3af7acff044b9bb62be0f9db
Summary: Use the more accurate timestamp that we have computed for the touch event rather than the event timestamp that Android provides.
Reviewed By: andreicoman11
Differential Revision: D3292705
fbshipit-source-id: dad082ab74406d391481d16cdac19629751aa1eb
Summary:
I ran into problems when using Clipboard.getString() in Android. The method seems to work fine when there is *something* in the clipboard, but when it's empty the app crashes. I think I've tracked down the bug to ClipboardModule.java@58.
When clipData is null, the promise is resolved with an empty string. However, after that the rest of the block is executed. There should be a return or an 'else if' like in my pr.
Screenshot of the error message when clipboard is empty:
![image](https://cloud.githubusercontent.com/assets/7509183/15206922/44bd2094-182b-11e6-9400-6a59c513de24.png)
Closes https://github.com/facebook/react-native/pull/7527
Differential Revision: D3292232
fbshipit-source-id: d2191286c49ee31233203fab4648449964b9d950
Summary:
There was a race condition with `SwipeRefreshLayout` that cause the `RefreshControl` to keep refreshing when it shouldn't.
It was caused because we have to use `post` to set the refreshing state otherwise it doesn't work when setting `refreshing=true` on initial mount. What happened is that `post` doesn't guarantee the order the runnables will be called so calling post with `refreshing=true` followed by `refreshing=false` caused the `resfreshing=false` runnable to be called before the `resfreshing=true` one. This made it stay in refreshing state when it should not.
```
D/test ( 6171): setRefreshing true
W/ReactNativeJS( 6171): false
D/test ( 6171): setRefreshing false
D/test ( 6171): setRefreshing post false
D/test ( 6171): setRefreshing post true
```
This change adds an instance variable and uses it in the `post` runnable to make sure the last set value is always used.
**Test plan (required)**
Tested that it fixed the issue in the [original issue app](https://github.com/digisqu
Closes https://github.com/facebook/react-native/pull/7317
Differential Revision: D3290464
Pulled By: andreicoman11
fbshipit-source-id: 15cabcfc6d2f191443be96e8845b924ce66c369f
Summary:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary: This is called on the JS thread so we don't need to post a runnable.
Reviewed By: lexs
Differential Revision: D3281388
fbshipit-source-id: ff292a710442c0b84c6ee31a2644a5c2ea650dc9