Summary:It didn't work for a few reason. First, the drawer view NEEDS to have a background color or no shadow will ever render. Second, we need to use the `setDrawerElevation` method instead of `setElevation` for DrawerLayout. Finally we need to actually pass the style value (maybe we could just pass elevation but I don't really think it can cause any issues) down to the native component as it is not the case at the moment.
I also added a default style to elevation of 16 which is the standard for material design according to https://www.google.com/design/spec/patterns/navigation-drawer.html#navigation-drawer-specs. I could also default it to 0 so it keeps the same appearance as before but I think it looks better this way.
Closes#6022
**Test plan**
Tested using the DrawerLayout in the UIExplorer app.
Before, elevation 0
<img width="420" alt="screen shot 2016-02-23 at 1 55 42 am" src="https://cloud.githubusercontent.com/assets/2677334/13244000/008afdb2-d9d1-11e5-95b8-9c345ea0ea8d.png">
After, elevation
Closes https://github.com/facebook/react-native/pull/6100
Reviewed By: bestander
Differential Revision: D3012242
Pulled By: lexs
fb-gh-sync-id: 4967d7ec920f0229d823032ba95c8a3cace329c6
shipit-source-id: 4967d7ec920f0229d823032ba95c8a3cace329c6
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary:Changed the implementation of `setTranslucent` because the old one used the view flag SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN which has the sad side effect of making the ScrollViews not adjust properly when the keyboard is opened. Instead I use `setOnApplyWindowInsetsListener` to hook in the insets calculation process and consume the top offset so the decor view doesn't add top padding for the status bar.
I also limited the translucent prop to API 21+ because `setOnApplyWindowInsetsListener` is not available before that and anyway the translucent prop is only useful with a semi-transparent status bar color which only works on API 21+.
**Test plan**
Reproduced the bug using this code in UIExplorer.
https://gist.github.com/janicduplessis/217b9994e35f960a1793
Tapping a text field that would be hidden by the soft keyboard should scroll the view so it is not hidden.
Also tested that setting the translucent prop on and off still works as before.
Fixes#6455
Closes https://github.com/facebook/react-native/pull/6481
Differential Revision: D3067199
Pulled By: mkonicek
fb-gh-sync-id: aa115f8688ac7e461e62c18ebb8ab77350d000f8
shipit-source-id: aa115f8688ac7e461e62c18ebb8ab77350d000f8
Summary:This adds a `HEIGHT` constant on `StatusBar` on Android. I needed only this for now but I will work on a better status bar dimensions API later (see TODO).
It also improves the implementation to fix a bug that happened when multiple `StatusBar` components get updated in the same frame as well as remove useless calls to the `StatusBarModule` when values did not change.
Instead of calling the `StatusBarManager` immediately when the component gets updated and relying on the order of the calls that get dispatched to native we now wait at the end of the frame to send the calls to the `StatusBarManager` using `setImmediate`. To make this work properly we need to change the data structure of the props stack a little bit to store the desired transition/animation too for each value.
Finally this updates the example to only show the ones that work for the current platform.
**Test plan**
In the UIExplorer Example, in the 'StatusBar dimensions' section it should show 25 for the height of the status bar.
A
Closes https://github.com/facebook/react-native/pull/6195
Differential Revision: D3017559
fb-gh-sync-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
shipit-source-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
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:Don't add systems current time to the `timeout` option. This is already correct on iOS.
Closes https://github.com/facebook/react-native/pull/6376
Differential Revision: D3053728
Pulled By: mkonicek
fb-gh-sync-id: 919068659d0d23906d8a6d85df7819296460b719
shipit-source-id: 919068659d0d23906d8a6d85df7819296460b719
Summary:This is a follow up of 9b87e6c860.
- Allows custom headers on connection request
- Adds a default `origin` header to Android, just like iOS
**Introduces no breaking changes.**
I was working on something similar and would like to propose a few changes that make the API more consistent across both iOS and Android platforms and brings this closer to [spec](https://tools.ietf.org/html/rfc6455).
I believe aprock first implementation of adding custom `headers` was correct. It makes sense naming this argument `headers` since we have no other general options available, and the current `options` field is being used to pass in a header anyway.
My use case for custom headers was attaching a token to the `Authorization` header on the connection request. I have been testing this by passing a JWT inside the `Authorization` header and verifying it on the server before establishing a connection.
Closes https://github.com/facebook/react-native/pull/6016
Differential Revision: D3040735
fb-gh-sync-id: 183744d2415b895f9d9fd8ecf6023a546e18a546
shipit-source-id: 183744d2415b895f9d9fd8ecf6023a546e18a546
Summary:This is a follow up of 9b87e6c860.
- Allows custom headers on connection request
- Adds a default `origin` header to Android, just like iOS
**Introduces no breaking changes.**
I was working on something similar and would like to propose a few changes that make the API more consistent across both iOS and Android platforms and brings this closer to [spec](https://tools.ietf.org/html/rfc6455).
I believe aprock first implementation of adding custom `headers` was correct. It makes sense naming this argument `headers` since we have no other general options available, and the current `options` field is being used to pass in a header anyway.
My use case for custom headers was attaching a token to the `Authorization` header on the connection request. I have been testing this by passing a JWT inside the `Authorization` header and verifying it on the server before establishing a connection.
Closes https://github.com/facebook/react-native/pull/6016
Differential Revision: D3040735
Pulled By: nicklockwood
fb-gh-sync-id: f81bd14ccbdba36309b9d4b4850fb66fe4deae11
shipit-source-id: f81bd14ccbdba36309b9d4b4850fb66fe4deae11
Summary:Turns out even using nanoseconds as timestamps will not guarantee that events
won't happen at the same time. This fixes sorting for event comparison.
Differential Revision: D3030540
fb-gh-sync-id: 2630c50ea60a792ea07b1bf1c6cd46a6d9859268
shipit-source-id: 2630c50ea60a792ea07b1bf1c6cd46a6d9859268
Summary: In React, ReactCompoundView is supposed to be implemented by a View, but there is no ViewGroup counterpart that allows mixing virual nodes and non-virtual ones (Views) in the same parent. This is needed because TouchTargetHelper always considers child Views when looking for touch target before falling back to View/ReactCompoundView. This works incorrectly for e.g. layout-only / flattened nodes. ReactCompoundViewGroup allow intercepting touch event before it is dispatched to its children. In that sense, ReactCompoundView.reactTagForTouch() is like View.onTouchEvent() whereas ReactCompoundViewGroup.interceptsTouchEvent() is like ViewGroup.onInterceptTouchEvent().
Differential Revision: D3018028
fb-gh-sync-id: d2c70a55afb9ce9823275e7483d72e0ebedf52e4
shipit-source-id: d2c70a55afb9ce9823275e7483d72e0ebedf52e4
Summary:- Motivation: The WebSocket implementation on Android crashes the app when an attempt is made to write on a web socket that was closed due to a spotty connection. We found this issue by using Pusher, which is built on WebSockets. The following stack trace reveals that the WebSocketModule doesn't catch the case of a closed connection, when a consumer attempts to write:
```sh
Fatal Exception: java.lang.IllegalStateException: closed
at com.squareup.okhttp.internal.ws.RealWebSocket.sendMessage(RealWebSocket.java:109)
at com.facebook.react.modules.websocket.WebSocketModule.send(WebSocketModule.java:176)
at java.lang.reflect.Method.invoke(Method.java)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.facebook.react.bridge.BaseJavaModule$JavaMethod.invoke(BaseJavaModule.java:249)
at com.facebook.react.bridge.NativeModuleRegistry$ModuleDefinition.call(NativeModuleRegistry.java:158)
at com.facebook.react.bridge.NativeModuleRegistry.call(NativeModuleReg
Closes https://github.com/facebook/react-native/pull/6301
Differential Revision: D3016099
fb-gh-sync-id: 838dd9d2e5e5b7a4e2242fa6de5658dfdaf24f55
shipit-source-id: 838dd9d2e5e5b7a4e2242fa6de5658dfdaf24f55
Summary: Split dispatchViewUpdates into two methods, which enables subclasses to commit pending ui operations, even when no root node is present.
Differential Revision: D3011191
fb-gh-sync-id: a3491179441223aeffe21ff483dda582053768e7
shipit-source-id: a3491179441223aeffe21ff483dda582053768e7
Summary: Calling setTimeout(f, 0) will currently schedule f to be called the next frame instead of immediately (which is how it behaves on iOS). This immediately calls back to JS and invokes the function.
Reviewed By: astreet, tadeuzagallo
Differential Revision: D3006125
fb-gh-sync-id: 9fa109ed82836a718cbb2e8cb21da4943d96f5f6
shipit-source-id: 9fa109ed82836a718cbb2e8cb21da4943d96f5f6
Summary:Making buck rebundle the worker script on every JS change is insanely slow. This allows the script to be downloaded for debug builds.
The plan is to couple this with an implementation of `require.resolve` which will automatically insert the correct packager network path in DEV builds and the correct local path in release builds.
e.g.
var worker = new Worker(require.resolve('WebWorkerSample_getPrimesBetween.js'));
Reviewed By: lexs
Differential Revision: D2939279
fb-gh-sync-id: fbf64bbf1df1649b44e4b98ac504d095c10104a6
shipit-source-id: fbf64bbf1df1649b44e4b98ac504d095c10104a6
Summary:There was a deadlock in the bridge if a native module tried to dispatch an event through EventDispatcher (that thread would hold the mTeardownLock and want the mEventStaging lock) at the same time the EventDispatcher callback was triggered and tried to dispatch a call through JS (that thread would hold the mEventStaging lock and want the mTeardownLock).
Now there are two locks (lol). In the scenario above, the native module would hold the mJSToJavaTeardownLock and want the mEventStaging lock, while the EventDispatcher callback would hold the mEventStaging lock and want the mJavaToJSTeardownLock.
Reviewed By: lexs
Differential Revision: D3011526
fb-gh-sync-id: c3ebd5c14a6370d73caebf6c99fcba18a86c6ac1
shipit-source-id: c3ebd5c14a6370d73caebf6c99fcba18a86c6ac1
Summary: Example of a conversion to web worker support using the ExecutionContext API changes made in the last set of web worker diffs. WebWorkerSample now creates timers to show that we can dispatch timer calls to multiple JS contexts.
Reviewed By: lexs
Differential Revision: D2928657
fb-gh-sync-id: 17c5f8cd7c63624da43383da7c4160dc48482fe5
shipit-source-id: 17c5f8cd7c63624da43383da7c4160dc48482fe5
Summary: This will allow them to clean up resources when a web worker goes away.
Reviewed By: mhorowitz, lexs
Differential Revision: D2994721
fb-gh-sync-id: c7ca1afc7290e85038cf692a139f6478dba0ef61
shipit-source-id: c7ca1afc7290e85038cf692a139f6478dba0ef61
Summary:To support native modules in web workers, native modules need to have an notion of the JS executor/thread that called into them in order to respond via Callback or JS module call to the right executor on the right thread.
ExecutorToken is an object that only serves as a token that can be used to identify an executor/message queue thread in the bridge. It doesn't expose any methods. Native modules Callback objects automatically have this ExecutionContext attached -- JSModule calls for modules that support workers will need to supply an appropriate ExecutorToken when retrieving the JSModule implementation from the ReactContext.
Reviewed By: mhorowitz
Differential Revision: D2965458
fb-gh-sync-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
shipit-source-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
Summary:In testing, I've found that there's no good way to return stack traces to the server for exceptions that happen in dtor's. If the dtor is not marked nothrow(false), the exceptions are uncatchable (and bubble up as a std::abort without exception info) and if annotated properly, the program instead crashes trying to resume the stack, again a std::abort without exception info.
Instead, I created a separate destroy method that can be called (and protected via fbjni) to make the dtor's no longer execute code that may throw. Note that we don't really expect the code that was previously in ~JSCExecutor() to throw, but it was in production and we had absolutely no info to help debug it.
Reviewed By: mhorowitz
Differential Revision: D2989999
fb-gh-sync-id: 4cf9de5e0592fe6830a9903375363a78e1339a94
shipit-source-id: 4cf9de5e0592fe6830a9903375363a78e1339a94
