Summary:
In Timing.java, the key provided to the remove function of mTimerIdsToTimers is not correct, that may introduce bugs.
Closes https://github.com/facebook/react-native/pull/8966
Differential Revision: D3605291
Pulled By: astreet
fbshipit-source-id: 97563b6846e8f3f40d20b48b3852dd557c9932f3
Summary: This is pure cleanup so that we can make sure that all events are living in the same time space (currently nano seconds).
Reviewed By: foghina
Differential Revision: D3593884
fbshipit-source-id: 71b084362008f1c93c21880630acf11f5c058355
Summary: Add support for top, bottom, and center layout gravity to ToastAndroid
Reviewed By: AaaChiuuu
Differential Revision: D3590224
fbshipit-source-id: 84dbbcfbe4133f291d62723c5c261acd7b32b46e
Summary:
This PR was split from a commit originally in #8619. /cc dmmiller
When an inline image was larger than the specified line height,
the image would be clipped. This changes the behavior so
that the line height is changed to make room for the inline
image. This is consistent with the behavior of RN for iOS.
Here's how the change works.
ReactTextView now receives its line height from the layout thread
rather than directly from JavaScript.
The reason is that the layout thread may pick a different line height.
In the case that the tallest inline image is larger than the line
height supplied by JavaScript, we want to use that image's height as
the line height rather than the supplied line height.
Also fixed a bug where the image, which is supposed to be baseline
aligned, would be positioned at the wrong y location. To fix this,
we use `y` (the baseline) in the `draw` method rather than trying
to calculate the baseline from `bottom`. For more information
see https://code.google.com/p/andro
Closes https://github.com/facebook/react-native/pull/8907
Differential Revision: D3592781
Pulled By: dmmiller
fbshipit-source-id: cba6cd86eb4e3abef6a0d7a81f802bdb0958492e
Summary:
Makes sure request for geolocation use in the webview is handled.
This solves issue #7609
Currently use of geolocation in webview fails silently, as the permission request is never received by the native app.
**Test plan (required)**
1. Create new project with webview
2. Add javascript for geolocation:
```javascript
navigator.geolocation.getCurrentPosition(function (position) {
console.log('success', position)
}, function (error) {
console.log('could not determine position', error)
})
```
3. Run code and assert geolocation permission is requested, resulting in success (or error) callback being called
Closes https://github.com/facebook/react-native/pull/8305
Differential Revision: D3592887
fbshipit-source-id: 84fe2383fba8873431c5e89d154c0a4fd58ffb70
Summary:
This PR was split from commits originally in #8619. /cc dmmiller
These refactorings to the HierarchyOptimizer are in preparation for implementing support for inline views in #8619.
**Refactoring 1: Collapse add*LayoutOnlyNodeToLayoutOnlyNode**
addLayoutOnlyNodeToLayoutOnlyNode and addNonLayoutOnlyNodeToLayoutOnlyNode
had nearly identical implementations. They both walk thru the ancestors
looking for a nonlayout-only node and adjusting the passed in index at each
step. This introduces a new function, walkUpUntilNonLayoutOnly, which
takes care of that responsibility. This simplifies addNodeToNode
because it can now consider the type of the parent and the type of
the child independently.
**Refactoring 2: Extract addGrandchildren**
Pull out addLayoutOnlyNode's logic into a helper called
addGrandchildren. We will need to call this method in
another place later.
**Test plan (required)**
This change was tested with UIExplorer and a small test app and it's being used in my team's app.
Closes https://github.com/facebook/react-native/pull/8908
Differential Revision: D3592783
Pulled By: dmmiller
fbshipit-source-id: a513e8d381e71112ce6348bbee7d4a7c62c33619
Summary:
As per javache comments in #8734.
Also removes now useless feature detection check.
**Test plan**
Tested that rIC still works in UIExplorer example.
Closes https://github.com/facebook/react-native/pull/8795
Differential Revision: D3572566
Pulled By: javache
fbshipit-source-id: 261d13d8b03898313f8b4184d634c70f81a61b62
Summary:
Two things in this diff:
1. Implemented `getItemPosition` in our adapter; the default implementation always returns POSITION_UNCHANGED, which is incorrect, and causes `destroyItem` to never (sometimes?) be called.
2. Fix `destroyItem`: this never worked. `destroyItem` is always called by the ViewPager after a `notifyDataSetChanged()`, so after `removeViewAt`, which removes the view from `mViews`, causing `destroyItem` to throw `IndexOutOfBoundsException` when it tries to get the view. Since our item objects are just views, use that instead of checking `mViews`.
Reviewed By: ahmedre
Differential Revision: D3555427
fbshipit-source-id: 900c2696162d07f507e850517d483b943ce39a35
Summary: This is causing log spew in all Android RN apps because we try to close a non-existing web socket.
Reviewed By: foghina
Differential Revision: D3548998
fbshipit-source-id: 27392915bdf456c88f44c3b394c5c9d2ea1bab54
Summary:
This is a follow up of the work by brentvatne in #5052. This addresses the feedback by astreet.
- Uses ReactChoreographer with a new callback type
- Callback dispatch logic moved to JS
- Only calls into JS when needed, when there are pending callbacks, it even removes the Choreographer listener when no JS context listen for idle events.
** Test plan **
Tested by running a background task that burns all remaining idle time (see new UIExplorer example) and made sure that UI and JS fps stayed near 60 on a real device (Nexus 6) with dev mode disabled. Also tried adding a JS driven animation and it stayed smooth.
Tested that native only calls into JS when there are pending idle callbacks.
Also tested that timers are executed before idle callback.
```
requestIdleCallback(() => console.log(1));
setTimeout(() => console.log(2), 100);
burnCPU(1000);
// 2
// 1
```
I did *not* test with webworkers but it should work as I'm using executor tokens.
Closes https://github.com/facebook/react-native/pull/8569
Differential Revision: D3558869
Pulled By: astreet
fbshipit-source-id: 61fa82eb26001d2b8c2ea69c35bf3eb5ce5454ba
Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
Summary: Changes the time drift error into a warning that will only get logged once per debugging session.
Reviewed By: jingc
Differential Revision: D3539067
fbshipit-source-id: 357db15750d867a91c39b5fc5fd6ed4ae2852bc7
Summary: This is caused by receiving \u2028/2029 in callbacks/function calls. The correct solution is to not evaluate these strings as scripts but instead parse them as json and pass them through the JSC API.
Reviewed By: lexs
Differential Revision: D3543098
fbshipit-source-id: 4d8acce1d510bb17361d32103d4738fc0208b0a8
Summary: Add a new interface to JSC that allows loading a file lazily from disk, i.e. using mmap, instead of loading the whole file upfront and copying into the VM.
Reviewed By: michalgr
Differential Revision: D3534042
fbshipit-source-id: 98b193cc7b7e33248073e2556ea94ce3391507c7
Summary:
https://github.com/facebook/css-layout/pull/199
- Nodes were measured with the assumption of being text nodes (height depends on width) when determining flex basis. This is not always true. Even when we are just interested in the main axis (flex basis) we need to correctly constrain the cross axis.
- Some tests were wrong. Measuring texts.big and expecting it to have textSizes.smallHeight which doesn't make a lot of sense.
Reviewed By: vjeux
Differential Revision: D3510163
fbshipit-source-id: ee53b548dd078005fdd153d279e4c7fef3dd02d0
Summary:
https://github.com/facebook/css-layout/pull/200
Make use of max dimension styles to allow root to be measured with AT_MOST measure mode
Reviewed By: IanChilds
Differential Revision: D3513505
fbshipit-source-id: 169f49717e896eb6270b52fb7115ce005aa0e3a8
Summary: If stacktrace-parser can't parse a stack trace, it'll return null. This can cause us to accidentally enter a crash loop where whenever you start your app, you load the last JS bundle you had, get a crash, and then hard crash trying to print the stack trace.
Reviewed By: frantic
Differential Revision: D3528141
fbshipit-source-id: 1146f43bc40492bfa79b6a1c0f81092383896164
Summary:
This adds proper support for tracking a TextInput content size as discussed in #6552 by adding a new callback that is called every time the content size changes including when first rendering the view.
Some points that are up for discussion are what do we want to do with the onChange callback as I don't see any use left for it now that we can track text change in onChangeText and size changes in onContentSizeChange. Also a bit off topic but should we consider renaming onChangeText to onTextChange to keep the naming more consistent (see [this naming justification](https://twitter.com/notbrent/status/709445076850597888)).
This is split in 2 commits for easier review, one for iOS and one for android.
The iOS implementation simply checks if the content size has changed everytime we update it and fire the callback, the only small issue was that the content size had several different values on initial render so I added a check to not fire events before the layoutSubviews where at this point the value is g
Closes https://github.com/facebook/react-native/pull/8457
Differential Revision: D3528202
Pulled By: dmmiller
fbshipit-source-id: fefe83f10cc5bfde1f5937c48c88b10408e58d9d
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: davidaurelio
fbshipit-source-id: d81732e50a5ece2168e8347309d8d52a0db42951
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: dmmiller
fbshipit-source-id: cbd25bb7e7bb87fa77b661a057643a6ea97bc3f1
Summary: D3516692 incorrectly assumed that the Spacing object was immutable. This is not true as it can change in a measure pass on the shadow thread while the UI is displaying some other data. This fixes it to just pull the values we need and pass them instead of the object.
Reviewed By: foghina
Differential Revision: D3523004
fbshipit-source-id: 056baecf60a9c2f2494d173a3c60396a93b97d42