Summary: This diff fixes a typo in the JavaDoc for ReactScrollViewManager.
Reviewed By: cpojer
Differential Revision: D15965028
fbshipit-source-id: 3506cdde21c8d00ab916455a2d9fa29772f35359
Summary:
Original commit changeset: 4849a8e94141
# Problem:
This diff caused https://github.com/facebook/react-native/issues/25339.
It was converting non string values to strings whenever the conversion was available.
The original problem that this diff was trying to solve is described here -> https://twitter.com/estevao_lucas/status/1117572702083190785?s=215
# Solution introduced by this diff
This diff introduced a conversion. So for any value that was meant to be string but wasn't we would attempt to convert it. Which is not always wanted.
# Solution for problem in the twitter
I think we should improve the error message if incorrect type is being passed as a prop. However this isn't a problem if views are Flow typed.
Reviewed By: cpojer
Differential Revision: D15964298
fbshipit-source-id: 3d027a378561b87e7a9e89fc5e39dc6f359d8d22
Summary: This component is only used in native (there are no JS paths to it). Currently, the schema is being used to generate the native code for this component. Here, we add the codegen types so we still generate the native code when the schemas are removed, but the view config will never be used
Reviewed By: cpojer
Differential Revision: D15960990
fbshipit-source-id: 08fd0155f603e45785520c49a3ea86e30b276f9c
Summary: This was a mismatch with the schema
Reviewed By: cpojer
Differential Revision: D15960977
fbshipit-source-id: 08a56ac404eb5d45c6363e4574bd3d7bacf3ca08
Summary: Renames PullToRefresh to PullToRefreshView to correct a previous mistake so that this matches the Schema file
Reviewed By: cpojer
Differential Revision: D15960975
fbshipit-source-id: 575e526df2efdfa260f3cbbb4b0764998a91ade0
Summary: I think this was just an oversight when adding the flow types (notice that this flag isn't in the schema file, and the interface is required for android)
Reviewed By: TheSavior
Differential Revision: D15960965
fbshipit-source-id: 116b289261fbcaaaff53cd657a91f03dc036fb98
Summary: Fixes an issue with the native output of components without props and events (a trailing comma)
Reviewed By: cpojer
Differential Revision: D15960962
fbshipit-source-id: 315276ef01484546da43954e6fd879350e214006
Summary:
The goal of this PR is to improve the pipeline currently used for displaying GIFs / animated images on iOS. It is achieved by not holding all of the decoded frames in memory at the same time, as well as happily releasing existing memory whenever possible. This code is a simplified version of what you would find in SDWebImage (it is nearly 1:1, with unsupported or uneeded things removed). By adopting this API, it also allows classes conforming to RCTImageURLLoader or RCTImageDataDecoder to return any decodable UIImages conforming to RCTAnimatedImage and have improvements to memory consumption. Because RCTAnimatedImage is just a subset of the SDAnimatedImage protocol, it also means that you can use SDWebImage easier with Image directly.
A nice to have would be progressive image loading, but is beyond scope for this PR. It would, however, touch most of these same parts.
## Changelog
[iOS] [Fixed] - Substantially lower chances of crashes from abundant GIF use
Pull Request resolved: https://github.com/facebook/react-native/pull/24822
Test Plan: TBD. (but i am running a version of this in my own app currently)
Reviewed By: shergin
Differential Revision: D15853479
Pulled By: sammy-SC
fbshipit-source-id: 969e0d458da9fa49453aee1dcdf51783c2a45067
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
On Android, if the ActivityIndicator component is initially set to `animate={false}`, it does not display if later set to `true` (https://github.com/facebook/react-native/issues/9023)
For some reason, the layout width/height of the associated ProgressBar remains 0, despite the parent layout having the correct width/height:

I wasn't able to determine why this is the case, but I did notice that changing the visibility settings from `View.GONE` to `View.INVISIBLE` fixes the issue while not (as far as I can tell) having an impact on the React Native layout:
#### Before:

#### After:

Using `View.INVISIBLE` appears to alleviate the issue.
This should fix https://github.com/facebook/react-native/issues/9023
## Changelog
[Android][fixed] - ActivityIndicator appears as expected when `animated={false}` is later set to `true`.
Pull Request resolved: https://github.com/facebook/react-native/pull/25354
Test Plan:
Link this branch to a new React native project with the following App.js class:
```javascript
import React, { Component } from "react";
import {
StyleSheet,
Text,
Button,
View,
ActivityIndicator,
TouchableHighlight
} from "react-native";
export default class App extends Component {
constructor() {
super();
this.state = {
show: false
};
}
hide = () => {
this.setState({ show: false });
};
show = () => {
this.setState({ show: true });
};
render() {
return (
<View>
<ActivityIndicator
animating={this.state.show}
size="large"
style={styles.indicator}
/>
<ActivityIndicator
animating={this.state.show}
size="small"
style={styles.indicator}
/>
<View style={{ flexDirection: "row" }}>
<Button title="Hide" style={styles.button} onPress={this.hide} />
<Button title="Show" style={styles.button} onPress={this.show} />
</View>
<Text>Showing ? {this.state.show.toString()}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
indicator: {
borderColor: "red",
borderWidth: 1
},
button: {
marginRight: 8
}
});
```
Differential Revision: D15963366
Pulled By: cpojer
fbshipit-source-id: ee3df3fd84acbff342599dc6f4f4a391704876fa
Summary:
## Context
Moving SegmentedControlIOS to use a generated view config.
---
It's worth mentioning that even though `RCTSegmentedControlNativeComponent` defines a different event type to that of `RCTView`. We currently do not have 100% type safety for the event types in Paper. In other words, when an event for `onChange` in this case comes from the native side, it could potentially be shaped differently than what was typed in the native component file. This will be addressed in `Fabric`.
```
// RCTSegmentedControlNativeComponent.js
export type Event = $ReadOnly<{|
value: Int32,
selectedSegmentIndex: Int32,
|}>;
...
export type NativeProps = $ReadOnly<{|
...
onChange?: ?(event: BubblingEvent<Event>) => mixed,
|}>
```
This means that in the view config diff, there will be a value of `none` for `bubblingEventTypes`
Reviewed By: rickhanlonii
Differential Revision: D15851692
fbshipit-source-id: 6653fe7a77e46afdd55808aa5a4df813b34d7f70
Summary:
`StatusBarIOS` has been merged with `StatusBar`. See [Implement a StatusBar frame API](https://github.com/facebook/react-native/pull/16478)
## Changelog
[General] [Deprecate] - Warning for `StatusBarIOS`
Pull Request resolved: https://github.com/facebook/react-native/pull/25350
Test Plan: Warning prints when user imports `StatusBarIOS`
Differential Revision: D15963347
Pulled By: cpojer
fbshipit-source-id: 456a7f3ccb245bd89ad322d5a2649e3bf844ba24
Summary:
The previous version of a set of default values of `ShadowView`'s fields has a bug:
```
ComponentName componentName = "";
```
Initalizing `char const *` with a string literal in .h file makes the default constructor of the object produces different values across binary units (because a pointer to empty string can be defined differently). Now it's just a null pointer.
Reviewed By: sammy-SC
Differential Revision: D15911452
fbshipit-source-id: 16bcfb5f78ea802c0833135c486e3fbb8b7acaa6
Summary: I am about to change the definition of ShadowView a bit, so I think we need to ensure that we don't regress move semantic.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D15911453
fbshipit-source-id: ce2cd4cb2375ecb76295948a1e9b5d2e7fb80f38
Summary:
Bump Fresco to 2.0.0, which supports AndroidX. We should cherry-pick to 0.60 release, to support brown field apps but also native components.
## Changelog
[Android] [Changed] - Bump Fresco to 2.0.0, supports AndroidX
Pull Request resolved: https://github.com/facebook/react-native/pull/25358
Test Plan: CI is green, and RNTester builds and runs as expected.
Differential Revision: D15959443
Pulled By: mdvacca
fbshipit-source-id: 58ba2c3e4d1342014d6ea632cd865b4f413548d9
Summary: Returning a shared pointer by const reference in this context is not correct/safe because the object (the ShadowNode) doesn't own the object, so the caller cannot reason about the lifetime (esp. in a multithreaded environment).
Reviewed By: mdvacca
Differential Revision: D15958737
fbshipit-source-id: 8f03e6530d07d63ece5f955055c5c67c204b8223
Summary:
I found that on Android we only support 2 fontWeight options, either **normal** or **bold**, even developer can set any numeric value. But iOS supports all possible numeric values. This PR tries to add support for all possible numeric values on Android, even if it's supported only on Android P(28) and above.
This change might break texts where fontWeight use improperly, because this PR removes conversion of values above 500 to BOLD and below 500 to normal.
FYI, also moved **mCustomTypefaceCache** usage up because it was working after unnecessary mFontCache usage.
## Changelog
[Android] [Changed] - add custom font weight support to Text component on Android, only on P(API 28) and above versions.
Pull Request resolved: https://github.com/facebook/react-native/pull/25341
Test Plan: RNTester app's Text examples will show Rubik Regular, Rubik Light, Rubik Bold, Rubik Medium and Rubik Medium Italic texts in corresponding font family, style and weights.
Differential Revision: D15956350
Pulled By: mdvacca
fbshipit-source-id: 61079d953c65fb34ab4497d44c22317912a5a616
Summary:
When I installed React Native and loaded it up in the emulator, I wasn't really sure what the menu button was. I clicked around through the default emulator for advice but couldn't find it. So, instead this version now tells you directly what the key commands are.
Because it needs to show both<key>ctrl</key> and <key>cmd</key> (depending on dev's OS) I opted to include both and felt like it needed spaces around the `+`. So, I made that consistent everywhere.
## Test Plan
n/a
## Changelog
[Android] [Fixed] - Improves the initial copy for creating a new RN project on android
Pull Request resolved: https://github.com/facebook/react-native/pull/25353
Differential Revision: D15956358
Pulled By: mdvacca
fbshipit-source-id: aa320e30da53e6ba35f879f57740777bdee26618
Summary: Removing the UiThread annotation from MountingManager.addRootView() because it doesn't seem like it's needed.
Reviewed By: mdvacca
Differential Revision: D15945819
fbshipit-source-id: 0cb9bfb2fe2889001f1c061a07518cf9734f0c16
Summary:
Similar to D15909582, this change makes the Android TextInput take strings for the value of autoCapitalize and not just numbers. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style.
Changelog:
[Android] [Internal] - Supporting autoCapitalize as string to clean up internal TextInput.js file
Reviewed By: mdvacca
Differential Revision: D15911323
fbshipit-source-id: b236fdb314489cc1ef33f9214ff2d6b0e28b7310
Summary: This is strange why it's happening but it's not a reason to crash here. We will migrate the text component to State anyway, so we will fix the problem then.
Reviewed By: JoshuaGross
Differential Revision: D15951391
fbshipit-source-id: c1d1217fab1180f1eef84dfc2b2fd1ed0864b035
Summary:
Previously DrawerLayoutAndroid required taking an int as the drawerPosition. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android][Added] - DrawerLayoutAndroid now supports strings and not just numbers for drawerPosition.
Reviewed By: mdvacca
Differential Revision: D15912607
fbshipit-source-id: b444454a1e74f8f659995b9ebe5e164ac9660138
Summary: There are still race condition during bridge invalidation. Some modules may be accessing other modules during invalidation, but it's racing with the TM manager clearing the cache.
Reviewed By: JoshuaGross
Differential Revision: D15947488
fbshipit-source-id: 3bd51382264f538a03ca565b0f099da40c3daadf
Summary:
Backward compatibility for `invalidate` method, because for the old module system, we ensure call all methods of modules on `methodQueue`, we also need to keep this rule to avoid some race condition in module.
## Changelog
[iOS] [Fixed] - Backward compatibility of calling invalidate on module's method queue
Pull Request resolved: https://github.com/facebook/react-native/pull/25264
Test Plan: Ensure `invalidate` method of `module` be called on `methodQueue`.
Reviewed By: PeteTheHeat, JoshuaGross
Differential Revision: D15944532
Pulled By: fkgozali
fbshipit-source-id: e260792bc6b86a48cdf376282063cbabccbf26f0
Summary: We didn't update the header name. The ref was weak so it just didn't pull in the module.
Reviewed By: fkgozali
Differential Revision: D15944635
fbshipit-source-id: 8599c091a2265f807662c3deea4bd3c59e1a8aa8
Summary: This diff adds extra logging in FabricUIManager, this will be useful to debug production issues
Reviewed By: JoshuaGross
Differential Revision: D15907520
fbshipit-source-id: 94e16444af3c023b6c4837c4797404d3debe8e95
Summary: This is utility for TurboModule codegen for the purpose of typesafety. It is not used anywhere else at the moment.
Reviewed By: cpojer
Differential Revision: D15929957
fbshipit-source-id: ecf68cc98b78bc5b9c2078492b853a677b625eea
Summary: FBLazyVector is a simple utility to help typesafety/codegen of TurboModule specs. This is not used widely elsewhere at the moment.
Reviewed By: hramos, cpojer
Differential Revision: D15929956
fbshipit-source-id: 17226351738335a74e7b931812a1ca901f47963f
Summary: The current grey one is very bland, hard to read (no contrast) and often looks like a bug. I've changed it to match the iOS Personal Hotspot colors which look more idiomatic.
Reviewed By: cpojer
Differential Revision: D15941200
fbshipit-source-id: d60a3744c73675b40f42c329c2a44e6b8b0a93dc
Summary:
Logging nasty objects can cause RN to lockup as we try to format it nicely. The formatting code has some safegaurds against excessive recursion and some cycles, but it's not failsafe.
This adds a limit on the total number of times format can be called before we start to bail out. In my testing, this limit keeps the format time under ~100ms for huge objects, and logcat and other log readers start truncating it anyway so there is rarely any lost information.
I also considered using wall time, but this seemed a little cleaner. Open to suggestions.
Reviewed By: yungsters
Differential Revision: D15710157
fbshipit-source-id: b50261093270d6fb67b3473432d384ec51b98fd5
Summary:
D10527979 made the "update" message sequence part of initial connection signals. But the HMR client uses this sequence as a signal to show "Hot Reloading..." bar. As a result, we were showing it on every initial load when Hot Reloading is on. This is very confusing.
As a simple fix, I now send an explicit message to mark the end of the first load. I could infer that by first update message but figured this is more explicit and less likely to break. Until we receive `connection-done`, we now don't attempt to show the "Hot Reloading..." bar.
Reviewed By: rubennorte
Differential Revision: D15936085
fbshipit-source-id: b18b6aceea6c47d919b4265e58b21fc44f77b0b3
Summary:
This removes React Transform HMR in favor of the new React Refresh implementation. It should only affect the "Enable Hot Reloading" mode. In further diffs I will remove "React Transform HMR" completely.
This is technically a breaking change for Metro so it'll need a version bump.
Reviewed By: rickhanlonii, rubennorte
Differential Revision: D15903585
fbshipit-source-id: 074380b00868cb31857f599a03799d3584c35d87
Summary:
Since Ads Manager for Android is crashing when a user tries to log in, I'm reverting D15826082 for now. Will investigate the reason of the crash later.
Crashlog: P67222724
Reviewed By: cpojer
Differential Revision: D15939152
fbshipit-source-id: bc1276e6057418821e1ebd90203bea586943b633
Summary: Replaces the relative include to `YGEnums.h` in `yoga/event/event.h` with `#include <yoga/YGEnums.h>
Reviewed By: SidharthGuglani
Differential Revision: D15778634
fbshipit-source-id: 2bceeb58f26c0d9d0df6c0e7ea20b8ddf68a1ee5
Summary:
Prior to this patch the websocket protocol was not being set when a connection
was opened, which could cause client libraries and apps to not work properly.
According to the [whatwg] spec the protocol must be set once the connection is
estabilished.
[whatwg]: https://html.spec.whatwg.org/multipage/web-sockets.html#feedback-from-the-protocol
## Changelog
[Javascript] [Fixed] - Properly set the this.protocol on WebSocket open
[Android] [Fixed] - Send the server chosen protocol to the WebSocket object
[iOS] [Fixed] - Send the server chosen protocol to the WebSocket object
Pull Request resolved: https://github.com/facebook/react-native/pull/25273
Test Plan:
In order to reproduce the issue you **need to install wampy@6.2.1**. Since **wampy@6.2.2** and newer contains a workaround for this react-native bug.
https://www.npmjs.com/package/wampy
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow
*/
import React, { Component } from 'react';
import { Platform, StyleSheet, Text, View } from 'react-native';
import Wampy from "wampy";
const instructions = Platform.select({
ios: 'Press Cmd+R to reload,\n' + 'Cmd+D or shake for dev menu',
android:
'Double tap R on your keyboard to reload,\n' +
'Shake or press menu button for dev menu',
});
type Props = {};
export default class App extends Component<Props> {
state = {conState: 'Initializing...'};
componentDidMount() {
const url = "wss://demo.crossbar.io/ws";
const ws = new Wampy(url, {
realm: "crossbardemo",
ws: WebSocket,
debug: true,
onConnect: () => {
console.log("WAMP onConnect");
this.setState({conState: 'Connected'});
},
onClose: () => {
console.log("WAMP onClose");
this.setState({conState: 'Connection closed'});
},
onError: () => {
console.log("WAMP onError");
this.setState({conState: 'Connection Error'});
}
});
}
render() {
return (
<View style={styles.container}>
<Text style={styles.message}>{this.state.conState}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
message: {
fontSize: 20,
color: 'black'
},
});
```
Using the code above one must see the message **WAMP onConnect** on Console and **Connected** in the middle of the screen
Closes https://github.com/facebook/react-native/issues/24796
Differential Revision: D15938870
Pulled By: cpojer
fbshipit-source-id: 10a0a9b40c2a69e484ead37149abc2b1158a4ffc
Summary:
Since React Native ART has been extracted to community module, we can deprecate it in Core. You can find the community module [here](https://github.com/react-native-community/art).
## Changelog
[General] [Deprecate] - Deprecate React Native ART
Pull Request resolved: https://github.com/facebook/react-native/pull/25321
Test Plan:
Deprecation warning prints when user imports ART from react-native core module.
cc. cpojer
Differential Revision: D15938910
Pulled By: cpojer
fbshipit-source-id: d360fab6582c0d6c9064005246a012d2d5391c5c
Summary:
This is a follow up PR to https://github.com/facebook/react-native/issues/24359. There's a good thread in the mentioned PR for more background for why I'm doing this change. Essentially `focusable` makes more sense since it is about whether a view can receive user-initiated focus from a pointer or keyboard.
Pull Request resolved: https://github.com/facebook/react-native/pull/25274
Differential Revision: D15873739
Pulled By: cpojer
fbshipit-source-id: 0f526bb99ecdc68131dfc10200a5d44c2ef75b33
Summary:
Reland https://github.com/facebook/react-native/issues/15611 and added the gcc warning that was different from fb internal config. The original PR missed the static keyword for the `RCTNormalizeAnimatedEventName` function which triggered the gcc warning internally but not with the OSS xcode config.
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/25317
Test Plan: Added a Slider (it uses RCTBubblingEventBlock for its onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15938856
Pulled By: cpojer
fbshipit-source-id: 7e7a3459e2a2e8b1254a2f1ec8153a159ea73eed
Summary:
Add event key action for Android EventHandler events, helps to know if the key event is a up (key release, value is 1) or down (key pressed, value is 0) action.
## Changelog
[ANDROID] [ADDED] - Add event key action to EventHandler events.
Pull Request resolved: https://github.com/facebook/react-native/pull/25300
Test Plan: No test added
Differential Revision: D15897484
Pulled By: cpojer
fbshipit-source-id: fdb3d5413d9da3dd5f46d41e31ac60f0b341f3eb
Summary:
This pulls in the latest package updates for Fresh. It doesn't have any user-observable behavior.
The renderer is rebuilt on top of the last cherry-picked sync. I cherry-picked https://github.com/facebook/react/pull/15928 on top of it.
Reviewed By: rickhanlonii
Differential Revision: D15901887
fbshipit-source-id: ccd974f79e4c0a2a8a8cab0d472deeaedf1e3ddd
Summary: We will need to use ES6 exports when we switch this to use the codegen'd view configs. I also need to have a named export from this file.
Reviewed By: rickhanlonii
Differential Revision: D15923789
fbshipit-source-id: 513e27834583b6d021ff06d5d7f116ccdcd27722