Summary:
* It complicates Touch Handling mechanism.
* The same functionality can be (and should be) implemented via overriding standard `hitTest:` method.
* It was marked as deprecated a while ago.
Reviewed By: mmmulani
Differential Revision: D4667776
fbshipit-source-id: 2e047c3308563a2849ea351a242270f0800fead2
Summary:
Pair `reactWillMakeFirstResponder` and `reactDidMakeFirstResponder` was replaced with just `reactFocus` method
which is supposed to incapsulate all "focus" and "focus-later-if-needed" functionality.
Reviewed By: mmmulani
Differential Revision: D4664626
fbshipit-source-id: 8d3b7935ca26d32ba1d1826a585cce0396fcc885
Summary:
…th RCTSharedApplication()
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
Using React Native latest version with Cocoapods 1.2.0 causes the following error inside iOS app extensions
> /react-native/React/Modules/RCTAccessibilityManager.m:67:70: ‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
Moving the use of [UIApplication sharedApplication] to RCTSharedApplication() which is safe on app extension
- [ ] Provide a **test plan** demonstrating that the code is solid.
I am not sure how to test such that all the features which touch the modified code are tested.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
Using React Native latest v
Closes https://github.com/facebook/react-native/pull/13227
Differential Revision: D4816338
Pulled By: javache
fbshipit-source-id: e3e3c77882990ad1817b0b633521cff52571ecd0
Summary:
Various fixes of xcode projects and cleaning up some warnings
Closes https://github.com/facebook/react-native/pull/13109
Differential Revision: D4762652
Pulled By: lacker
fbshipit-source-id: b452976a58962439de4adecc8e703264af40cb38
Summary:
The Math Strikes Back
Several related things:
* When we specify `scale: 0;` style for some view it ends up with calling `CATransform3DScale` with zero scale parameter.
* In this case `CATransform3DScale` returns transform matrix full of zeros. It actually depends on representation and matrix-type (2d or 3d) but in UIView debugger it appears as [0, 0, 0, 0, ...]. And probably it is correct result.
* By default, for hit-testing, UIKit uses specially optimized logic based on GPU/CALayer infrastructure under the hood. And the transform matrix full of zeros breaks this algorithm. I guess, it happens because zero-matrix doesn't quite make sense.
So, `scale: 0;` is a weird edge case, and in this diff, we are trying to illuminate it by replacing with epsilon value.
Related SO issues:
http://stackoverflow.com/questions/25964224/cgaffinetransformscale-not-working-with-zero-scalehttp://stackoverflow.com/questions/7937369/animate-uiview-scale-to-zero
Reviewed By: blairvanderhoof
Differential Revision: D4734475
fbshipit-source-id: 7241cdffa86c05a6552860a25789e2281588ba23
Summary:
If user slide picker when picker item is zero, `UIPickerViewDelegate` will call `pickerView:didSelectRow:inComponent` row=0, `_items[row][@"value"]` will crash.
Closes https://github.com/facebook/react-native/pull/12187
Differential Revision: D4709882
Pulled By: mkonicek
fbshipit-source-id: 772c819d4eaef41ac983287877bda2918f40b1a7
Summary: Helps mitigate part of https://github.com/facebook/react-native/pull/12245 while we wait for a more comprehensive solution.
Reviewed By: emilsjolander
Differential Revision: D4571776
fbshipit-source-id: 185cd1b0d3af37724136a37471df412c2000dfe4
Summary:
Moving setting `availableSize` for `RCTRootShadowView` on earlier stage allows to prevent situations where `availableSize` is not specified yet, but Yoga layout is already happening.
Because `availableSize` equals {infinity, infinity} by default (in this case), Yoga returns a lot of nodes with infinit metrics, which confises UIKit.
Reviewed By: mmmulani
Differential Revision: D4672170
fbshipit-source-id: f9d8c84799dcbdb6b9230ddef6284d84df268833
Summary:
MapView has been deprecated in open source for a while: http://facebook.github.io/react-native/docs/mapview.html
We still want to use it internally. Moving it away from the GitHub folder.
Reviewed By: mmmulani
Differential Revision: D4646199
fbshipit-source-id: f469971e448dbca12afe141b43fa8a2518c7d467
Summary:
Remove the native iOS sticky headers implementation that has been replaced by the js Animated one. Also remove a line in JS that made sure we passed null to native so it did not use the native implementation.
**Test plan**
Made sure there were no more mentions of sticky / header in native ScrollView related code.
Tested that sticky headers still work :o
Closes https://github.com/facebook/react-native/pull/12696
Differential Revision: D4657391
Pulled By: ericvicenti
fbshipit-source-id: 16324a45ca4ce5cd143293c61394a0fa7ad0c4a1
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:
The actual badgeColor prop causes the following error when run on device with a version inferior to iOS 10 like iPad 2 and iPad mini 1.
`*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITabBarItem setBadgeColor:]: unrecognized selector sent to instance 0x7968be80'`
This PR fixes it by checking at runtime if the selector is available for the current running version.
It also makes the color available at start by using the variable `self.barItem`. Currently, the color appears only after a reload.
Closes https://github.com/facebook/react-native/pull/12354
Differential Revision: D4598036
Pulled By: shergin
fbshipit-source-id: 9f104fc27db51213a54273e33c5a22f1b350c55e
Summary:
In some cases, the accessibilityLabel contains a leading space. This is because `RCTRecursiveAccessibilityLabel` adds a space before every iteration of the loop including the first.
After this change, the contract is that:
- `RCTRecursiveAccessibilityLabel` always returns a string with a leading space.
- `accessibilityLabel` never returns a string with a leading space.
**Test plan**
I created a test app with the following code:
```
<View style={{height: 100, width: 100, backgroundColor: 'steelblue'}} accessible={true}>
<View style={{height: 20, width: 20, backgroundColor: 'red'}} accessibilityLabel='One' />
<View style={{height: 20, width: 20, backgroundColor: 'yellow'}} accessibilityLabel='Two' />
<View style={{height: 20, width: 20, backgroundColor: 'green'}} accessibilityLabel='Three' />
</View>
```
Before this change, the accessibilityLabel of the outermost View was " One Two Three" (notice the leading space).
After this change, it is "One Two Three" as desired.
Adam
Closes https://github.com/facebook/react-native/pull/12269
Reviewed By: javache
Differential Revision: D4596761
Pulled By: shergin
fbshipit-source-id: 7d5ff704e858d9f277d1547339a2831ffa90f592
Summary:
Now things look much more clear, I hope.
This diff:
* Introduces new property of `RCTRootShadowView` `availableSize` which represents exactly what we transmit to layout engine;
* Illuminates conflict between logical `availableSize` and explicitly specified size of DOM node (current `size`);
* Splits overcomplicated `setSize:forView:` method into two unrelated ones;
* Changes actual values of `RCTRootViewSizeFlexibility` enum constants for simpler usage;
* Completely removes `sizeFlexibility` concept from `RCTRootShadowView` (in favor of special values of `availableSize`);
* Makes the code clearer finally.
This is beginning of big effort to improve `RCTRootView` and co.
Reviewed By: mmmulani
Differential Revision: D4562834
fbshipit-source-id: f5baaf2859ea430d44645a6b5d35f222f15a668e
Summary: With the Cxx bridge, properties are not guaranteed to be set it any order (and furthermore, they should not be). RCTRefreshControl previously had its title set first, and would crash otherwise. This fixes that.
Reviewed By: mhorowitz
Differential Revision: D4580253
fbshipit-source-id: 39baecceb8b67c6a851c08ba9cabbf4dc99359cb
Summary: This method was defined in the .m file already, so we can just expose it to the header for other usages.
Reviewed By: mmmulani, shergin
Differential Revision: D4557942
fbshipit-source-id: a1be8af8e31b88a152cabfab6d4cf82316088572
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: 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: Now layout direction (LTR or LTR) can be specified not only for whole app but also for view subtree via `direction` style property.
Reviewed By: mmmulani
Differential Revision: D4510206
fbshipit-source-id: 4e56c5886b6e42f2343165eb76be897e681c5ba4
Summary:
Motivation:
* `RCTShadowView`'s `frame` property actually represents computed layout of the view. We must not use it as a setter for yoga node styles;
* Using `frame` and `setLeftTop` in existing way actually works only for view with absolute positioning, so it is super rare and special case;
* Internally, setting `frame` only make sense to `RootView`, and in that case there we always must not change `origin` we are introducing `setSize` method.
Changes:
* `[-RCTShadowView setFrame:]` was removed, `frame` property is readonly now;
* `[-RCTShadowView setLeftTop:]` was removed; no replacement provided;
* `[-RCTShadowView size]` read-write property was added;
* `[-RCTUIManager setFrame:forView:]` was deprecated, use (just introduced) `setSize:forView:` instead;
* `[-RCTUIManager setSize:forView:]` was added.
If you are still need some of removed methods, you are probably doing something wrong. Consider using `setIntrinsicContentSize`-family methods,
`setSize`-family methods, or (in the worst case) accessing `yogaNode` directly.
Reviewed By: javache
Differential Revision: D4491384
fbshipit-source-id: 56dd84567324c5a86e4c870a41c38322dc1224d2
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:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
This change is required when you try to set a focus on a view that doesn't exist and thus cannot be focused. In my specific use case, this occurred when trying to set a focus on a list item in a setInterval when the View (with the specific list item) had been popped. The while loop ran infinitely (eventually freezing the app) since the rootView doesn't exist. This adds that check and breaks out if so.
All obj-c tests ran successfully.
dlowder-salesforce
Closes https://github.com/facebook/react-native/pull/12073
Differential Revision: D4468989
Pulled By: ericvicenti
fbshipit-source-id: 7926c887035722c983c41cb6b6d9df567010c2ee
Summary:
Motivation: reduce build noise that might worry new users or hide real problems.
This deals with four of the warnings currently in the iOS build. The `__unused` additions are standard and self-explanatory, following the style used elsewhere in RN. I've used `#pragma unused` to deal with parameters named by macros.
Tested by building and running the `UIExplorer` example app in XCode 8.2
Closes https://github.com/facebook/react-native/pull/11797
Differential Revision: D4396611
fbshipit-source-id: 728e9ebb94d147f7a2cbc674a25fe67e66e2e8b2
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