Summary:
Display.getCurrentSizeRange() doesn't include the size of the status
bar, so Modal windows on Android have a gap in the bottom that is the
same size as the status bar. This checks the current theme and adds the
size of status bar to the modal window height if necessary.
**Test plan (required)**
Run a React Native app on Android with a theme that doesn't show status bar and launch a modal dialog. See issue #11872 for an example.
Closes https://github.com/facebook/react-native/pull/11928
Differential Revision: D4695847
fbshipit-source-id: 9fafc2b5040e2f58d562c9cc4cd4d6d87b0df2a3
Summary: `onHostDestroy` is when the app is backgrounded and all Activities are destroyed. At this point it's safe to clear Fresco's memory cache.
Reviewed By: AaaChiuuu
Differential Revision: D4674950
fbshipit-source-id: f6db658ad56e3ad843cd2acfa31e2df1c40d3279
Summary:
We use this version internally.
Closes https://github.com/facebook/react-native/pull/12837
Differential Revision: D4688986
Pulled By: mkonicek
fbshipit-source-id: 93d9dedb51a56d6104aae443e939455c44397e88
Summary:
Re-applying the diff that was reverted in D4659669 / b87f4abf78 because of some crashes with fixes from D4659708 merged in.
---
Fixes a bug that happens when trying to use ScrollView with sticky headers and native `Animated.event` with `onScroll`. Made a few changes to the ListViewPaging UIExplorer example to repro https://gist.github.com/janicduplessis/17e2fcd99c6ea49ced2954d881011b09.
What happens is we need to be able to add multiple events to the same prop + viewTag pair. To do that I simple changed the data structure to `Map<prop+viewTag, List<AnimatedEventDriver>>` and try to optimize for the case where there is only one item in the list since it will be the case 99% of the time.
**Test plan**
Tested by reproducing the bug with the above gist and made sure it was fixed after applying this diff.
Closes https://github.com/facebook/react-native/pull/12697
Reviewed By: fkgozali
Differential Revision: D4661105
Pulled By: sahrens
fbshipit-source-id: c719dc85f45c1a142ef5b9ebfe0a82ae8ec66497
Summary:
This implements a loading banner like on iOS that shows the progress of the packager.
**Test plan**
- Tested that it displays similar messages as it does on iOS and also that is show the right message when waiting for the remote debugger.
- Tested that errors are still shown properly.
- Tested that it works with packagers that don't support multipart response (add && false in https://github.com/facebook/react-native/blob/master/packager/src/Server/MultipartResponse.js#L81).
- Run new unit tests.
- Tested that backgrounding / foregrounding the app hides / show the banner properly.
Closes https://github.com/facebook/react-native/pull/12674
Differential Revision: D4673638
Pulled By: mkonicek
fbshipit-source-id: b2a1163de3d0792cf481d7111231a065f80a9594
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/12818
Differential Revision: D4680312
Pulled By: AaaChiuuu
fbshipit-source-id: d8410e99c3ced4e2c94145186a450923029d5b22
Summary:
I don't remember exactly where we talked about this but LayoutAnimation on Android is pretty stable now so there's no reason to keep it behind an experimental flag anymore. The only part that is not really stable is delete animations, so what I did is remove the default delete animation that we provide in presets.
**Test plan**
Tested that layout animations work properly without any config.
Closes https://github.com/facebook/react-native/pull/12141
Differential Revision: D4494386
Pulled By: mkonicek
fbshipit-source-id: 5dd025584e35f9bff25dc299cc9ca5c5bf5f17a3
Summary:
PR for option to set mixed content mode in Webview(Android) for issue #8460
Closes https://github.com/facebook/react-native/pull/12314
Differential Revision: D4663084
Pulled By: lacker
fbshipit-source-id: 0e40ea463739166311ddcb7887ff6d0289369637
Summary:
Fixes#11592
This bug was seen on a Galaxy S4 running Android 4.4.2. On this device, Android's `Layout.getDesiredWidth` method doesn't correctly measure text that contains unicode emoticons. It appears to think the emoticons take up 0 space.
Setting ANTI_ALIAS_FLAG in the TextPaint's constructor instead of setting it later with setFlags works around the Android bug.
**Test plan (required)**
My team uses this fix in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12690
Differential Revision: D4673649
Pulled By: mkonicek
fbshipit-source-id: 535f371281927bfff5d8b42966496bc8daf30045
Summary: Initializing natives modules on the UI thread blocks the JS thread if the UI thread is busy.
Reviewed By: yungsters
Differential Revision: D4611211
fbshipit-source-id: cd4fb9cb5e52a478b6692b784cfd9e3bf34c0d34
Summary:
At times, ReactPackage needs to get information from the ReactInstanceManager, e.g. to get the DevSupportManager for debugging purpose. This allows passing down the instance manager to create the native modules, in addition to just ReactApplicationContext. It is then up to the Package to use it or not.
To use this, you must make your package class extends ReactInstancePackage, instead of just implementing ReactPackage interface.
Reviewed By: mmmulani
Differential Revision: D4641997
fbshipit-source-id: 497c4408a7d2b773c49f08bff7c1bf8f9d372edb
Summary:
Fixes a bug that happens when trying to use ScrollView with sticky headers and native `Animated.event` with `onScroll`. Made a few changes to the ListViewPaging UIExplorer example to repro https://gist.github.com/janicduplessis/17e2fcd99c6ea49ced2954d881011b09.
What happens is we need to be able to add multiple events to the same prop + viewTag pair. To do that I simple changed the data structure to `Map<prop+viewTag, List<AnimatedEventDriver>>` and try to optimize for the case where there is only one item in the list since it will be the case 99% of the time.
**Test plan**
Tested by reproducing the bug with the above gist and made sure it was fixed after applying this diff.
Closes https://github.com/facebook/react-native/pull/12697
Differential Revision: D4656347
Pulled By: sahrens
fbshipit-source-id: b5c36ba796f478e56028c7a95bc0f86bc54cb2ce
Summary:
Removing unused code. We used to have this dependency for the RecyclerViewBackedScrollView, which has been removed.
**Test plan (required)**
Tests pass on Circle CI.
Closes https://github.com/facebook/react-native/pull/12636
Differential Revision: D4646561
Pulled By: ericnakagawa
fbshipit-source-id: 285de78debec306078eb9ad34a2339f95bc42a9c
Summary:
This adds blurRadius support for <Image>, similar to iOS.
The heavy-lifting was done by lambdapioneer in the stack of diffs ending with
D3924013, we're just patching this in.
Two notes: we might need to apply two postprocessors going forward, will tackle
that in a separate diff, so we can ship this asap.
However, we need a new version of fresco to be released in order
to ship this.
Reviewed By: lexs
Differential Revision: D3936438
fbshipit-source-id: 353bf1f1120ebd5f4f8266c5a20188b41478a741
Summary:
Move configuration to new ```YGConfig``` and pass them down to CalculateLayout. See #418 .
Adds ```YGConfigNew()``` + ```YGConfigFree```, and changed ```YGSetExperimentalFeatureEnabled``` to use the config.
New function for calculation is ```YGNodeCalculateLayoutWithConfig```.
Closes https://github.com/facebook/yoga/pull/432
Reviewed By: astreet
Differential Revision: D4611359
Pulled By: emilsjolander
fbshipit-source-id: a1332f0e1b21cec02129dd021ee57408449e10b0
Summary:
This diff adds display:none support to React Native. This enables hiding components which still calling their render method and keeping them within the state of your application. This enables preserving state in a component even though the component is not visible. Previously this was often implemented by rendering a component off screen as a work around. See below playground for usage.
```
class Playground extends React.Component {
render() {
return (
<View style={{width: '100%', height: '100%', flexDirection: 'row', backgroundColor: 'white'}}>
<View style={{width: 100, height: 100, display: 'none', backgroundColor: 'red'}}/>
<View style={{width: 100, height: 100, backgroundColor: 'blue'}}/>
</View>
);
}
}
```
Reviewed By: astreet
Differential Revision: D4611771
fbshipit-source-id: 0dbe0494d989df42994ab9ad5125d47f3233cc5a
Summary:
This PR is based on files ericvicenti gave me. Specifically, he gave me:
- AccessibilityInfo.android.js
- AccessibilityInfo.ios.js
- AccessibilityInfoModule.java
Before this change, only a native iOS implementation of AccessibilityInfo existed. This change includes:
- A native Android implementation of AccessibilityInfo.
- JavaScript wrappers for the AccessibilityInfo module for both iOS and Android.
- UIExplorer changes to illustrate how to use AccessibilityInfo on iOS and Android.
- Documentation for the AccessibilityInfo APIs.
**Test plan (required)**
Tested the UIExplorer AccessibilityInfo example on iOS and Android with the screen reader both enabled and disabled.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12273
Reviewed By: mkonicek
Differential Revision: D4527224
Pulled By: ericvicenti
fbshipit-source-id: d04638465ccbdbb35ecfc9504daaeb8e33aab57a
Summary:
Android API 15 still have 1.5~2.0% distribution (refer: [Dashboard - Android Developer](https://developer.android.com/ndk/guides/standalone_toolchain.html#creating_the_toolchain)).
React Native is a good tec but many companies cannot endure loose their consumer. [Choreographer](https://developer.android.com/reference/android/view/Choreographer.html) triggered UI operation is the only reason that React Native Android sdk use minSdkVersion 16, so we can use a backward solution **only in API 15**: [Handler](https://developer.android.com/reference/android/os/Handler.html).
In this PR, the biggest change is :
- Make core operation of ReactChoreographer to an interface: ReactUIDriver;
- Impl ReactUIDriver by Handler => UIDriverHandlerImpl, refactor ReactChoreographer to UIDriverChoreographerImpl;
- Let UIDriverFactory to choose which one impl would be in use. (Only use handler in api 15).
Closes https://github.com/facebook/react-native/pull/12396
Reviewed By: AaaChiuuu
Differential Revision: D4588399
Pulled By: astreet
fbshipit-source-id: 76408e53664314dd926e6a553cde6bafbd37779e
Summary:
This PR fixes#6332
The issue is that Android Framework will return the same drawable instance for all requests if they request for the same resource. So the changes on the drawable instance will affect all users(`TextInput` in this case). The solution is very easy, call `mutate()` before change it will get a new drawable instance which make sure the change doesn't affect other users.
Closes https://github.com/facebook/react-native/pull/12493
Differential Revision: D4620034
Pulled By: astreet
fbshipit-source-id: a7b10fbc7447e01132b7ca0e1f78413796493e07
Summary: Adding providesModule annotations to files that don't have a `providesModule` annotation but are in directories that packager crawls.
Reviewed By: cpojer
Differential Revision: D4612455
fbshipit-source-id: b23f0d6bbe2d26f480e93b56b67c6c8b1075e9f7
Summary:
This PR will:
- add missing documentation for `caretHidden` prop to the docs
- add `caretHidden` prop implementation for Android
I noticed this by accident when looking at `RCTTextFieldManager.m` and there is `RCT_EXPORT_VIEW_PROPERTY(caretHidden, BOOL)` which hides caret on iOS. Then I realised that the docs were missing for this prop and implementation on Android side :)
Render `TextInput` with prop `caretHidden`. After this caret is not visible anymore.
`<TextInput style={styles.input} caretHidden />`
If you omit the prop then caret is visible again
`<TextInput style={styles.input} />`
Closes https://github.com/facebook/react-native/pull/11863
Differential Revision: D4448402
fbshipit-source-id: 456e1df3e2cbb8af32540d2c7a8f4e7da219f5c3
Summary:
Developers are complaining about horrible lag (https://github.com/facebook/react-native/issues/11809) caused by PR https://github.com/facebook/react-native/pull/11222.
The issue was that hasNewLayout in yoga is actually a dirty bit and indicates that either you OR one of your children has a new layout. We still need to manually check whether the component's layout actually is different from before.
Reviewed By: sahrens
Differential Revision: D4597545
fbshipit-source-id: 27d4605afd00badfdcdacae740ee2e477adee929
Summary:
Native animated events sometimes end up lagging a frame behind on android because we perform the update in the normal animation loop instead of doing it immediately when we receive the event. We had the same issue on iOS and was fixed in a similar way.
Moved some code around to have a method that updates a list of node that we can use to update the node in the animated event handler and also use it in the animation update loop.
**Test plan**
Tested that it did fix sticky headers lagging a frame behind during momentum scrolling in my PR #11315 and also tested the native animations examples still work properly.
Closes https://github.com/facebook/react-native/pull/11994
Reviewed By: mkonicek
Differential Revision: D4488977
Pulled By: sahrens
fbshipit-source-id: 831a1565bc7b8fa88cadd5a8c1be876fbdefbf66
Summary:
Since we are reading from a file, we should make sure this struct is packed, just in case we change it down the line and the compiler decides it might want to introduce padding, we're now protected against that.
There was also a discussion about the fact that people might use `ptr += sizeof(BundleHeader)` as an idiom in their code, which would currently be incorrect, if padding was introduced at the end of the file. Actually, it remains incorrect to do that now, because a RAM bundle header is a different size to a BC Bundle header. If people are properly testing their code, they should spot this pretty quickly, because it will always be an incorrect thing to do with a RAM bundle, so this isn't as bad as previously thought: where the code only succeeds when the compiler deigns to not pad the struct at the end.
This diff also cleans up how headers are initialised. `BundleHeader` has a constructor that explicitly zero-initialises it so we can rely on the default initializer to do the right thing now.
Reviewed By: mhorowitz
Differential Revision: D4572032
fbshipit-source-id: 7dc50cfa9438dfdfb9f842dc39d8f15334813c63
Summary:
A copy of https://github.com/facebook/react-native/pull/7791 because of our very imperfect tools that mirror the changes from pull requests in the fb monorepo. The internal Phabricator revision for #7791 is in an 'abandoned' state (by foghina probably because of changing teams) and Phabricator doesn't allow me to claim that revision and merge it. Therefore I'm creating a new one.
(It's not foghina's fault, no one probably knew about this "abandoned Phabricator revision" edge case, don't remember we hit it before.)
Will try to keep attribution (git blame) to rigdern when merging.
Closes https://github.com/facebook/react-native/pull/12448
Differential Revision: D4584743
Pulled By: mkonicek
fbshipit-source-id: 66e5b88134fca1980adc4cd8a2ff17c42e10022c
Summary: We're logging all console logs from webview. This strips console logging for non debug builds
Reviewed By: AaaChiuuu
Differential Revision: D4578071
fbshipit-source-id: 79b21012a6ef215eb35701911662a720cb6be280
Summary:
This matches the behavior on iOS, there was no way before to change the cursor color per input, it was only possible to change it globally via the theme. Ideally cursor color and selection color would be 2 different props but I think this is better than what we have (and matches iOS).
Sadly there is no api to change it pragmatically (only possible via xml) so this uses reflection and can easily break so it is wrapped in a try catch to avoid crashes. I think it is better to just silently fail in this case. Definetly not super happy about the solution but I think it's worth adding since it is possible to do it natively using xml so it would suck not to be able to do it in RN.
**Test plan**
Tested that the cursor has the same color as before the change when not setting the prop and that it gets the selectionColor color when set.
Closes https://github.com/facebook/react-native/pull/12280
Differential Revision: D4571858
Pulled By: astreet
fbshipit-source-id: 7dca2db33a0a4eecb6115b45155549b1265ffbed
Summary:
I couldn't resist to do this 😄#394
This adds ```flex-wrap: wrap-reverse```
I think we hit a edge case here:
https://stackoverflow.com/questions/33891709/when-flexbox-items-wrap-in-column-mode-container-does-not-grow-its-width
as is differs here from chrome, but I think that yoga is here more correct.
So I haven't added this test yet as this would fail against chrome, as chrome outputs a width of 30 for root, whereas yoga gets a width of 60 here, which I think is correct. Strangely the output of ```flex-wrap:wrap``` is in jsfiddle also only with a (visual) width of 30 on chrome, while the tests gets generated with 60.
```html
<div id="wrap_reverse_column" style="height: 100px; flex-wrap: wrap-reverse">
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
</div>
```
Looking forward what you think here emilsjolander
Closes https://github.com/facebook/yoga/pull/398
Reviewed By: astreet
Differential Revision: D4564711
Pulled By: emilsjolander
fbshipit-source-id: 33dc055abd8444b2aa7796ef90bd7ec99e961bb8
Summary:
...to reflect the modern world we live in with dynamic DPI platforms :)
Closes https://github.com/facebook/yoga/pull/375
Reviewed By: dshahidehpour
Differential Revision: D4528518
Pulled By: emilsjolander
fbshipit-source-id: e422bd4ae148e02c598a7b484a6adfa8c0e1e0c9
Summary:
Even so I know there are some opinions against ```margin: 0 auto``` it's still part of the spec: https://www.w3.org/TR/css-flexbox-1/#auto-margins and pretty usefull if you have to position via ```justify-content```.
This PR adds an implementation for that.
It adds an additonal ```YGUnitAuto``` and margins got ```YGNodeStyleSetMarginAuto``` functions as well.
Closes https://github.com/facebook/yoga/pull/357
Reviewed By: astreet
Differential Revision: D4501142
Pulled By: emilsjolander
fbshipit-source-id: 86519f8632496f46e78a7c9dbc5b21e212e3e0c7
Summary:
The PR description has been updated to reflect the new approach.
**Breaking Change Summary**
On Android, the following properties now return a different number:
- `Dimensions.get('window').fontScale`
- `Dimensions.get('screen').fontScale`
- `PixelRatio.getFontScale()`
This is a breaking change to anyone who was using these properties because the meaning of these properties has now changed.
These properties used to return a value representing font scale times density ([`DisplayMetrics.scaledDensity`](https://developer.android.com/reference/android/util/DisplayMetrics.html#scaledDensity)). Now they return a value representing just font scale ([`Configuration.fontScale`](https://developer.android.com/reference/android/content/res/Configuration.html#fontScale)).
**PR Description**
This PR changes a few things:
- Correctly exposes the font scale to JavaScript as `Dimensions.get('screen').fontScale`. UIManager was exporting `DisplayMetrics.scaledDensity` under the name `fontScale`. How
Closes https://github.com/facebook/react-native/pull/11008
Differential Revision: D4558207
Pulled By: astreet
fbshipit-source-id: 096ce7b28051325dfd45fdb2a14b5e9b7d3bc46f
Summary:
cc astreet
The goal of this PR is to enable the buck module `uimanager` to depend on `modules/core` without introducing any dependency cycles.
PR #11008 relies on this PR. PR #11008 needs `uimanager` to depend on `modules/core` so that `uimanager` can fire events using `RCTDeviceEventEmitter` which is in `modules/core`.
This PR moved a number of classes and interfaces:
- `com.facebook.react.modules.debug.DeveloperSettings` -> `com.facebook.react.modules.debug.interfaces.DeveloperSettings`
- `com.facebook.react.devsupport.DevOptionHandler` -> `com.facebook.react.devsupport.interfaces.DevOptionHandler `
- `com.facebook.react.devsupport.DevSupportManager` -> `com.facebook.react.devsupport.interfaces.DevSupportManager`
- `com.facebook.react.devsupport.DevServerHelper.PackagerStatusCallback` -> `com.facebook.react.devsupport.interfaces.PackagerStatusCallback`
- The class `com.facebook.react.devsupport.StackTraceHelper.StackFrame` was renamed to `StackFram
Closes https://github.com/facebook/react-native/pull/12329
Differential Revision: D4551160
Pulled By: astreet
fbshipit-source-id: 3a78443c4f30469b13ddfbdcc9bbef6af9e8381a
Summary:
Adds the two missing alignments ```space-between``` and ```space-around``` for ```align-content``` . Those values are a noop on ```align-items``` in order to prevent a breaking changes for an additional enum.
Fix#229
Closes https://github.com/facebook/yoga/pull/364
Reviewed By: gkassabli
Differential Revision: D4528561
Pulled By: emilsjolander
fbshipit-source-id: ea6291b6dd22cef05d9eec03893250d50371236e
Summary:
If we throw an exception from a UIOperation, the UI is likely in a bad state and we shouldn't execute any other operations on it. In non-dev mode, this would mean we've crashed and don't have to worry about that. But in dev mode, we may have shown a redbox and the instance is still active. This means doing something like reloading, which will trigger onPause and thus flush more UI operations, can crash the app while its sitting on a red box.
This diff aims to prevent that by no longer executing UI operations after one has thrown an exception.
Reviewed By: AaaChiuuu
Differential Revision: D4536925
fbshipit-source-id: 15c21bb76ad3419a54d9d5de94b6bd1f70a3e4a4
Summary: Activity lifecycle events in native modules can cause exceptions: we should redbox them like we do all other application-logic triggered exceptions.
Reviewed By: AaaChiuuu
Differential Revision: D4537111
fbshipit-source-id: 71abf8696173a3d647e858c4ea316a169ad2d8ef
Summary:
Don't call OnBatchComplete on NativeModules that have'nt been initialized.
Also a follow up to D4479604. This also removes the extra allocation of OnBatchCompleteListener per NativeModule that implements OnBatchCompleteListener.
This means NativeModules which implement OnBatchCompleteListener will have to be explicitly initialized or called into before the OnBatchCompleteListener of that NativeModule will be triggered.
Reviewed By: javache
Differential Revision: D4483682
fbshipit-source-id: 6a9431c82f72d17605d1c1e0ee9194f8d8fc2ddc
Summary: Like GuardedAsyncTask, et al, but for Runnables.
Reviewed By: achen1
Differential Revision: D4537287
fbshipit-source-id: 8ae60c7007843c0b7d8e5c3835d0847921fb3db5
Summary:
Some nodes have a value of NaN initially so if we assign the value of the input in the constructor it is possible we get NaN as a value and then it will break when trying to update the value. Initializing at 0 is actually fine with this node since it will get updated properly in the `update` method.
**Test plan**
Tested in an app that uses native animated diffclamp where I noticed the issue. Made sure this change fixed it.
Closes https://github.com/facebook/react-native/pull/12279
Differential Revision: D4527866
fbshipit-source-id: add3fc0d86ffcf4ddcd01ff3251f2373eeaa2cf5
Summary: We deprecated `transformMatrix` and `decomposedMatrix` in D3239960 10 months ago. This revision finally removes remains of this functionality from native code.
Reviewed By: mmmulani
Differential Revision: D4515760
fbshipit-source-id: b4d5b7e834ac4a775f4992b28270b4ff961889a6
Summary:
Fix#241 and successor for #302
Added new property ```display``` with ```YGDisplayFlex``` and ```YGDisplayNone```. Allows to hide nodes from the layout without the need to remove it from the DOM.
Closes https://github.com/facebook/yoga/pull/369
Reviewed By: astreet
Differential Revision: D4501141
Pulled By: emilsjolander
fbshipit-source-id: 0dfeee381f6d1e4bbba81926126b83dd7abab9d6
Summary:
Corresponding iOS PR: https://github.com/facebook/react-native/pull/11002
This adds an onScroll event to TextInput which is useful when a multiline TextInput has so much content that it is scrollable.
**Test plan (required)**
Verified the event works properly in a test app. Also, my team uses this event in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11001
Differential Revision: D4220941
Pulled By: mkonicek
fbshipit-source-id: 7e420579946f2ae840c9e1fcdc8afab68007da17
Summary:
Fixes LayoutAnimation when animating the position of a view that has a transform, the animation would start at the wrong position, offset by the transform translation value. I noticed this bug while working on sticky headers using animated in the UIExplorer <ListView> - Paging example.
**Test plan**
Made a simple repro for the bug https://gist.github.com/janicduplessis/eb985dc3accfd5982c77761be692e395 and tested that it fixed it. Also tested that the UIExplorer <ListView> - Paging example with sticky headers worked properly with this fix.
Closes https://github.com/facebook/react-native/pull/12140
Differential Revision: D4494389
Pulled By: mkonicek
fbshipit-source-id: dd49cb2db9dd4950e293596fbc773f7d79e8b10a
Summary:
This prop exposes the functionality provided by Android ScrollView's setOverScrollMode method.
One interesting thing to note is that, if you were to read the Android docs, you would think that the value "always" is the default over scroll mode. However, the docs are incorrect and "always-if-content-scrolls" is actually the default value (http://stackoverflow.com/a/27116306).
**Test plan (required)**
Verified this change in a test app. Also, our team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10905
Differential Revision: D4500957
Pulled By: mkonicek
fbshipit-source-id: 873eba38183defba133c228e0c1038efa83297d3
Summary:
The DCIM folder is a better mapping to a "CameraRoll" than the "movies" or "pictures" directories.
https://developer.android.com/reference/android/os/Environment.html#DIRECTORY_DCIM
```
DIRECTORY_DCIM
The traditional location for pictures and videos when mounting the device as a camera.
Note that this is primarily a convention for the top-level public directory, as this convention makes no sense elsewhere.
```
**Test plan**
- Make sure tests pass on both Travis and Circle CI.
- Test `saveToCameraRoll` in an example app, and check it is saved to the expected folder in a photos app.
Closes https://github.com/facebook/react-native/pull/12059
Differential Revision: D4500946
Pulled By: mkonicek
fbshipit-source-id: 8af994492303c175374502dffe6fd2f3e4e9975e
Summary:
Especially for newcomers, this may help since some may think the effect is immediate.
Closes https://github.com/facebook/react-native/pull/12066
Differential Revision: D4500929
Pulled By: mkonicek
fbshipit-source-id: dfa05134f208c084dacb3e490fe9eb8df323ffd5
Summary: `RecyclerViewBackedScrollView` was added a long time ago to work around the scroll-back-when-data-is-added bug, but that has now been fixed directly in the `ScrollView` (`ReactScrollView.java`) in open source and internally.
Reviewed By: astreet
Differential Revision: D4482105
fbshipit-source-id: 208f21f00045d5c5a83b74ad69b3db6fa63391d7
Summary:
**Motivation**
Ability to customize slider colors is desirable to match the brand. Currently iOS allows using images for slider parts, but android doesn't have any customization options. This PR adds support for customizing `thumbTintColor`, `trackTintColor` and `progressTintColor`.
**Test plan (required)**
Run UIExplorer example with the changes and verify everything works fine.
cc brentvatne
Closes https://github.com/facebook/react-native/pull/11946
Differential Revision: D4427474
fbshipit-source-id: ec3a38db600bac6108691a4cfa15e2409143b9f3
Summary:
We were noticing the following crash in our application, that was occurring fairly often, but still hard to reproduce:
```
12-12 10:37:35.342: E/AndroidRuntime(9064): FATAL EXCEPTION: main
12-12 10:37:35.342: E/AndroidRuntime(9064): Process: com.bloomberg.android.plus, PID: 9064
12-12 10:37:35.342: E/AndroidRuntime(9064): java.lang.NullPointerException: Attempt to invoke interface method 'void com.facebook.react.uimanager.UIViewOperationQueue$UIOperation.execute()' on a null object reference
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue$2.run(UIViewOperationQueue.java:782)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:829)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue.access$1500(UIViewOperationQueue.java:44)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQ
Closes https://github.com/facebook/react-native/pull/11428
Differential Revision: D4487841
Pulled By: astreet
fbshipit-source-id: ae49ef77967edea7514cbf40cb533c4b63fd34ae
Summary:
This is a followup for https://github.com/facebook/react-native/pull/12088 and implements the scrolling to end on Android natively rather than sending a large scroll offset from JS.
This turned out to be an OK amount of code, and some reduction in the amount of JavaScript. The only part I'm not particularly happy about is:
```
// ScrollView always has one child - the scrollable area
int bottom = scrollView.getChildAt(0).getHeight() + scrollView.getPaddingBottom();
```
According to multiple sources (e.g. [this SO answer](http://stackoverflow.com/questions/3609297/android-total-height-of-scrollview)) it is the way to get the total size of the scrollable area, similar to`scrollView.contentSize` on iOS but more ugly and relying on the fact the ScrollView always has a single child (hopefully this won't change in future versions of Android).
An alternative is:
```
View lastChild = scrollLayout.getChildAt(scrollLayout.getChildCount() - 1);
int bottom = lastChild.getBottom() + scrollLayout.getPadd
Closes https://github.com/facebook/react-native/pull/12101
Differential Revision: D4481523
Pulled By: mkonicek
fbshipit-source-id: 8c7967a0b9e06890c1e1ea70ad573c6eceb03daf
Summary:
According to #11992 fix skew transform in native code as well
janicduplessis vjeux
Closes https://github.com/facebook/react-native/pull/12106
Differential Revision: D4479880
fbshipit-source-id: d84780842b555f6352d84d229b5b6c5c3c6a0647
Summary: It should be possible to use the latter without using the former.
Reviewed By: ashwinb
Differential Revision: D4321776
fbshipit-source-id: 935fbb3fdb47369e18992aca0497d312ad6023bc
Summary:
When using a TextInput with a custom font, the placeholder didn't use that font. This is because ReactTextInputManager didn't use ReactFontManager to create the TypeFace which handles custom fonts.
**Test plan**
Tested in UI explorer by reproducing the bug with and testing that the custom font gets applied properly after the fix.
``` js
<TextInput
placeholder="Hello"
style={{ fontFamily: 'notoserif' }}
/>
```
Closes https://github.com/facebook/react-native/pull/12000
Reviewed By: hramos
Differential Revision: D4443713
fbshipit-source-id: e92c9822d9226681d7b00126dad95e5534c0c46e
Summary:
Support `xhr.send(data)` for typed arrays.
**Test plan:** run UIExplorer example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/11904
Differential Revision: D4425551
fbshipit-source-id: 065ab5873407a406ca4a831068ab138606c3361b
Summary:
For returnKeyType 'go', 'search' and 'send' Android will call
onEditorAction twice, once with IME_NULL and another time with the respective IME_ACTION.
This change makes sure to only fire one onSubmitEditing by always returning true in onEditorAction, which causes no subsequent events to be fired by android.
Fixes#10443
**Test plan**
1. Create view with TextInput having 'go', 'search' or 'send as `returnKeyType`
```javascript
<View>
<TextInput
returnKeyType='search'
onSubmitEditing={event => console.log('submit search')}></TextInput>
<TextInput
returnKeyType='go'
onSubmitEditing={event => console.log('submit go')}></TextInput>
<TextInput
returnKeyType='send'
onSubmitEditing={event => console.log('submit send')}></TextInput>
</View>
```
2. Input some text and click submit button in soft keyboard
3. See event fired only once instead of two times
Closes https://github.com/facebook/react-native/pull/11006
Differential Revision: D4439110
Pulled By: hramos
fbshipit-source-id: 5573b7f15f862b432600ddd3d61a0852ce51b2b3
Summary: Introduced IS_TESTING flag on Platform module for android as well. This is useful for testing environment.
Reviewed By: mmmulani
Differential Revision: D4429662
fbshipit-source-id: 33711d7fb5666f0bac8aee444b71261f7f12770f
Summary:
Many websites use domstorage and never think of its unavailability, which usually leads to a blank page on android and hard for developers to debug. I think it's better to enable domstorage by default, for convenience and consistency to iOS and PC.
Closes https://github.com/facebook/react-native/pull/11333
Differential Revision: D4437165
Pulled By: hramos
fbshipit-source-id: a00441cb5214cca27927471d3a33f030b9ff9b52
Summary: Since we don't support this, we should throw early. Also tries to improve the error message when adding a node that doesn't have a YogaNode to a node that can't measure itself.
Reviewed By: andreicoman11
Differential Revision: D4421542
fbshipit-source-id: e0be8cdd763091145e5e6af2db91515f4d236b37
Summary:
Fix#326. I'll open another PR once this one gets accepted to add support for `YGLayoutGetBorder` 👌
Closes https://github.com/facebook/yoga/pull/335
Reviewed By: gkassabli
Differential Revision: D4409399
Pulled By: emilsjolander
fbshipit-source-id: 8153f6701cab60b55a485f6d2e0b9f7767481090
Summary:
This is an attempt to fix the following startup exception that I get when running any of the example apps:
> Unrecognized type: interface com.facebook.react.bridge.Dynamic for method: com.facebook.react.uimanager.LayoutShadowNode#setFlexBasis
I really have no idea what I'm doing here, just trying to get UIExplorer to compile and run so I can test my upcoming PRs. ~~Unfortunately, this doesn't actually make the apps run, but at least it does get rid of the startup exception!~~ Edit: it works now.
**Test plan:** Run Movies and UIExplorer example app
Closes https://github.com/facebook/react-native/pull/11896
Differential Revision: D4418927
Pulled By: mkonicek
fbshipit-source-id: 34788b790b6bfc46ff39a0d9ca1698a5c20662e1
Summary: The include was missing in 87c6bcb65d (D4405355)
Reviewed By: ericnakagawa
Differential Revision: D4417874
fbshipit-source-id: 164a44e08c9da0931b49c90d01eb4396225e27d1
Summary:
== What ==
Changing the `JSBundleLoader` API, to remove `String getSourceUrl()`, instead `JSBundleLoader.loadScript` now returns the source URL it loaded.
This change has a knock-on effect: We can no longer populate `SourceCodeModule` when we construct it, because at that time, we do not know the source URL.
In order to solve this I have made the following changes:
- Added `CatalystInstance.getSourceURL()`, to return the source URL from the instance after the JS Bundle has been loaded, or `null` otherwise.
- Removed `ReactInstanceManager.getSourceUrl()`, because its only purpose was to populate `SourceCodeModule`.
- Also removed `ReactInstanceManager.getJSBundleFile()` because it was only being used in a test confirming that the `ReactInstanceManager` knew its bundle file as soon as it was constructed, which is no longer necessarily true.
- Initialise `SourceCodeModule` with the `ReactContext` instance it belongs to.
- Override `NativeModule.initialize()` in `SourceCodeModule` to fetch the source URL. When the `SourceCodeModule` is constructed, the context does not have a properly initialised `CatalystInstance`, but by the time we call initialise on it, the `ReactContext` has a `CatalystInstance` and that in turn has a source URL.
== Why ==
The reason for this change is that it allows us to add implementations of `JSBundleLoader`, that cannot determine their source URL until after having performed a load successfully. In particular I plan to introduce `FallbackJSBundleLoader` which will try to load from multiple sources in sequence stopping after the first successful load. As load failures could happen for a variety of reasons, we can't know what the true source URL is without performing the load.
Reviewed By: javache
Differential Revision: D4398956
fbshipit-source-id: 51ff4e289c8723e9d242f23267181c775a6abe6f
Summary:
Currently, < WebView > allows you to pass JS to execute within the view. This works great, but there currently is not a way to execute JS after the page is loaded. We needed this for our app.
We noticed that the WebView had messaging support added (see #9762) . Initially, this seemed like more than enough functionality for our use case - just write a function that's injected on initial load that accepts a message with JS, and `eval()` it. However, this broke once we realized that Content Security Policy can block the use of eval on pages. The native methods iOS provide to inject JS allow you to inject JS without CSP interfering. So, we just wrapped the native methods on iOS (and later Android) and it worked for our use case. The method injectJavaScript was born.
Now, after I wrote this code, I realized that #8798 exists and hadn't been merged because of a lack of tests. I commend what was done in #8798 as it sorely solves a problem (injecting JS after the initial load) and has more features than what I'
Closes https://github.com/facebook/react-native/pull/11358
Differential Revision: D4390425
fbshipit-source-id: 02813127f8cf60fd84229cb26eeea7f8922d03b3
Summary:
Added baseline support (see #132)
You have the ability for a custom baseline function (```float(*YGBaselineFunc)(YGNodeRef node);```) to return whatever baseline you want.
Closes https://github.com/facebook/yoga/pull/317
Reviewed By: splhack
Differential Revision: D4385061
Pulled By: emilsjolander
fbshipit-source-id: cb8a59a09237c840fa3e21753ab68239997dab0c
Summary: Explicitly set default scrollbarstyle value. Previously this style was implicitly used as a side effect of how we set padding on the Scrollview. This instead makes that behavior explicit.
Reviewed By: astreet
Differential Revision: D4386861
fbshipit-source-id: 362d82136a12b75fb81287ac0d0fd58f2ee297fb
Summary:
Adds the feature to use percentage as a value unit.
You can use the function ```YGPx(float)``` and ```YGPercent(float)``` for convenience.
I did some benchmarks:
```
Without Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.146683 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.490101 ms
Huge nested layout: median: 23.000000 ms, stddev: 0.928291 ms
Stack with flex: median: 0.000000 ms, stddev: 0.170587 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.143384 ms
Nested flex: median: 0.000000 ms, stddev: 0.477791 ms
Huge nested layout: median: 22.000000 ms, stddev: 2.129779 ms
With Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.132951 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.489570 ms
Huge nested layout: median: 21.000000 ms, stddev: 1.390476 ms
Closes https://github.com/facebook/yoga/pull/258
Reviewed By: dshahidehpour
Differential Revision: D4361945
Pulled By: emilsjolander
fbshipit-source-id: a8f5bc63ad352eb9410d792729e56664468cd76a
Summary: Update the Android RecyclerView, support v4, and annotation libraries to 23.4.0.
Differential Revision: D4345649
fbshipit-source-id: 859c6555bc79358b1c8ffed0629cdf0e83408a00
Summary:
Before this patch, each Node would always generate a node
region, representing the bounds of this particular Node. This set of Nodes was
used when handling touch to figure out whether we should intercept touch (i.e.
a flat Node is catching the draw), or let Android handle touch (i.e. a Node
mounted to a View will handle the touch).
This patch modifies the list of NodeRegions to exclude any Nodes that draw
nothing at all. These Nodes, having no draw output, are effectively layout
containers used to group items, so they shouldn't handle touch.
Reviewed By: sriramramani
Differential Revision: D4369484
fbshipit-source-id: 71b41611873580631f1639f368fa8d971995874f
Summary:
Virtual nodes do not have backing Yoga nodes, so measure
their first non-virtual parent instead of measuring them.
Reviewed By: sriramramani
Differential Revision: D4360540
fbshipit-source-id: 505d35fec74dddf67b002d29268acc29d2651b13
Summary:
Like its non-Nodes counterpart, FlatARTSurfaceViewShadowNode
should redraw when extra updates are collected.
Reviewed By: sriramramani
Differential Revision: D4355702
fbshipit-source-id: 6e7b90360958481f5bef9b806eca9fa888cb6a32
Summary:
Add a README file explaining the purpose of Nodes and how to
enable it within an app.
Reviewed By: JoelMarcey, lacker
Differential Revision: D4349517
fbshipit-source-id: ec26ebb37039e7c23ecd2cf4b482fa21ca8beeda
Summary:
drawRect was sometimes being called with NaN values, which caused
very strange ui behavior on some devices. This patch fixes the problem by
ensuring that we use a default value when the value is NaN.
Reviewed By: AaaChiuuu
Differential Revision: D4338453
Summary: Update package name of java code to refer to yoga instead of csslayout. Still need to change the name of the folder where this code resides but that requires update github sync scripts etc so it is safer and easier to split these diffs apart.
Differential Revision: D4271420
Summary: Remove deprecated java code and make use of CSSEdge instead of the now removed Spacing class.
Reviewed By: AaaChiuuu
Differential Revision: D4233198
Summary:
@public
Virtual shadow nodes (e.g. text) don't use CSSNodes so we don't need to create them. This shows large savings in CSSNodes allocated, depending on the app.
This could be breaking if:
- You have virtual nodes that still set and get CSS properties. The setters now no-op for virtual nodes (I unfortunately couldn't remove them completely -- see the comment on LayoutShadowNode), but the getters will NPE. If you see these NPE's, you should almost definitely be using your own datastructure instead of a CSSNode as virtual nodes will not participate in the layout process (and the CSSNode is then behaving just as a POJO for you).
I do not anticipate this to be breaking for anyone, but am including breaking in the commit message since this is a change in API contract.
Reviewed By: emilsjolander
Differential Revision: D4220204
Summary:
@public
Adds a pool to recycle CSSNodes within UIManager. A follow-up diff will hook this up to a memory pressure listener to drop the pool on memory pressure.
Reviewed By: emilsjolander
Differential Revision: D4189532
Summary: setPadding already calls dirty, and we should only be calling dirty on nodes that have measure functions.
Reviewed By: emilsjolander
Differential Revision: D4205148
Summary:
@public
This diff makes it so ReactShadowNode holds a CSSNode instead of extending one. This will enable us to pool and re-use CSSNodes and will allow us to keep from breaking the CSSNode api assumption that nodes that have measure functions don't have children (right now, text nodes have measure functions, but they also have raw text children).
BREAKING
This diff makes ReactShadowNode no longer extend CSSNodeDEPRECATED. If you have code that depended on that, e.g. via instanceof checks, that will no longer work as expected. Subclasses that override getChildAt/addChildAt/etc will need to update your method signatures. There should be no runtime behavior changes.
Reviewed By: emilsjolander
Differential Revision: D4153818
Summary: This is an API breaking change done to allow us to avoid an allocation during measurement. Instead we do the same trick as is done when passing measure results to C, we path them into a long.
Reviewed By: splhack
Differential Revision: D4081037
Summary:
In Nodes, we sometimes get crashes when we drop an already dropped
view. For now, this catches the exception to allow things to be handled
gracefully (until we can identify the actual root cause). #accept2ship
Reviewed By: sriramramani
Differential Revision: D4059333
Summary: The current implementation was made out of simplicity and to keep the same API as before. Now that the java version of csslayout is deprecated it is time to change the API to make the calls more efficient for the JNI version. This diff with reduce allocations as well as reduce the number of JNI calls done.
Differential Revision: D4050773
Summary:
From task:
in Nodes today, styles (dashed and dotted) only work on borders if the view has rounded corners. this is incorrect as they should work even when we're drawing rectangular borders.
Looking at the current non-nodes code (https://fburl.com/474407319) we can see that whenever there is a pathstyle effect the non-nodes code treats the border as if it was rounded (note that mBorderStyle == null || mBorderStyle == BorderStyle.SOLID means NO path effect is applied).
To bring the Nodes code in line with the non-Nodes code we can simply do the same thing: if there is a path style effect draw it as if it was rounded.
Reviewed By: ahmedre
Differential Revision: D4054722
Summary:
From task:
In some cases, however, drawPath is the more correct thing to do, and this ticket is one such example - if we draw the left border and top border with different colors, Nodes draws rectangularly, whereas non-Nodes makes the edges triangular.
To solve the issue in Nodes, we use drawPath instead of drawRect only when necessary (borders intersect with different colors).
Reviewed By: ahmedre
Differential Revision: D4048685
Summary:
Implemented 2 TODOs from ReactART for Android:
- TODO(7255985): Use TextureView and pass Surface from the view to draw on it asynchronously instead of passing the bitmap (which is inefficient especially in terms of memory usage)
- TODO(6352067): Support dashes in ARTShape
We use ReactNativeART in our Android project.
1. Our app crashes sometimes on large screen smartphones with OutOfMemoryError. Crashes happen in ARTSurfaceShadowNode where TODO(7255985) was suggested in a comment in order to use memory more efficiently.
2. We needed dashes for drawing on ARTSurface.
**Test plan (required)**
I attach a screenshot of our app which shows dashed-lines and two ARTSurfaces on top of each other rendering exactly the same as in the pervious implementation of ARTSurface.
Closes https://github.com/facebook/react-native/pull/9486
Differential Revision: D4021303
Pulled By: foghina
Summary:
In Nodes, we added logic when we dropped a view to also pass the
parent, so we could tell the parent that \"hey, this view is now dropped\"
so that it can be released. While this is fine, there are some crashes due
to the fact that the root node is not being found when we drop the child.
I've spent a lot of time thinking about how this could happen, and the only
plausible explanation I can come up with is that we first detach all views
from the root, then drop the root, and then drop one of the children that
was detached. I can't think of a good way why this would happen.
In the interest of protecting from this crash, this patch adds a check as to
whether or not the id of the parent is that of a root id, and, if so, it
doesn't run the logic that tells this view that this view was removed.
This should be safe, because the root most view should not have clipping
enabled (since it's a vanilla view group as opposed to a scrolling view).
Reviewed By: sriramramani
Differential Revision: D3991682
Summary:
This way `UIImplementation` can hold on to it and use it outside of calls from the `UIManagerModule`.
@public
Reviewed By: lexs
Differential Revision: D3899774
Summary:
@public
The hack for the status bar height is not necessary any longer, so we can remove
all code related to it
Reviewed By: lexs
Differential Revision: D3943770
Summary:
Modals were doing nothing (and sometimes crashing) when they were
being closed. The reason for this was due to the fact that the parent being
removed was not necessarily the view's parent. Consequently, trying to inform
said parent that its child was removed failed, because said parent wasn't a
view, and therefore had no record in mViewsToTags.
Reviewed By: sriramramani
Differential Revision: D3928850
Summary:
@public
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
Summary:
With Nodes, we want to support recursive clipping of subviews.
Without this, surfaces like Marketplace won't properly handle subviews.
Reviewed By: sriramramani
Differential Revision: D3904721
Summary:
This fixes a crash for the case when we try to drop a view that has already been dropped.
**The Problem**
We got reports of a crash (t12912526) that occurs when the resolveViewManager method can't resolve a ViewManager for a View being dropped.
Investigating this, one thing in common between all the stack traces for this is that dropView is called from line 210 of FlatNativeViewHierarchyManager. This part of the code is specifically the part we added to remove strong references to any clipped children (from views that have subview clipping enabled).
So this is a problem specifically with Nodes and clipSubviews, which brings up some questions:
**when can this happen?**
The only situation this can possibly happen is when we drop a child (which is clipped) followed by dropping its parent in the same cycle. Consider a tree where each view only has one child, such as: A - B - C - D. This crash would happen if D is clipped, and we removed it, followed by removing any of its parents in the same frame.
**if the removes happen in different frames, does this bug occur?**
No - the reason is that before we execute the DropView operations, we run through StateBuilder, which traverses the shadow tree and marks updates, thus removing the view going away (such that the delete in the next frame doesn't try to re-delete it).
So why doesn't this happen when we're dropping in the same frame? The reason is that manageChildren (where this all starts) asks to remove some views. We handle this by removing said Nodes and their children from the shadow tree. Consequently, when StateBuilder iterates over the shadow tree, it can't do the right thing because said nodes no longer exist.
As a more concrete example, consider A - B - C - D again, and consider that both D and B are removed. StateBuilder only sees A, and realizes that it now has 0 children (whereas before it has 1), so it removes B from its children. However, this process isn't recursive, so C never gets cleaned up.
**why doesn't this happen with Nodes without clipping containers?**
The answer to this is that NativeViewHierarchyManager's dropView method checks the existance of each child before deeply dropping that child and its subtree. So in this case, we drop D and all its children, and when we come to drop B, we try to drop C (which exists) and then its children (D, which doesn't exist because we already dropped it, so we ignore it).
**why doesn't this happen with non-Nodes?**
The reason is that non-Nodes handles removes differently - every remove is enqueued in a call to NativeViewHierarchy's manageChildren, which explicitly asks the parent to remove said child. Consequently, we never try to remove a child that is already removed.
**Fix**
The initial fix was to check whether or not the view exists, but this updated patch just does the right thing at drop time - i.e. whenever a view is dropped, we notify the parent of this fact so that it can clear the reference from clipped views.
**One last Note**
There are two reasons for switching `super.dropView` to `dropView` - first, the comment is only partially correct - calling `super.dropView` will avoid looking at clipped children (as an aside, that could cause a leak in the case of nested clipping subviews), but will look at clipped grandchildren, because of the super class's iteration across the set of children.
Reviewed By: astreet
Differential Revision: D3815485
Summary:
This should probably be two separate diffs, sorry. It takes forever to test these things on fb4a though.
The nodes GK was turned up in fb4a, so I had to make a few changes to make the existing integration work.
Reviewed By: lexs, emilsjolander
Differential Revision: D3863226
Summary:
@public
Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
Summary:
@public
Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
Summary:
@public
This is to be able to depend on ReactClippingViewGroup from BaseViewManager. Devs using ReactClippingViewGroup may need to update their imports when updating past this commit.
Reviewed By: lexs
Differential Revision: D3835328
Summary:
We were always getting LEFT explicitly, and, due to RTL support, we
should be asking for START instead.
Reviewed By: sriramramani
Differential Revision: D3836816
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3841658
Summary:
Fix TextInput padding on Nodes. We used to not call super and used
to manually do the setting of padding. This stops us from running the same
logic that non-Nodes runs (we bypassed it), so this fixes it.
Reviewed By: astreet
Differential Revision: D3825227
Summary:
Due to the RTL implementation, the ViewProps spacing array has START
and END, whereas Nodes should deal with RIGHT and LEFT directly (just like
non-Nodes does). This is the same implementation in use by non-Nodes.
Reviewed By: astreet
Differential Revision: D3809028
Summary:
Nodes historically had two image implementations -
DrawImageWithDrawee and DrawImageWithPipeline. The drawee implementation
was the default (per request of the Fresco team). At this point, there is
no point of having two (especially since updates to one need to be made to
the other), so this patch removes pipeline.
Reviewed By: sriramramani
Differential Revision: D3755523
Summary:
Nodes would typically clip its images, and then Fresco would then
re-clip as part of ScaleTypeDrawable - in addition to being unnecessary,
it's also incorrect, beacuse it causes the image to be smaller than it
should be.
Reviewed By: sriramramani
Differential Revision: D3754778
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
Summary:
This is just a minor cleanup, use constants for the LEFT
and RIGHT alignments, since they are hide.
Reviewed By: sriramramani
Differential Revision: D3746019
Summary: Adds a flag that can be set in FlatViewGroup to see known performance issues in Nodes objects. This is mostly useful in internal development of Nodes, and will be a dead code path when not set.
Reviewed By: ahmedre
Differential Revision: D3732675
Summary: Node region bounds are assumed to equal the underlying node bounds. In the case of hit slop, these need to be abstracted.
Reviewed By: ahmedre
Differential Revision: D3713430
Summary:
This is minor, but for our use case a SparseArray is going to be faster as long as we have less than 10,000 clipped subviews, and will also use much less memory.
Faster because of the boxing, unboxing and hash caching; less memory as it is two arrays instead of the object overhead of the HashMap.
Reviewed By: ahmedre
Differential Revision: D3704326
Summary: Previously, the first time we collected a draw view, we would make a clone, even though the draw view had never been mutated. This refactors draw view to avoid this extra allocate.
Reviewed By: ahmedre
Differential Revision: D3719056
Summary:
In Nodes, there were certain cases where text wasn't drawn due to an
optimization that skipped measuring because the size was already known.
Reviewed By: emilsjolander
Differential Revision: D3713841
Summary:
For Nodes that don't mount to views, measureLayout wasn't working
because our calls for getting the width and height would return the view delta
bounds, which won't exist for Nodes. #accept2ship
Differential Revision: D3707880
Summary:
Nodes currently doesn't ask Fresco to resize images, but this is
potentially problematic (ex having a camera photo of 6000x1500 causes a crash
due to the massive size).
Differential Revision: D3687944
Summary: Adds support for horizontal clipping, though the FlatViewGroup needs to be made aware still of which it is.
Reviewed By: ahmedre
Differential Revision: D3673501
Summary: This optimizes node region searches in clipping cases, and does position calculation for drawCommands off of the UI thread.
Reviewed By: ahmedre
Differential Revision: D3665301
Summary: Add jni bindings for csslayout. First step in many of removing LayoutEngine.java and performing all layout in native.
Reviewed By: lucasr
Differential Revision: D3648793
Summary:
Use ImageRequestBuilder directly in Nodes, just like we do for
non-Nodes.
Reviewed By: sriramramani
Differential Revision:
D3660610
Ninja: Sandcastle is broken. 25 denizens of the Facebook republic are affected by this unrelated issue today.
Summary: Add directional aware clipping to DrawCommandManager. Currently not attached to FlatViewGroup logic, with the plan to keep this unattached until we are clipping the way we want to in the final state.
Reviewed By: ahmedre
Differential Revision: D3622253
Summary: @public Make UIOperation public so that custom implementations can expose instances of it.
Reviewed By: ahmedre
Differential Revision: D3618197
Summary:
Support rounded clipping in Nodes. Before, if a view had
a radius and had overflow of hidden, its children could still draw
outside of it (specifically, in the area between the rounded rect
and square rect) - this is due to the fact that clipping is, by
default, rectangular. This patch supports this type of rounded
clipping.
Differential Revision: D3634861
Summary: Previously, we had no information about the positioning of the view until after we had attached it. We have the position information attached to the shadow node, but this attaches it to the DrawView as well. It also removes the need for AbstractClippingDrawCommand.
Reviewed By: ahmedre
Differential Revision: D3609092
Summary: @public Change the textalign setter to support RTL. In order to support text alignment according to layout style, move the textalign setter bridge function from ReactTextViewManager.java to ReactTextShadowNode.java and calculate it correctly on RCTTextUpdate.
Reviewed By: dmmiller
Differential Revision: D3597494
Summary:
This patch fixes measureInWindow for Nodes backed by Views.
Whereas the intention was to call the super implementation when we have a
Node backed by a View, we instead called the super implementation of
measure, which doesn't measure relative to window.
Differential Revision: D3607890
Summary:
Currently we have race conditions in DrawView related to isViewGroupClipped, where we create a copy of the DrawView before we update the clipping state, and think the view is unclipped in the next iteration.
Also we are sometimes creating a DrawView with a reactTag of 0.
This fixes both, and is part of the upcoming DrawView bounds change, but is a separate issue that is live in current source.
Reviewed By: ahmedre
Differential Revision: D3598499
Summary:
@public
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
Summary:
View the comment thread for discussion:
https://www.facebook.com/groups/1505872839725322/permalink/1630102823968989
Our current behaviour of add then immediately remove if a view is clipped pretty much guarantees that we kill network requests for images in feed. We have a better fix for that in the pipeline, but this is a low risk fix in the meantime.
Reviewed By: ahmedre
Differential Revision: D3597785
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
Summary:
DrawImageWithDrawee has caused NPEs when using Nodes in various cases
in RNFeed. This patch explicitly throws a RuntimeException, so that we can
debug as to whether this is coming from bad sources or a bad size for the
image.
Differential Revision: D3574998
Summary: This is the most straightforward fix for the double detach issue. If a view is not attached, then addViewInLayout never propagates onAttach, and adding through attachViewToParent is a no op. We could hack something in to attach clipped FlatViewGroups in onClippingRect, but any other view that relies on onAttachedToWindow will have similar issues.
Reviewed By: ahmedre
Differential Revision: D3560565
Summary: Since Nodes' manageChildren doesn't enqueue the child updates immediately, commands were being directed to non-updated views. Previously we applied updates for the shadow node before dispatching the command, but we can instead wait to fire commands until after we update the view hierarchy.
Reviewed By: ahmedre
Differential Revision: D3568541
Summary: Supports show layout bounds either by override within FlatViewGroup, or if show layout bounds is set in settings. Currently requires app restart to disable.
Reviewed By: ahmedre
Differential Revision: D3553669
Summary: Fixes needing to specify exact height of react views in Mason. Uses a ViewTreeObserver to delay draw until we have correct bounds.
Reviewed By: sriramramani
Differential Revision: D3527122
Summary:
Nodes wasn't supporting text decorations to the line (strike through
and underline). This patch implements that.
Differential Revision: D3512711
Summary: We do want to only apply updates when a view previously wasn't mounted and didn't have a backing view created. Previously we were applying updates to the view regardless of the mount state, which resulted in positioning bugs. Rather than revert, I cleaned up the code Ahmed fixed, since didUpdate || ensureBackingViewIsCreated() was both a bug and obscure, as the two should have a swapped order.
Reviewed By: sriramramani
Differential Revision: D3538734
Summary:
@public
Text was not correctly respecting padding. We would account for it when measuring, but then not actually apply the padding to the text. This adds support for proper padding
Reviewed By: andreicoman11
Differential Revision: D3516692
Summary:
Previously, to fix the issue of commands happening before the Views
were made and attached to the hierarchy, a check was added to see if a node
had not been mounted to a View, to update its hierarchy. In reality, we need
to do this irrespective, since a node could be mounted to a View, but its
children may not yet be attached, for example. Note that if there is nothing
to be done, this won't do extra work (i.e. applyUpdates recursively goes
through the tree from the node on which we did the operation to apply updates,
but if there are no updates, we stop traversing that praticular subtree).
Reviewed By: sriramramani
Differential Revision: D3511462
Summary:
The TextInput spannables are being set wrong by Nodes. Consequently,
when you hit space after a word, anything you type is highlighted, though it
shouldn't be.
Differential Revision: D3507516
Summary:
The results from measureInWindow were always wrong the first time it
was called. This was due to the fact that the view in question was not
actually a view yet, so the results were incorrect. This patch uses the
existing measure functionality (which can measure virtual nodes) to measure
the view, while modifying it to properly get the results relative to the
window instead of relative to the root view.
Reviewed By: sriramramani
Differential Revision: D3501544
Summary:
Depends on D3120798
Depends on D3120631
Enables D3120631 for nodes. This implementation seems to work but let me know if I'm doing something really stupid.
Reviewed By: ahmedre
Differential Revision: D3120814
Summary:
Modals were broken in Nodes, because the custom measurement logic for
all the children of the ReactModalShadowNode was not being applied (because we
wrapped it in a NativeViewWrapper). This change adds a custom flat node type
for modals.
Differential Revision: D3499557
Summary:
Fix DrawImageWithPipeline's code for checking whether or not an image
request exists or not to be the same as DrawImageWithDrawee's.
Differential Revision: D3489532
Summary:
In manageChildren, we were assuming that the indices that
were passed in to be removed were sorted, however, they weren't.
This patch sorts the children to be removed. Note that it doesn't
explicitly sort move, since these are sorted by the MoveProxy class.
Reviewed By: astreet
Differential Revision: D3474639
Summary:
Groups encountered a pretty major crash where, in many cases,
we would find that DrawCommands and Views were out of sync. This
turns out to be due to the fact that when we drop views from the
root view, we remove each child using removeChildAt (which ultimately
causes an invalidate and redraw). If this happens for a
FlatViewGroup, this causes issues where the Views are all removed,
but there are some DrawCommands (potentially DrawViews) that aren't
removed, hence them going out of sync.
Reviewed By: astreet
Differential Revision: D3473916
Summary: Currently only FlatViewGroup children were clipped, rather than all offscreen Android views.
Reviewed By: ahmedre
Differential Revision: D3462002
Summary:
During the patch for fixing the order of UI operations, we apply
updates to any node receiving a ViewManager command in order to ensure that
nodes that were not yet mounted to a View and not yet attached to their parent
would be properly able to receive the event. However, if a node is already a
view, calling the update could cause unwanted things to happen (for example,
the View's bounds changing improperly), because we're only traversing that
node of the tree and down (instead of the entire tree). This fixes the issue
by only applying updates to the node if the view mount state has changed.
Reviewed By: sriramramani
Differential Revision: D3448356
Summary:
A Layout's text can either be an Ellipsizer or a SpannedEllipsizer.
SpannedEllipsizer implements Spannable, but Ellipsizer doesn't. We were
casting the Layout's text directly to a Spanned without first checking as to
whether or not it was actually a Spanned.
Reviewed By: sriramramani
Differential Revision: D3435075
Summary:
The nodes version of D3364550. The only difference is that here we
don't get `onSizeChanged` but `onBoundsChanged`, and we need to compute the
height/width of the target image from those bounds. ahmedre please let me know
if any of these assumptions are in any way incorrect.
Reviewed By: ahmedre
Differential Revision: D3424843
Summary:
This is needed for the upcoming loading from multiple sources (D3364550 for the non-nodes version) and cache interrogation (D3392751 for non-nodes version).
This postpones creating the DraweeRequestHelper until the image size is known, which in the nodes universe is when `onBoundsChanged` is called.
Reviewed By: foghina, ahmedre
Differential Revision: D3413467
Summary:
Fix touch inspector when using Nodes by implementing custom logic.
This logic now takes into account that non-View nodes need to be clickable.
Reviewed By: astreet
Differential Revision: D3433927
Summary:
Made some improvements to RCTText based on some of our learnings from components for android. This now resembles diffusion/FBS/browse/master/fbandroid/java/com/facebook/components/widget/TextSpec.java
Things that have improved:
- Calculation of text width is now faster (we noticed in components that .getWith() on the layout is all that is needed and it is much faster)
- Use text layout builder to abstract away a lot of the low level details of static / boring layouts and text measurements
- Handle MeasureMode correctly, previously AT_MOST was not supported.
- Better handling of RTL text by using TextLayoutBuilder where I made changes to support RTL text in components. Specifically RTL text measured with UNSPECIFIED or AT_MOST.
- There was an incorrect assumption being made that when measure() was not called the text had to be boring. This is incorrect, Arabic text is never boring for example. Also multiline text is not boring either and may have exact sizing.
Reviewed By: ahmedre
Differential Revision: D3374752
Summary:
The dispatchViewManager command should, according to the spec, only
be executed after children are added. On Nodes, however, due to the fact that
the Views in question may not have been created until the call to the command
occurred, the dispatchViewManagerCommand may occur too early. Consequently,
ensure that we apply any state updates to the Node represented by that
reactTag before we enqueue the view manager command (this will ensure that
views are properly added to the parent, etc before sending the command).
Reviewed By: astreet
Differential Revision: D3428855
Summary:
@public
This adds support for specifying multiple sources for an image component, so that native can choose the best one based on the flexbox-computed size of the image.
The API is as follows: the image component receives in the `source` prop an array of objects of the type `{uri, width, height}`. On the native side, the native component will wait for the layout pass to receive the width and height of the image, and then parse the array to find the best fitting one. For now, this does not support local resources, but it will be added soon.
To see how this works and play with it, there's an example called `MultipleSourcesExample` under `ImageExample` In UIExplorer.
Reviewed By: foghina
Differential Revision: D3364550
Summary:
Historically, removeClippedSubviews for Nodes would not clip views
that overflowed their parent. This patch changes that, so that Nodes can
properly clip views when they are off screen (even if they have descendants
that overflow the bounds of their parent).
This is done by calculating a set of offsets from the actual width and
height of the view, and using those in the clipping calculations.
Reviewed By: sriramramani
Differential Revision: D3409859
Summary:
As an optimization, for something like a ScrollView which contains
a FlatViewGroup containing posts, make sure that each post is explicitly
mounted to a View. This may help improve performance, especially when said
Views are otherwise inlined as DrawCommands instead of actual Views.
Reviewed By: astreet
Differential Revision: D3161232
Summary:
The removeClippedSubviews optimization often detaches views while
maintaining strong references to them (so they can be attached again later
on). However, when removing the parent view, any detached views end up not
being cleaned up or removed, thus leaking memory. This fixes this by
explicitly dropping detached views when the parent is removed.
Reviewed By: astreet
Differential Revision: D3337513
Summary:
Text in Nodes is squashed into a single DrawCommand for drawing a
Boring or StaticLayout. Touch is handled using a TextNodeRegion subclass of
NodeRegion that knows how to identify pieces of text inside of the DrawCommand
based on spans in the text. However, we only use a TextNodeRegion on the
second call for updateNodeRegion for an RCTText. If there is only one call,
the NodeRegion will just be a normal one. This patch ensures that the
NodeRegion for an RCTText is always a TextNodeRegion, allowing for null
Layouts that are set when the DrawCommand is made.
Reviewed By: astreet
Differential Revision: D3291682
Summary:
As of D3235050, Nodes supports the optimization of removing clipped
subviews from the hierarchy. However, because Nodes supports overflow:visible,
this could cause issues when DrawCommands overflow the bounds of their parent
container. This patch fixes this by not clipping any overflowing Nodes.
Reviewed By: astreet
Differential Revision: D3235072
Summary:
RN has an optimization in which a ScrollView (or similar ViewGroups)
can ask to remove clipped subviews from the View hierarchy. This patch
implements this optimization for Nodes, but instead of adding and removing the
Views, it attaches and detaches Views instead.
Note that this patch does not handle overflow: visible. This is addressed in a
stacked patch on top of this patch (to simplify the review process).
Reviewed By: astreet
Differential Revision: D3235050
Summary:
Nodes crashed when setJSResponder was called on a virtual (non-View)
node, because a View could not be found using that react tag. The solution is
two fold - first, to figure out the View parent and pass that to
setJSResponder in addition to that of the virtual tag. Secondly, we weren't
mounting views that had animation properties (transform, for example) to
Views, which caused related code to fail.
Reviewed By: sriramramani
Differential Revision: D3301310
Summary:
Canvas.save by default saves both the matrix (for translations,
scaling, etc) and the clip (clipRect) - in most of our cases, we really only
care to save and restore the clip, not the matrix.
Reviewed By: sriramramani
Differential Revision: D3235698
Summary:
With nodes, it's possible for a touchable region to not be
explicitly mounted to a View. To work around this (and allow the region to
be the handler of the touch event), FlatViewGroup intercepts touch events
when the touch lies within any of the virtual NodeRegions.
This can sometimes be wrong - the canonical example is when touch starts
outside of a particular FlatViewGroup (so someone else, for example a
sibling) intercepts the touch event, and then the person moves over a
different FlatViewGroup, causing it to intercept the touch event when it
shouldn't. To fix this, we only allow intercepting touch events due to
NodeRegions on the down event.
Reviewed By: astreet
Differential Revision: D3160152
Summary:
By default, Nodes causes views to not be clipped, unless overflow is
explicitly set to hidden. Consequently, Nodes sets all the clipping bounds to
negative infinity, and does some extra work (saving the canvas layer,
clipping, etc) before drawing. This optimization skips the extra work when
it's not needed.
Reviewed By: sriramramani
Differential Revision: D3161268
Summary:
Initially, we used to mount nodes to Views anytime a node was
clicked. This was not useful, since we could still not handle touch when
a touch event was already dispatched. Later, a fix was pushed that
supported handling touch events for non-View NodeRegions. Part of the
intention was to remove this code, but it was forgotten.
Reviewed By: sriramramani
Differential Revision: D3160532
Summary: This allows users of the API to have greater control over handling RTL. One example is Components which needs this greater control to correctly handle RTL.
Differential Revision: D3120721
Summary:
UIImplementation has a few methods that in the end touch native Views, such as dispatchViewManagerCommand, addAnimation, sendAccessibilityEvent etc. There are 2 cases where it is possible to have those methods called on shadow nodes that don't have backing Views created:
- backing view is scheduled to be created but not commited yet (StateBuilder accumulates createView commands into a queue and flushes it in the very end)
- shadow node doesn't mount to a View so there is no backing View
Touching View in UI thread in these 2 cases will either lead to silent error (e.g. failure callback will execute), or a native crash.
This diff is overriding all UIImplementation methods that touch Views in UI thread and makes sure that backing View is created before we do so.
Reviewed By: ahmedre
Differential Revision: D3046392
Summary: In some rare cases, RCTText.measure can receive negative width which will crash with an assertion in android.text.Layout because it expects a positive value. This is a temporary fix to treat negative values as unconstrained width until the original bug is fixed.
Reviewed By: sriramramani
Differential Revision: D3038767
Summary:
Since we now have the correct fix in place, this patch is to revert
the hack we put in place to not be launch blocking.
Reviewed By: sriramramani
Differential Revision: D3019883
Summary: In FlatViewGroup, we flatten some react nodes into parent while mounting others into child Views. This is causing touch events being dispatched to wrong targets because child Views are \"stealing\" touch events from flattened Views. To fix the issue, implement ReactCompoundViewGroup to provide information about both virtual and non-virtual nodes.
Reviewed By: ahmedre
Differential Revision: D3018054
Summary: Before this patch, we only collected virtual nodes in NodeRegions, because NodeRegions are only needed to implement ReactCompoundView.reactTargetForTouch() which is only interested in virtual nodes. In the next patch, FlatViewGroup will implement ReactCompoundViewGroup interface which requires knowledge of both virtual and non-virtual children. As a step towards that, we need to include non-virtual nodes in NodeRegions. This patch is implementing that. By itself, it should have not cause any changes in application behavior: we add non-virtual nodes to NodeRegions and mark them as non-virtual, then skip all non-virtual nodes in reactTagForTouch().
Reviewed By: ahmedre
Differential Revision: D3018047
Summary: Before the patch, order of NodeRegions was inconsistent. Given parent A and 3 children B, C and D, we collect DrawCommands like this: A, B, C, D but NodeRegions were collected as B, C, D, A which neither matches draw order, nor a reverse of it. This patch changes it so that NodeRegions are collected in drawing order (A, B, C, D) and we iterate backwards to find correct touch target (in case they overlap).
Reviewed By: ahmedre
Differential Revision: D3018034
Summary:
This is a hack to fix the Groups dialog bug so that we can get some
real data in production from using Nodes. This should be replaced with a
better solution in the near future.
Differential Revision: D3016859
Summary: CSSNode.addChildAt() calls dirty() to invalidate the node and propagate dirty flag up to the root. However, ReactShadowNode overrides dirty() for virtual nodes so it does nothing. This results in bugs where an added text doesn't trigger a measure pass because RCTText is never dirtied. To fix the bug, override addChildAt() in RCTVirtualText and explicitly call notifyChanged(true) to make sure hosting RCTText is dirtied and re-measured/re-laid out.
Reviewed By: ahmedre
Differential Revision: D3016827
Summary:
This code reverts D3004541, since it fixes the symptom instead
of the root cause. Root cause fix is in D3011191.
Differential Revision: D3011291
Summary: @public Split dispatchViewUpdates into two methods, which enables subclasses to commit pending ui operations, even when no root node is present.
Differential Revision: D3011191
Summary:
getLayoutWidth is the same as right - left, and since we have right
and left, we can save a method call.
Reviewed By: sriramramani
Differential Revision: D3010697
Summary:
In D2980358, alignment was implemented for nodes. This unfortunately
introduced a bug, which is that when we have a BoringLayout that is set to
ALIGN_CENTER, it can't be seen. This is a result of the fact that the width
passed in to BoringLayout is Integer.MAX_VALUE. Since measure has already
been called at this point, we can just pass the layout's width as the width
of the BoringLayout.
Reviewed By: sriramramani
Differential Revision: D3004971
Summary:
Groups had a crash when running with React with Nodes when returning
from a search screen. This was due to the fact that the node representing a
ShimmerFrameLayout was being dropped, and then later we were trying to detach
it. Since the view was already dropped, we shouldn't try to detach it since
it's already dropped and removed from the view hierarchy.
Reviewed By: sriramramani
Differential Revision: D3004541
Summary:
We keep a list of FlatShadowNodes that mount to Views that we want to delete, and only flush it at the end of an update cycle. This results in a situation where a root view is being removed before children are removed, which results in a crash in NativeViewHierarchyManager because a View that we are trying to remove no longer exists. There are a few approaches to fix the issue:
a) make a check if a View exists before removing it. While works, it removes a bug protection when we erroneously trying to remove a View that no longer exists (such as this). I'd prefer to keep the check in place
b) flush the views-to-drop queue. This works, but does some extra work in UI thread (namely, removing Views that would be removed anyway)
c) trim the views-to-drop queue to remove any Views that will be removed anyway. This does a tiny bit of extra work in BG thread, but less work in UI thread.
This diff implements option c).
Reviewed By: ahmedre
Differential Revision: D2990105
Summary:
Code in FlatUIImplementation.manageChildren() incorrectly assumed that moveFrom is sorted and moveTo is not, which is actually reverse: moveFrom is not sorted, and moveTo is. This means that we need to sort moveFrom before we can traverse it, and that we no longer need to sort moveTo (we did it by moving nodes to mNodesToMove first and then sorting it).
The sorting algorithm used is borrowed from Android implementation of insertion sort used in DualPivotQuicksort.doSort() when number of elements < INSERTION_SORT_THRESHOLD(32) which is 99.999% the case in UIImplementation.manageChildren() (most of the time this array is either empty or only contains 1 element).
Another (very rare) bug this is fixing is that the code only worked for FlatShadowNodes, but not all shadow nodes are FlatShadowNodes (there are rare exceptions, such as ARTShape, ARTGroup etc). New code works with all types of shadow nodes.
Reviewed By: ahmedre
Differential Revision: D2975787
Summary: We are currently traversing entire tree every time there is any update to any of the nodes, which is hugely inefficient. Instead, we can early out for nodes that are known to contain no updates. This saves a lof of CPU. This optimization can be turned off, and an Exception will be thrown if there was an unexpected update.
Reviewed By: ahmedre
Differential Revision: D2975706
Summary:
Fix screenshot tests for React with nodes. It was broken due to
calling clipRect with bounds of [-∞, ∞], which, due to a bug in Canvas that
appeared in screenshot tests, caused the view not to draw. Since this is a
no-op anyway, this patch just doesn't call clipRect when we have infinite
bounds.
Differential Revision: D2975494
Summary: Right now invalidate always tell the root node that the tree is dirty, and next update will traverse the entire tree in search of changes. While this works correctly, it's not the most efficient implementation. It is more efficient to store dirty flag in every node, and skip entire subtrees if this node and all descendants are already up to date. This diff is a first step towards that optimization.
Reviewed By: ahmedre
Differential Revision: D2955197
Summary:
Examples that use defaultValue as part of their declaration (such as
those examples under UIExplorerApp's TextInput) were being ignored. This patch
supports having text set directly on RCTTextInput and handles it properly.
Note that this patch depends on D2962643 and D2964847, without which the
TextInput example will look wrong.
Differential Revision: D2968002
Summary:
There are 2 issues in removeChild() implementation.
a) There is a chance that a node that we are removing will be mounting to a View, but the create view request has not be created so there is no backing View for it yet. In that case, FlatNativeViewHierarchyManager.dropView() will throw an Exception failing to find the View. The fix is to only dropView() if one was (requested to be) created.
b) If the shadow node that we are removing doesn't mount to a View, but one or more of its children do, those Views will leak because noone is removing them. The fix is to recursively call removeChild() until we find a node that mounts to a View.
Reviewed By: ahmedre
Differential Revision: D2974938
Summary:
OnLayoutEvent was incorrectly dispatching x/y coordinates relative to native View instead of relative to parent. This was causing issues in many cases, such as when Node was mounting to a View, in which case x/y would always be 0. This diff is fixing it.
This diff also caches last OnLayoutEvent to avoid dispatching the event on every layout even when layout didn't chance.
Reviewed By: ahmedre
Differential Revision: D2955087
Summary:
Setting the color for a TextInput with nodes was broken. The text color was
not being applied due to an optimization that prevented setting spans if
begin and end were the same (which is the case for an empty TextInput).
This patch depends on D2962643.
Differential Revision: D2962394
Summary:
The spannable flags for RCTVirtualText were always being set to
INCLUSIVE_EXCLUSIVE - this is different than the behavior that is found in
ReactTextShadowNode, which sets EXCLUSIVE_INCLUSIVE as the default flag
unless the text is at the beginning.
This is needed to fix various problems with TextInput, including the handling
of empty spans (see also D2962394 which depends on this patch), and making the
behavior consistent when styled children of a TextInput are changed.
Differential Revision: D2962643
Summary:
Implement measure for RCTTextInput. This is (almost) the same as
the one implemented for ReactTextInputShadowNode.
Differential Revision: D2964847
Summary:
There are 2 reasons why someone would call StateBuilder.ensureBackingViewIsCreated():
1) to make sure a View is created, because we are going to use it NOW
2) make sure react styles are applied to View, which doesn't really need the View to be created immediately
This diff is splitting the method into 2, without changing behavior. Difference between the methods' signatures is coming from the fact that 1) never takes styles and 2) possibly takes styles.
This is a pure refactoring diff and should have no change in functionality or behavior.
Reviewed By: ahmedre
Differential Revision: D2916697
Summary:
There is a rare case in React Native when a hierarchy is created and then *immediately* discarded all in one transaction. This is causing a View leak, because a View is created and then never attached to a hierarchy because it shadow node got detached. Since we never attached the View to the hierarchy, we cannot do a detach either and the View is kept in NativeViewHierarchyManager forever, causing a View leak. To fix the issue, don't create a backing View whenever a shadow node mounts to a View. Instead, put the create request into a queue and ONLY execute it if a shadow node is still attached to a hierarchy. This is fixing the View leak because will not create a View unless it's going to be attached somewhere.
The same logic applies to View style update (we don't want to update a View that is going to be detached from a hierarchy).
Reviewed By: ahmedre
Differential Revision: D2916826
Summary:
There are 2 reasons why someone would call StateBuilder.ensureBackingViewIsCreated():
1) to make sure a View is created, because we are going to use it NOW
2) make sure react styles are applied to View, which doesn't really need the View to be created immediately
This diff is splitting the method into 2, without changing behavior. Difference between the methods' signatures is coming from the fact that 1) never takes styles and 2) possibly takes styles.
This is a pure refactoring diff and should have no change in functionality or behavior.
Reviewed By: ahmedre
Differential Revision: D2916697
Summary:
When layout happens, left/top/right/bottom coordinates (and thus clip-*, too) are sometimes not at a pixel boundary for 2 reasons:
a) width/height in Flexbox are floats, and can contain any value, not just a whole pixel. E.g. style={{width: 3.1415926}} is perfectly valid
b) floating point arithmetics sometimes leads to values barely outside of pixel boundaries (width 18.0f can become 18.000001f when a sibling/child size changes).
a) is \"breaking\" screenshot tests, which slightly but differ from reference implementation
b) causes extra View updates/redraws for no reason
This patch is rounding DrawCommand bounds to a whole pixel to avoid these 2 issues.
Reviewed By: ahmedre
Differential Revision: D2934401
Summary:
Public
We wanted to do this before, but couldn't because touch events had timestamps
set by the system (and matched System.currentTimeMillis), but now we set those
timestamps! The idea behind this change is that System.currentTimeMillis is
unreliable, but nanoTime isn't, and it also guarantees that we will never have two events with the same
timestamp.
We're still seeing crashes with touch events not ending correctly in JS, this
might be the cause of that.
Reviewed By: foghina
Differential Revision: D2953917
Summary:
Many of StateBuilder methods take a lot of arguments, which makes it hard to read. This patch is doing a bit of cleanup by removing tag from the method signatures, because tag can be easily obtained from the node itself.
This is a pure refactoring diff and should have no functional changes.
Reviewed By: ahmedre
Differential Revision: D2915815
Summary: Both DrawView and AbstractDrawCommand have clipping logic, this diff is moving out logic into a common base class. This also reverts the screenshot tests fix, which was causing issues with overflow: visible.
Reviewed By: ahmedre
Differential Revision: D2933780
Summary:
The current AndroidView stipulates that the backing shadow node can't
be a FlatShadowNode. In some cases, however, we want to apply some of the same
logic (ex not adding NodeRegions, etc) to other ViewManagers that have a
FlatShadowNode backing (and that don't necessarily create a FlatViewGroup).
This commit renames AndroidView to NativeViewWrapper, and re-introduces
AndroidView as an interface, so that logic for padding, NodeRegions, etc can
be shared.
Differential Revision: D2942387
Summary: Not every CSSNode in a hierarchy is a FlatShadowNode, some virtual nodes can be ReactShadowNodes for compatibility with ART nodes. This diff fixes StateBuilder unconditionally casting a node to FlatShadowNode, which is causing a crash in Groups.
Reviewed By: nickholub
Differential Revision: D2941031
Summary: These methods (mostly getters/setters) are not meant to be overriden, so let's make them final. Hopefully, they will inline better, too.
Reviewed By: ahmedre
Differential Revision: D2933869
Summary:
@public Relax the constraint on ReactTextInputManager.
The TextInput Advanced screen looked different with and without
nodes, namely child Text items were not being rendered on the Nodes version.
This patch fixes that.
Differential Revision: D2930800
Summary: FlatUIImplementation.handleCreateView was missing an Override annotation. This diff fixes it.
Reviewed By: sriramramani
Differential Revision: D2919596
Summary: Currently, we wrap all unknown shadow nodes with AndroidView. This works great, except when the shadow node is virtual, i.e. it *doesn't* mount to a View. In this case, we just need to keep it in the hierarchy as is. Fixes ARTSurfaceView not working correctly in groups.
Reviewed By: ahmedre
Differential Revision: D2933325
Summary: Software Canvas uses ints to represents boundaries (because it is backed by Bitmap that has scalar size), whereas Hardware Canvas uses floats to represent boundaries. This results in a bug in Software Canvas where clipping with floats close to or outside of int range results in int overflows and incorrect clipping. To fix the issue, compute the clip boundaries manually instead of using Canvas.clipRect() method (that contains the bug).
Reviewed By: sriramramani
Differential Revision: D2919509
Summary: There is a bug in border drawing code that will not draw the border if the element has a background color. This diff fixes it.
Reviewed By: sriramramani
Differential Revision: D2919549
Summary: ImageRequestHelper was not handling data: scheme correctly, which resulted in images failing to load. This diff is fixing it by considering \"data:\" as a Uri resource, and piping it appropriately.
Reviewed By: sriramramani
Differential Revision: D2919403
Summary: Previously, RCTImageView/DrawCommand would always clip for specific scale types (such as CENTER_CROP), but this is incorrect if we want to allow overflow: visible on RCTImageView (which iOS allows). This patch tweaks the clipping condition from paddingLeft/paddingTop < 0 (i.e. image wants to draw outside of its bounds) to actual image rect being outside of clip rect. Previously, that would mean exact same thing, but now that clip rect is aware of overflow: visible, it matters, allowing RCTImage to not clip when we want it to draw outside of the boundaries.
Reviewed By: ahmedre
Differential Revision: D2873350
Summary:
Previously, every node would be clipped by its own boundaries. This made sense, because
a) RCTView cannot draw outside of its bounds, so clipping is harmless
b) all other node types were not allowed to control overflow behavior, and for them overflow was implicitly set to hidden, which means it should clip.
This diff changes the logic so that overflow can be set on any node (image, text, view etc).
The change has an important implication that make the diff a little trickier that it could be: AbstractDrawCommand clipping logic needs to be relaxed. Previously, clip bounds were *always* intersected with node bounds, which means that clip rect was always within node rect. This is no longer true, and thus shouldClip() logic needs to be modified.
Because of the above, RCTText no longer needs to artificially clip bounds against layout width/height.
Note: RCTImage is still not working with overflow: visible correctly (it still always clips). This is fixed in a follow up diff.
Reviewed By: ahmedre
Differential Revision: D2867849
Summary:
There is an assert in FlatViewGroup.reactTagForTouch() that says that TouchTargetHelper should not allow returning getId() when pointer events are BOX_NONE. This is not entirely accurate.
This acturally method is invoked in 2 different contexts. Main context is to find a touch target, and in that context the method indeed should never return getId() if pointer events are BOX_NONE. There is however a TouchTargetHelper which actually expects that reactTagForTouch() *may* return getId(), in which case it will perform logic to not all this method be invoked again from main context.
In other words, this assert needs to be removed because it is entirely possible to return getId() when pointer events are BOX_NONE. Ideally, these would be 2 different methods, but ReactCompoundView interface only defines a single reactTagForTouch() method.
Reviewed By: ahmedre
Differential Revision: D2873931
Summary: When padding is applied to RCTText, the text it renders should be offset by that padding. This is what iOS is doing.
Reviewed By: sriramramani
Differential Revision: D2872039
Summary: A simple refactoring diff that should make code a little easier to read. No functional changes.
Reviewed By: ahmedre
Differential Revision: D2867718
Summary: Exact same class is needed for Groups, and probably for other apps that want to work with Nodes, too, so let's extract it into a helper class to simplify coding.
Reviewed By: sriramramani
Differential Revision: D2873943
Summary:
Nodes create a FlatViewGroup for a root node element, and NativeViewHierarchyManager assigns it an id that matches root node it. Now this top-level FlatViewGroup is added to a ReactRootView. In non-nodes, this ReactRootView has an id that matches root View id, and when this ReactRootView gets detached from Window, it sends an event to NativeViewHierarchyManager that says that all the children of this View must be removed recursively. This works great in non-Nodes, but fails in Nodes because ReactRootView has no id (-1) and NativeViewHierarchyManager fails to find a corresponding ReactShadowNode, throwing an Exception. To fix the issue and make it work again we need to assign this View id of the top level shadow node. This creates a minor issue, where 2 Views (ReactRootView and its only child) share the same id, but that is not a problem because we don't enforce uniqueness of the ids, and don't rely on getViewById().
This was originally implemented, but then I removed it because I thought it wasn't truly needed. Turns out, it is needed.
Reviewed By: sriramramani
Differential Revision: D2873995
Summary: This diff implements ImageLoadEvents (ON_LOAD, ON_LOAD_END and ON_LOAD_START) in RCTImageView. ON_ERROR and ON_PROGRESS are easy to implement, too, but these 2 are supposed to carry extra information (error message and progress) but ImageLoadEvent doesn't support a payload yet (I'll add them in a separate patch).
Reviewed By: ahmedre
Differential Revision: D2824772
Summary: React provides properties to support shadows for Text, this diff implements it for Nodes.
Reviewed By: ahmedre
Differential Revision: D2817212
Summary: Minor optimization/cleanup: instead of creating an instance of FontStylingSpan for every RCTVirtualText, start with a global immutable instance of use copy-on-write when any of the properties change.
Reviewed By: ahmedre
Differential Revision: D2817156
Summary: Wrong order or top/right -> right/top means that clipping can be incorrect. I didn't notice it because visual result in many cases would still be the same (especially with overflow: visible being default and clipping being mostly disabled). Also only background was clipped incorrectly, and most texts don't have a background.
Reviewed By: ahmedre
Differential Revision: D2816432
Summary: Small optimization that prevents empty NodeRegions from being collected. Those will never receive touch events anyway, so why bother allocating memory and iterating over them?
Reviewed By: ahmedre
Differential Revision: D2816355
Summary: RCTText may modify its DrawCommand on collectState(), which updateNodeRegion() relies on. This means that order of the two is important: call collectState() first, followed by updateNodeRegion(). This fixes the bug where am RCTText may sometimes not respond to clicks (because its NodeRegion would be empty).
Reviewed By: ahmedre
Differential Revision: D2816295
Summary: NodeRegions are touch regions within hosting View, and while in most cases they are the same as View boundaries, there is one case where it's not true: TextNodeRegion. When mounted to a View, TextNodeRegion will have a bounds of (0,0,width,height) which is clearly different from (left,top,right,bottom). Initially I assumed they would always be the same so we could use information stored in NodeRegion (should probably be called TouchRegion) to update node's View boundaries, but it breaks RCTTextView when it mount to a View (because it would either contain incorrect bounds, or View will be laid out incorrectly). Right now touch is not working on RCTView that mounts to a View. To fix the issue, separate the 2 concepts.
Reviewed By: ahmedre
Differential Revision: D2816268
Summary: Small optimization. Once we mount a Node to a View, its NodeRegion is not used anymore with RCTText being an exception, but it will correct itself automatically upon updateNodeRegion call. This patch allows the dead object to get garbage collected.
Reviewed By: ahmedre
Differential Revision: D2816331
Summary: Alternative implementation of DrawImage using DraweeHierarchy instead of ImagePipeline directly. Yields same results, but potentially more stable. We'll run tests to measure performance of both.
Reviewed By: ahmedre
Differential Revision: D2746197
Summary:
Moves ReactProp and ReactPropGroup to `com.facebook.react.uimanager.annotations`. This is needed
so that future annotation processor can run on code inside the com.facebook.react.uimanager package.
@public
Reviewed By: astreet
Differential Revision: D2754842
Summary: View.invalidate() will not actually invalidate a View if it has width or height equal to 0. This is causing problems with overflow: visible. A quick fix applied here is to invalidate slightly larger region that the View bounds to bypass the optimization.
Reviewed By: ahmedre
Differential Revision: D2800920
Summary: Virtual shadow nodes, such as RCTRawText, RCTTextInlineImage etc cannot be mounted to a View (ViewManager will throw an Exception if we ever try to). This diff is adding a check to make sure that Exception is never thrown.
Reviewed By: ahmedre
Differential Revision: D2800869
Summary: UIImplementation.measure() can only measure shadow nodes that map to native Views. As a result of this, every time we tried to measure a shadow node that doesn't map to a View, we trigger callback with no data (to indicate an error). To fix this issue, walk up until we find a node that maps to a View, then measure that View and adjust for the bounds of a virtual child.
Reviewed By: ahmedre
Differential Revision: D2800960
Summary:
Everything (but Views) are drawn using AbstractDrawCommand (or its derivative, like DrawBorder or DrawBackgroundColor) and supports clipping properly. Views however are drawn using an assumption that Android will clip them manually. This is however not always true. One example is if an element A mounts to a View, and its parent B doesn't but has overflow: hidden and thus should clip the child.
There are 2 ways to fix this:
- pop every element that has overflow: hidden to its own View. In this case, its children will always be correctly clipped. This is however very inefficient, especially if overflow: hidden is default (which it is!) which means that almost every React element must be backed by an Android View.
- add clipping information to DrawView, similar to how AbstractDrawCommand has it.
This diff implements the latter approach.
Reviewed By: ahmedre
Differential Revision: D2792375
Summary: RootFlatShadowNode always mounts to a (top-level) View but was never marked as one that mounts to a View. This diff fixes it. Nothing in the code relied on it being marked as mounting to a View, so it worked fine. A follow up path that implements UIImplementation.measure() for nodes that don't mount to a View goes up until it finds first mounting node, and it was crashing with NPE because it tried to access RootFlatShadowNode's parent (and there isn't one).
Reviewed By: sriramramani
Differential Revision: D2800818
Summary:
React allows nesting <Image> inside <Text>, in which case it turns into an RCTTextInlineImage element. RNFeed is using it in a few places and thus we need to support it, too.
This diff implements it with InlineImageSpan (WithPipeline, and WithDrawee separately).
Reviewed By: ahmedre
Differential Revision: D2792569
Summary: D2768643 disabled View clipping of FlatViewGroup's children by calling setClipChildren(false). Turns out, instead of disabling clipping on the View this method is called on, it disables clipping on the children, instead. While we want the clipping disabled on all children that are FlatViewGroups, it also means that everyone else gets the clipping disabled as well. This has issues with ScrollView that stopped clipping its scrolling content, resulting in visual glitches. To fix the issue, manually clip all the Views that are not FlatViewGroups.
Reviewed By: ahmedre
Differential Revision: D2792411
Summary: This diff add an ImageRequestHelper class to reuse code that creates ImageRequest in both RCTImageView and (upcoming) RCTTextInlineImage
Reviewed By: ahmedre
Differential Revision: D2792548
Summary: Minor cleanup; renames BitmapRequestHelper to PipelineRequestHelper and adds BitmapUpdateListener interface. I plan reusing these classes in an upcoming RCTTextInlineImage implementation.
Reviewed By: ahmedre
Differential Revision: D2792535
Summary: AbstractDrawCommand's bounds are supposed to be the rectangle that the DrawCommand will draw into, so that it can compare bounds against clip rect bounds and reliable skip clipping when it's not needed. It is however not true for RCTText that can create text Layout that in some cases can go out of it's requested bounds (happens with TextView, too). To fix the issue, instead of passing requested bounds, pass the actual ones. In this case, AbstractDrawCommand will make sure to clip DrawTextLayout if for some reason it draws outside of the allowed boundaries.
Reviewed By: ahmedre
Differential Revision: D2786306
Summary:
@public React allows excluding certain elements from touch handling by assigning `PointerEvents` filter to them, such as BOX_NONE - this element will not receive touch but its children will, BOX_ONLY - only this element will receive pointer event and not children, NONE - neither this element nor its children will receive pointer events, and AUTO - pointer events are allowed for both this element and its children.
This diff adds PointerEvents support to flat RCTView. Most of the implementation is copied from ReactViewManager/ReactViewGroup. One small change is made to TouchTargetHelper to ensure that it works correctly with virtual nodes when their parent has PointerEvents set to PointerEvents.BOX_NONE.
Reviewed By: ahmedre
Differential Revision: D2784208
Summary: There is a small bug in DrawBorder where we forget updating color for a left border, which makes the border draw with whatever color was previously set to the Paint. This diff fixes it by updating the color.
Reviewed By: ahmedre
Differential Revision: D2779511
Summary: When setJSResponder() is called on a shadow node that doesn't mount to a View, React runtime will crash in NativeViewHierarchyManager because it will fail to find a corresponding View. To fix the issue, make sure we forceMountToView() before we call enqueueSetJSResponder().
Reviewed By: ahmedre
Differential Revision: D2779523
Summary: D2772438 removed some unused imports, and a parallel build landed that uses one of the imports. Both diffs landed and now master is broken. This diff is fixing it.
Reviewed By: ahmedre
Differential Revision: D2779442
Summary:
Prior to this patch DrawCommands weren't get clipped by parent DrawCommands at all. For example, a <View> element with size 200x200 with overflow:hidden should clip its child which is 400x400, but this didn't happen. However, if parent <View> would mount to an Android View, it would clip the child regardless of the overflow attribute value (because Android Views always clip whatever is drawing inside that View against its boundaries).
This diff is fixing these issue, implementing overflow attribute support and making clipping behavior consistent between nodes that mount to View and nodes that don't.
Reviewed By: ahmedre
Differential Revision: D2768643
Summary: I lost FlatViewGroup.verifyDrawable(Drawable) method during one of the rebases. Re-adding it now because hotspot drawable is not working without it.
Reviewed By: ahmedre
Differential Revision: D2772460
Summary: Previously, manageChildren() would throw an Exception if moveFrom != null or moveTo != null. This is obviously not correct, because no matter how rare these events are, they actually happen in practice. This diff re-implements manageChildren() to support all the cases. It does so by first removing all the elements that need to be removed. During removal, those elements that need to be moved will be temporarily put into `mNodesToMove` array. Then the next step is to add all elements (including new elements to add, and existing elements to move). There is an fast path when only one of another is present. If both types are present, they need to be sorted, first, to maintain correct orded. A similar optimization is applied to `removeChildren()`: there is a fast path when moveFrom == null and a another fast path when removeFrom == null. When both are != null, a merge sort is used (it is assumed that both moveFrom and removeFrom are sorted).
Reviewed By: ahmedre
Differential Revision: D2768689
Summary: There is an OnLayoutEvent that needs to be dispatched when a ReactShadowNode gets re-laid out. Some applications rely on it, so we should support it. This diff adds this functionality.
Reviewed By: ahmedre
Differential Revision: D2768625
Summary: RCTView has a property called nativeBackgroundAndroid that shows a ripple effect (or any other Drawable) when pressed and holded. This diff is adding support for the property.
Reviewed By: ahmedre
Differential Revision: D2768671
Summary: NodeRegion is only able to describe a rectangular region for touch, which is not good enough for text, where we want to be able to assign different touch ids to individual words (and those can span more than one line and in general have non-rectangular structure). This diff adds TextNodeRegion which inserts additional markers into text Layout to allow individual words to have unique react tags.
Reviewed By: ahmedre
Differential Revision: D2757387
Summary: Views that can contain other Views need to have their ViewManager to extend ViewGroupManager. Otherwise, it may not remove child Views correctly when a parent View is being detached. This diff is changing FlatViewManager that create FlatViewGroups (that can have child Views) to extend from ViewGroupManager.
Reviewed By: ahmedre
Differential Revision: D2768667
Summary: RCTImageView.setBorderWidth() is shadowing ShadowLayoutNode.setBorderWidths() because both are annotated with `ReactProp borderWidth`. To fix the issue, override setBorder instead (which is what LayoutShadowNode.setBorderWidths delegates to).
Reviewed By: ahmedre
Differential Revision: D2763938
Summary:
In ReactNative, we are fully controlling layout of all the Views, not allowing Android to layout anything for us. This is done by making onLayout() of the top-level View in the hierarchy to be empty. This works fine because we explicitly call measure/layout for all the Views when they need to be re-measured or re-laid out. There is however one case where this doesn't happen automatically: some Android Views such as DrawerLayout or ActionBar have children that don't have shadow nodes associated with them (such as a title in ActionBar). This results in situations where children of AndroidView will call requestLayout but they will never get relaid out, because shadow hierarchy doesn't know about them. Example: ActionBar has a seTitle method that will internally call TextView.setTitle() and that TextView will call requestLayout because its size may have changed. However, that TextView will never be remeasured or relaid out.
This diff is fixing it by keeping track of everyone who called requestLayout. Then, at the end of the update loop we go over the list a manually remeasure and relayout those Views.
Not a huge fan of how this is implemented (there MUST be a better way) but this works with least efforts. I'll see if I can improve it later.
Reviewed By: ahmedre
Differential Revision: D2757485
Summary:
There is currently a bug where we never release any Views that no longer display, still storing hard references in NativeViewHierarchyManager. This diff is fixing this bug, and here is how:
a) there is already logic in place to drop FlatShadowNodes (UIImplementation.removeShadowNode).
b) there is already logic in place to drop Views (NativeViewHierarchyManager.dropView(int reactTag) - used to private but needs to be protected so I can call it)
c) (the missing part) when we are about to drop a FlatShadowNode, check if it mount to a View (i.e. there is a View associated with that node), put it into a ArrayList. When we finished updates to a nodes hierarchy (which happens in non-UI thread), collect ids from those nodes and enqueue a UIOperation that will drop all the Views. We can either forward nodes as FlatShadowNode[], or only ids as int[]. Both should be fine, but as a rule of thumb we don't touch shadow node hierarchy from UI thread (as we don't touch Views from non-UI thread) so passing int[] is what this code is doing.
Reviewed By: ahmedre
Differential Revision: D2757310
Summary: Virtual nodes (such as RCTRawText and RCTVirtualText) have no state or node regions, don't need to be laid out, and thus should not be checked for state.
Reviewed By: ahmedre
Differential Revision: D2757089
Summary: Any padding that a FlatShadowNode is assigned by React runtime should be translated to a backing Android View so it looks correct and lays out children accordingly.
Reviewed By: sriramramani
Differential Revision: D2756562
Summary: This diff adds an `AndroidView` as a proxy for custom Views in FlatUIImplementation. Any ReactShadowNode that FlatUIImplementation doesn't recognize (because they don't extend from FlatShadowNode) will be wrapped with AndroidView to ensure that it measures and displays correctly. While not perfect, this is the easiest way to support custom Views (EditTexts, DrawerLayouts, ScrollViews etc).
Reviewed By: ahmedre
Differential Revision: D2751716
Summary: @public There are some properties, such as alpha or scale that we ONLY handle on a View level. This means that whenever we encounter a FlatShadowNode with this property, it should be mapped to a View. This diff is doing exactly this.
Reviewed By: ahmedre
Differential Revision: D2694495
Summary:
This diff pulls in my changes to css-layout algorithm. (The change: https://github.com/facebook/css-layout/pull/154)
This is a breaking change, since it adds a new `height` parameter to all measure functions.
So I've fixed all existing implementations just by adding a new unused parameter `height` - it's up to owners of these functions whether they want to use it or not.
Reviewed By: foghina
Differential Revision: D2757965
Summary: Normally, order or `measure/layout` and `onAttachedToWindow` shouldn't matter. However, `DrawerLayout` has a `boolean mFirstLayout` flag that it resets to true in `onAttachedToWindow` that makes it ignore first layout, and it leads to bugs. To fix the issue, we need to make sure that we first call `onAttachedToWindow` and only then we call `measure/layout`. The easiest way to do it is to delay measure/layout calls until all the views are attached to their parents. This diff implements the mentioned logic.
Reviewed By: sriramramani
Differential Revision: D2694973
Summary: @public There are some properties that we want to handle on a View level, as opposed to a FlatShadowNode level. For example, scale or alpha, that can be done very efficiently in hardware. Once we pop FlatShadowNode to a separate View, we need to apply these properties. This is where `BaseViewManager` comes in handy.
Reviewed By: sriramramani
Differential Revision: D2694290
Summary: @public When Android dispatches `MotionEvent` to `ReactRootView`, it needs to find a correspoding react node that should receive it. To be able to do it, we need to store boundaries of every `FlatShadowNode` in `FlatViewGroup`. Then we can iterate over node boundaries and find one that contains the touch event coordinates.
Reviewed By: sriramramani
Differential Revision: D2694197
Summary: @public This diff adds a `FlatShadowNode.forceMountToView()` method that will render its contents in it own `View`.
Reviewed By: sriramramani
Differential Revision: D2564502
Summary: @public To render `View`s inside `FlatViewGroup`, we need to pass the parent to `DrawCommand.draw()` method. Used in a followup diff.
Reviewed By: sriramramani
Differential Revision: D2564478
Summary: @public Similar to a `DrawBorder` patch, this diff adds `DrawBackground` and implements `ViewProps.BACKGROUND_COLOR` property in `FlatShadowNode` with it.
Reviewed By: sriramramani
Differential Revision: D2564466
Summary: @public Initial implementation of RCTView doesn't support borders, this diff fixes it by implementing a `DrawBorder`.
Reviewed By: sriramramani
Differential Revision: D2564424
Summary: @public Initial RCTImageView implementation only supported 'src', 'tintColor' and 'resizeMode'. This diff adds support for the rest of the properties: 'borderColor', 'borderWidth' and 'borderRadius'. `AbstractDrawBorders` class is reused in a follow up diff to draw borders for 'RCTView'.
Reviewed By: sriramramani
Differential Revision: D2693560
Summary: @public This patch adds basic support for RCTImageView (only 'src', 'tintColor' and 'resizeMode' properties are supported for now), and a concept of AttachDetachListener that is required to support it to FlatUIImplementations.
Reviewed By: sriramramani
Differential Revision: D2564389
Summary: @public This is a pure refactoring diff makes `StateBuilder` code a little bit easier to read. This gets increasingly important as new features with similar logic are added to `StateBuilder`.
Reviewed By: sriramramani
Differential Revision: D2564342
Summary: @public `RCTVirtualText` is creating a new `CustomStyleSpan` on every `applySpans()` call, which is not very efficient. We can cache and reuse unchanged `CustomStyleSpans` for efficiency. This patch is doing just that.
Reviewed By: sriramramani
Differential Revision: D2564366
Summary: @public Initial version of FlatUIImplementation lacks any primitives support (such as RCTText, RCTImageView or RCTView). This diff add the first part, RCTText (alongside with RCTVirtualText and RCTRawText).
Reviewed By: sriramramani
Differential Revision: D2693348
Summary:
Improvement over https://github.com/facebook/react-native/pull/11469.
Depends on https://github.com/react-native-community/boost-for-react-native/issues/1, **don't merge before it is fixed**.
It would be more in line with other dependencies to depend only on github for thirdparty bridge dependencies.
**Test plan (required)**
- Circle (testing with caches cleaned)
- ./gradlew ReactAndroid:packageReactNdkLibsForBuck (check twice to make sure caches work)
REACT_NATIVE_BOOST_PATH=./path-to-local-boost/
- ./gradlew ReactAndroid:packageReactNdkLibsForBuck (check twice to make sure caches work)
Closes https://github.com/facebook/react-native/pull/11511
Differential Revision: D4348098
fbshipit-source-id: 5c2f25cc395ae0cad19d56b7c0b2b102513580fb
Summary: Show a toast (since there isn't an easy way to show the yellow box)
Reviewed By: AaaChiuuu
Differential Revision: D4336435
fbshipit-source-id: 01b0dbdaabf51be3d23aab5c72ab2a701fcb8f80
Summary:
An exception is thrown when the native animation code attempts to play an animation on a view that hasn't been created yet. This can happen because views are created in batches. If this particular view didn't make it into a batch yet, the view won't exist and an exception will be thrown when attempting to start an animation on it.
This change eats the exception rather than crashing. The impact is that the app may drop one or more frames of the animation.
**Notes**
I'm not familiar enough with the Android native animation code to know whether or not this is a good fix. My team is using this change in our app because dropping animation frames is better than crashing the app. [This is the code](c612c61544/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIViewOperationQueue.java (L874-L892)) that is creating the views in batches. Hopefully my PR at least provides some insight into the cause of the bug.
This may fix#9887
Closes https://github.com/facebook/react-native/pull/10907
Differential Revision: D4340129
Pulled By: lacker
fbshipit-source-id: 69160d9e71281a96a7445d764b4715a3e54c0357
Summary:
Boost is officially hosted on SourceForge which has ab SSL problem that Gradle complains about and also it is sometimes unavailable.
I switched to using npm hosted (yarnpkg mirrored for performance) boost lib exactly the same as from Source Forge.
Other alternatives considered:
- CDN e.g. mirror.nienbo.com started responding with 4XX code when requested by Gradle
- File sharing like DropBox are not for mass anonymous downloads
- Github is not good for binary files and is throttled for anonymous raw file downloads
- S3 or similar. Requires amazon account for maintenance and does not expose semver API and other nice features that npm has
In the future I'd like to try Yarn as dependency management tool for bridge builds, this could be the first step.
**Test plan (required)**
- Circle (testing with caches cleaned)
- `./gradlew ReactAndroid:packageReactNdkLibsForBuck` (check twice to make sure caches work)
- `REACT_NATIVE_BOOST_PATH=./bridge-dependencies/node_modules/boost-react-native-bundle ./
Closes https://github.com/facebook/react-native/pull/11469
Differential Revision: D4339446
Pulled By: mkonicek
fbshipit-source-id: ccc9196e9b675c16a235a318c4861aaa4e263d6e
Summary:
Android has a text API called breakStrategy for controlling how paragraphs are broken up into lines. For example, some modes support automatically hyphenating words so a word can be split across lines while others do not.
One source of complexity is that Android provides different defaults for `breakStrategy` for `TextView` vs `EditText`. `TextView`'s default is `BREAK_STRATEGY_HIGH_QUALITY` while `EditText`'s default is `BREAK_STRATEGY_SIMPLE`.
In addition to exposing `textBreakStrategy`, this change also fixes a couple of rendering glitches with `Text` and `TextInput`. `TextView` and `EditText` have different default values for `breakStrategy` and `hyphenationFrequency` than `StaticLayout`. Consequently, we were using different parameters for measuring and rendering. Whenever measuring and rendering parameters are inconsistent, it can result in visual glitches such as the text taking up too much space or being clipped.
This change fixes these inconsistencies by setting `breakStrategy` and `hyphenat
Closes https://github.com/facebook/react-native/pull/11007
Differential Revision: D4227495
Pulled By: lacker
fbshipit-source-id: c2d96bd0ddc7bd315fda016fb4f1b5108a2e35cf
Summary:
The reason for this change is to implement `allowFontScaling` on the Android's React Native Text component. Prior to this PR `allowFontScaling` only works for iOS.
The following link contains images of `allowFontScaling` working in Android on small, normal, large, and huge system fonts (from native Android display settings)
http://imgur.com/a/94bF1
The following link is a video of the same thing working on an Android emulator
https://youtu.be/1jTlZhPdj9Y
Here is the sample code snippet driving the video/images
```
render() {
const size = [12, 14, 16, 18];
return (
<View style={{backgroundColor: 'white', flex: 1}}>
<Text>
Default size no allowFontScaling prop (default true)
</Text>
<Text allowFontScaling={true}>
Default size allowFontScaling: true
</Text>
<Text style={{ marginBottom: 10, }} allowFontScaling={false}>
Default size allowFontScaling: false
</Text>
{ size.map(
Closes https://github.com/facebook/react-native/pull/10898
Differential Revision: D4335190
Pulled By: lacker
fbshipit-source-id: 0480809c44983644ff2abfcaf4887569b2bfede5
Summary:
Currently React Native is opinionated in that the easiest approach is to extend ReactActivity. However to more easily allow integrating with existing application, we should allow some of the methods in ReactNativeHost to be public, and this is a very good first step.
* There is no harm in making this public from what I can tell.
* This allows `ReactNativeHost` to be more easily used outside of the `ReactActivity` and `ReactActivityDelegate` ecosystem. (A `ReactFragment` would be a good example)
_No issues found_
**Test plan (required)**
* Run any sample app and verify it still works.
Make sure tests pass on both Travis and Circle CI.
Closes https://github.com/facebook/react-native/pull/11329
Differential Revision: D4287429
Pulled By: AaaChiuuu
fbshipit-source-id: 8cb76f3226aae3737af5f5bd6010d3eea8df9bfe
Summary:
When using React Native on Android on top of a game as an overlay, dialog windows sometimes get created with hardware acceleration disabled. This causes the UI to be unresponsive and anything that uses a TextureView stops working. Added a property for the modal view to make sure hardware acceleration flag is enabled when it's set to true.
**Test plan (required)**
set `hardwareAccelerated` property for Modal to force hardware acceleration on dialog windows on Android. Does nothing on iOS.
Closes https://github.com/facebook/react-native/pull/11421
Differential Revision: D4312912
Pulled By: andreicoman11
fbshipit-source-id: 9db6b2eca361421b92b24234b3501b5de0eecea7
Summary: This changes ReactImageView to pull the transform matrix for rounding from the scale type itself instead of a utility method that forwards to the same thing.
Reviewed By: lambdapioneer
Differential Revision: D4326549
fbshipit-source-id: 82e59e3c20f83beb1d454743e6dbbce8666de8a3
Summary:
The goal of this pull request is to make it easier for contributors to run Android tests locally, specifically the unit tests and integration tests. I added a bunch of checks to the local testing scripts that will warn you if your environment is misconfigured, and tell you how to fix it. I also updated the testing docs, so that the regular "Testing" page should be a decent resource to point people to when you are telling them "hey this pull request needs a test." Just Android, though, I haven't gotten to the iOS parts yet.
I also disabled a couple tests that seemed quite flaky while running on a local machine, and don't seem to be providing much value. In particular, the `TestId` test just hangs on my emulator a lot and has been flaky on CI in the past, so I removed about half of its test cases to make the sample app smaller. The testMetions test appears to be dependent on screen size so I commented it out.
Closes https://github.com/facebook/react-native/pull/11442
Differential Revision: D4323569
Pulled By: bestander
fbshipit-source-id: 9c869f3915d5c7cee438615f37986b07ab251f8c
Summary:
Currently any React Native apps that target API 23 or greater will crash on the first initial debug/dev build due to the overlay permission.
Sadly there isn't a concrete "request permission" baked into the Marshmallow permission system.
However, we can launch the overlay screen without starting the react app and once its turned on start the app.
- https://github.com/facebook/react-native/issues/10454 - targetSdkVersion 23 lead crash / App crash for targeting 23+
- https://github.com/facebook/react-native/pull/10479 - Add the overlay permission information / Larger discussion around targeting API 23+
- Intent to Overlay permission goes directly to the app in question, rather then the general full listing of applications. This allows a developer who is not familiar with the system to easily toggle the overlay without getting confused.
**Test plan (required)**
* Ran UIExplorer App on fresh install with Target 23
```
cd react-native
./gradlew :Examples:UI
Closes https://github.com/facebook/react-native/pull/11316
Differential Revision: D4286351
fbshipit-source-id: 024e97c08c40ee23646dd153794fcde7127b2308
Summary:
By default Android will put extra space above text to allow for upper-case accents or other ascenders. With some fonts, this can make text look slightly misaligned when centered vertically.
We have found that the effect is very noticeable with certain custom fonts on Android. On iOS the font aligns vertically as expected.
Android exposes a property `includeFontPadding` that will remove this extra padding if set to false. This PR exposes that to JS, and adds it to the documentation and UIExplorer.
Closes https://github.com/facebook/react-native/pull/9323
Differential Revision: D4266713
Pulled By: lacker
fbshipit-source-id: f9711254bc26c09b4586a865f0e95ef4bf77cf3f
Summary:
This PR fixes#11096.
I don't know enough the ReactAndroid's source code so I don't know if this is correct but I hope it is.
In a recent commit (d4b8ae7a8a), the `dispatchUpdates` method now returns a boolean to dispatch or not the `onLayout` event. This works well but if the content is unchanged, the line `nativeViewHierarchyOptimizer.handleUpdateLayout(this);` is never called. I don't know if it was intended but it was this which introduces my issue. I called this again even if the content didn't change. This was the behaviour before 0.38 so I guess I didn't break anything.
**Test plan (required)**
I tested my pretty big app with this fix and every screen is ok.
Closes https://github.com/facebook/react-native/pull/11222
Differential Revision: D4252101
Pulled By: astreet
fbshipit-source-id: 551559234631ac37245a854d81ba568f0ddb02dd
Summary:
This change suppresses access checking during reflection which makes reflection faster by decreasing its overhead.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11204
Differential Revision: D4250790
Pulled By: astreet
fbshipit-source-id: 0ee2f40dcadccc695980fcae14fafe1050acb52f
Summary:
Suppose that the user is scrolled to the bottom of a ScrollView. Next, the ScrollView's content is edited such that the height of the content changes and the current scroll position is larger than the new height of the content. Consequently, the user sees a blank ScrollView. As soon as the user interacts with the ScrollView, the ScrollView will jump to its max scroll position.
This change improves this scenario by ensuring that the user is never staring at a blank ScrollView when the ScrollView has content in it. It does this by moving the ScrollView to its max scroll position when the scroll position after an edit is larger than the max scroll position of the ScrollView.
Here are some pictures to illustrate how this PR improves the scenario described above:
**Test plan (require
Closes https://github.com/facebook/react-native/pull/11000
Differential Revision: D4250792
Pulled By: astreet
fbshipit-source-id: 940fff6282ad29c796726f68b4519cbdabbfe554
Summary:
ReactAndroid/build.gradle downloads a number of ad-hoc dependencies from the internet such as boost, JSC headers, and folly. Having the build depend on the internet is problematic. For example, if the site hosting the JSC headers was to go down, then CI builds would start failing.
This change introduces the environment variable REACT_NATIVE_DEPENDENCIES which refers to a path. Developers can pre-download all of the ad-hoc dependencies into that path and then the build process will grab the dependencies from that local path rather than trying to download them from the internet. This solution is in the spirit of the existing REACT_NATIVE_BOOST_PATH hook.
**Test plan (required)**
This change is used by my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11195
Differential Revision: D4247080
Pulled By: mkonicek
fbshipit-source-id: 7c4350339c8d509a829e258d8f1bf320ff8eef64
Summary:
Made modification to react-native code that reduces the communication channel overhead to ~50% of prior, in some cases, by caching the class-name of the java-script module/interface.
For me it reduced the run-time of the RCTDeviceEventEmitter.emit function from 1438ms to 715ms, over a period of 8 seconds in my Android app. My project requires many emit calls, as I'm transferring real-time EEG data from a Muse headband to my react-native UI to be graphed, so this optimization was very helpful in my case.
Closes https://github.com/facebook/react-native/pull/11118
Reviewed By: astreet
Differential Revision: D4232794
Pulled By: javache
fbshipit-source-id: 25ca1cfc170a343e71ff8915c3fa7e38884a402b
Summary:
The `FrescoModule` supports providing a custom image pipeline configuration. This module is created by `MainReactPackage` but `MainReactPackage` doesn't expose any way to customize the Fresco configuration. This change adds a parameter to `MainReactPackage`'s constructor so that the `FrescoModule`'s configuration can be customized by the app. A couple of design choices were made in this change:
- `MainReactPackage`'s new constructor parameter is a `MainPackageConfig`. Introducing `MainPackageConfig` enables `MainReactPackage` to nicely support new optional configuration options in the future. Imagine the alternative of each optional configuration being a separate parameter to the `MainReactPackage` constructor.
- `FrescoModule` exposes its default configuration as a builder object through the `getDefaultConfigBuilder` method. This enables app's to start with `FrescoModule`'s default configuration and then modify it.
**Test plan (required)**
Verified that passing a custom config based on React Nati
Closes https://github.com/facebook/react-native/pull/10906
Differential Revision: D4237054
Pulled By: mkonicek
fbshipit-source-id: 8a62a6f0e77ca5f6d35238950094686756262196
Summary:
"com.facebook.react.ReactPackage" is imported twice so fixed it to once.
Closes https://github.com/facebook/react-native/pull/11165
Differential Revision: D4236961
Pulled By: mkonicek
fbshipit-source-id: 84765dd9f8731b978972959f3825bf3c9c0684e3
Summary:
When using text inputs inside a ScrollView with `keyboardShouldPersistTaps=false` (default behavior) tapping another text input dismisses the keyboard instead of keeping it open and focusing the new text input which I think is the better and expected behavior.
See #10628 for more discussion about that. Note that this affects nothing but the behavior with text inputs unlike #10628.
cc satya164 MaxLap ericvicenti
Closes https://github.com/facebook/react-native/pull/10887
Differential Revision: D4178474
Pulled By: ericvicenti
fbshipit-source-id: 0c62ea2fac0017d559d1f8674b0a686a5e1b3d2d
Summary:
This PR removes dependency to Jackson third-party library in Android React Native.
Looking at some older PRs that got merged, it seems like some work had already been done to move away from Jackson.
Anyway, there was only two classes left with a dependency on Jackson. I refactored the code to use android built-in `JsonReader` and `JsonWriter` classes instead.
Prep work was done in https://github.com/facebook/react-native/pull/10516 introducing a few unit tests around serialization, to make sure that refactoring around serialization would not break things.
All references to Jackson in build systems files (BUCK files & build.gradle) have also been removed now that no code depend anymore on this third-party library.
Motivation behind this work is that third-party dependencies in Android React Native can prove to be a pain when trying to integrate React Native components into an already existing large Android application (I know this is not the most common use case for react-native ... yet ;P), that might a
Closes https://github.com/facebook/react-native/pull/10521
Differential Revision: D4226705
Pulled By: mkonicek
fbshipit-source-id: e3a7430a79dd00c871ba3c6a705b0b0c3ec3a701
Summary:
Expose aspectRatio style prop from css-layout to React Native.
This means the following will now work:
<View style={{backgroundColor: 'blue', aspectRatio: 1}}/>
Reviewed By: javache
Differential Revision: D4226472
fbshipit-source-id: c8709a7c0abbf77089a4e867879b42dcd9116f65
Summary:
Downloading from the CDN is much faster than from SourceForge, both on my home WiFi and at the office.
I checked using the `diff` utility that both files are identical.
**Test Plan**
Circle CI build on this PR.
Closes https://github.com/facebook/react-native/pull/11087
Differential Revision: D4226538
fbshipit-source-id: a30ec1d94fe3228342c4a198bf65df7a95e0c005
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
When native events where handled they were not sent to JS as an optimization but this caused some issues. One of the major one is touches are not handled properly inside a ScrollView with an Animated.event because it doesn't receive scroll events so it can't cancel the touch if the user scrolled.
Closes https://github.com/facebook/react-native/pull/10981
Differential Revision: D4226403
Pulled By: astreet
fbshipit-source-id: 41278d3ed4b684af142d9e273b11b974eb679879
Summary:
Virtual shadow nodes (e.g. text) don't use CSSNodes so we don't need to create them. This shows large savings in CSSNodes allocated, depending on the app.
This could be breaking if:
- You have virtual nodes that still set and get CSS properties. The setters now no-op for virtual nodes (I unfortunately couldn't remove them completely -- see the comment on LayoutShadowNode), but the getters will NPE. If you see these NPE's, you should almost definitely be using your own datastructure instead of a CSSNode as virtual nodes will not participate in the layout process (and the CSSNode is then behaving just as a POJO for you).
I do not anticipate this to be breaking for anyone, but am including breaking in the commit message since this is a change in API contract.
Reviewed By: emilsjolander
Differential Revision: D4220204
fbshipit-source-id: b8dc083fff420eb94180f669dd49389136111ecb
Summary:
When tapping on a link in a WebView with an unknown scheme, the app would crash. For example, if you have the link "something://example/" but your device doesn't have anything to handle the "something" scheme, the app would crash when the user clicks on the link. This change handles the exception to prevent the app from crashing. Instead, the click is a no-op and the WebView doesn't navigate anywhere.
**Test plan (required)**
Verified the app no longer crashes when clicking on unknown schemes in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10903
Differential Revision: D4226371
Pulled By: mkonicek
fbshipit-source-id: a6d3957806c6063e74fe055b0979cb9d1ce40e51
Summary:
The only callsite of `coalesce` looks like this:
```
newEvent.coalesce(oldEvent);
```
The default `coalesce` implementation returns the event with the most recent timestamp. When the events have the same timestamp then, using the variable names from above, `coalesce` returns `oldEvent`.
This change updates `coalesce`'s implementation to make it explicit that it returns `this` (`newEvent` in the variable names from above) in the case of a tie.
The motivation for this change is related to scroll events. In my team's app, we were seeing scroll events being emitted with the same timestamp and the coalescing logic was causing the oldest scroll event to be chosen. This was causing our JavaScript code to receive stale scroll information and the way the JavaScript code utilized this stale scroll information resulted in the ScrollView settling on the wrong scroll position.
**Test plan (required)**
Verified that scroll events work properly in a ScrollView in a test app. Also, my team's app uses this
Closes https://github.com/facebook/react-native/pull/11080
Differential Revision: D4226152
Pulled By: andreicoman11
fbshipit-source-id: d28a2569225ca95de662f2239a0fa14de0540a7d
Summary:
TextInput rounds padding down with `floor` when measuring. However, it rounds padding up with `ceil` when rendering.
This change makes things consistent by moving TextInput's rendering code to use `floor` as well. It looks like this is the intended behavior because commit bdff10b moved measuring from `ceil` to `floor`. It looks like TextInput's rendering code was just overlooked in that commit.
**Test plan (required)**
Verified TextInput padding works in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11003
Differential Revision: D4220855
Pulled By: mkonicek
fbshipit-source-id: 95349867ef89c021a8441b383a09052ca0dd569c
Summary:
Added an experimental feature to allow to use only rounded values. See #184. It's not a perfect solution and definitely can be further improved. I'm looking forward to your ideas.
Closes https://github.com/facebook/css-layout/pull/256
Reviewed By: splhack
Differential Revision: D4214168
Pulled By: emilsjolander
fbshipit-source-id: 6293352d479b7b4dad258eb3f9e0afaa11cf7236
Üstün Ergenoglu
Aaron Chiu
Alexey Lang
Theo Yaung
Felix Oghina
Martin Konicek
Fred Liu
Janic Duplessis
Oleg Lokhvitsky
Aaron Chiu
Prabakar Marimuthu
Adam Comella
Kevin Gozali
Jiajie Zhu
Konrad Reiche
Andy Street
Ludo Fardel
Scott Wolchok
Ke Mao
Marc Horowitz
Lukas Wöhrl
Emil Sjolander
Georgiy Kassabli
Charles Dick
Eric Vicenti
desmondyao
Swordsman-Inaction
Bhuwan Khattar
Michael Bolin
Eric Vicenti
Henrik Raitasola
Pieter De Baets
Ashok Menon
Andrew Y. Chen
Lukas Piatkowski
David Hart
Dan Abramov
Valentin Shergin
Antonio Corrado
awitherow
Andrei Coman
Satyajit Sahoo
Andrew Jack
Vojtech Novak
Mani Ghasemlou
huangqi03
Max Graey
Gerald Monaco
Philipp von Weitershausen
Rene Weber
Ahmed El-Helw
sunnylqm
Jakub Zika
Maël Nison
Vince Yuan
Michael Lee
Luke Miles
Konstantin Raev
Caleb Gomer
Sriram Ramasubramanian
Jonathan Lawlor
Dmitry Petukhov
Seth Kirby
Mengjue Wang
Dave Miller
Denis Koroskin
Alexander Blom
Martin Kralik
FBShipIt
Andrew
Steven Goff
Delyan Kratunov
John Shelley
Kirwan Lyster
Kevin Lacker
Don Yu
David Aurelio
Ben Clayton
Yann Pringault
Venryx
Ryan Gomba
Vishal Kakadiya
Connor McEwen
Benoit Lemaire
Pandiarajan Nagarajan
Michał Gregorczyk
