Summary:
iOS13 status bar has now 3 styles
UIStatusBarStyleDefault, UIStatusBarStyleLightContent, UIStatusBarStyleDarkContent
UIStatusBarStyleDefault now acts as an automatic style which will set it’s value dynamically based on the the userinterfacestyle(One of the traits) of the viewcontroller that controls the status bar appearance.
## Changelog
[iOS] [Fixed] - iOS13 new status bar style UIStatusBarStyleDarkContent
Pull Request resolved: https://github.com/facebook/react-native/pull/26294
Differential Revision: D17314054
Pulled By: cpojer
fbshipit-source-id: ea109e729bb551dff314bc00a056860a8febb0e9
Summary:
For now, disable TM completely in test environment, like RNTester integration/unit tests. See details in T53341772
This also fixes the failure discussed in https://github.com/facebook/react-native/pull/26151
Reviewed By: PeteTheHeat
Differential Revision: D17147915
fbshipit-source-id: 1c48ebb9c3b81fc08bc33606dcc38c29297d6010
Summary:
@public
CADisplayLink strongly holds onto its target, so you have to use a weak proxy object to pass the target into the CADisplayLink.
Previously we passed a weak-self point (i.e. weakSelf) but this did not have the intended effect, since the pointer to self would still be passed to CADisplayLink, and thus it would hold onto the RCTUIImageViewAnimated strongly.
So is weakSelf doing anything other than using self?
It is but it's very minor and not useful. In the case that the object got de-allocated between assigning self to weakSelf and creating the CADisplayLink, then we would pass a nil target. This is actually impossible though because we are running an instance method, so self is implicitly retained! So semantically it is something different but in practice it is the same as passing self through.
Notes:
* This system was added originally in https://github.com/facebook/react-native/pull/24822
* https://github.com/facebook/react-native/pull/25636 then "enabled" this system by deprecating existing approach
Reviewed By: fkgozali
Differential Revision: D16939869
fbshipit-source-id: 7a0e947896f23aa30ad074d1dcb4d4db7543e00a
Summary:
`NativeExceptionsManager.js` contains the JS spec for this native module. This diff moves the objc code to CoreModules (since it's the only directory that supports TM at the moment) and makes it conform to the spec.
NOTE: I will update podfiles after this diff is reviewed, before I land. Adding those generated changes makes it really hard to review.
Reviewed By: RSNara
Differential Revision: D16812212
fbshipit-source-id: 38b6e9a20ce15e7e9995df34493b37ed7adb2911
Summary: Instead of getting `RuntimeExecutor` from the bridge, pass it from above. Right now pass through `null`, but eventually this will work :)
Reviewed By: RSNara
Differential Revision: D16626288
fbshipit-source-id: bce527f85c0a79cfe6cf240a3633bbbe357f75c4
Summary: Instead of grabbing `imageManager` from the bridge, pass it from above. Right now, still use bridge to pass from above, but this gives us flexibility to not use bridge in the future.
Reviewed By: shergin
Differential Revision: D16504270
fbshipit-source-id: 7977a7957b659375f8348d26cd57b648e9d5959f
Summary:
This diff adds a JS spec for RCTImageLoader, and conforms to it in ObjC++. Since RCTImageLoader isn't called from JS, the js spec is empty. Since `/CoreModules/` is the only dir in OSS which supports TM, move the ObjC++ impl there.
The change in `NativeExceptionsManager.js` fixes a weird bug I was hitting in codegen, where the codegen cpp file wouldn't compile due to unused variable.
Reviewed By: JoshuaGross
Differential Revision: D16495674
fbshipit-source-id: 191897b87730a6b0b96022eedc6412551fae04a6
Summary:
This diff moves RCTImageLoader, RCTImageEditingManager, and RCTImageStoreManager to CoreModules. This is necessary for us to convert all these NativeModules to TurboModules.
**Note:** As a part of this diff, I had to break apart `RCTImageLoader.h`. All the protocols that were in `RCTImageLoader` are now in their own headers. Furthermore, `RCTImageLoader`'s methods are defined in `RCTImageLoaderProtocol`, so that we can call them from classes like `RCTImageViewManager` in `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D16805827
fbshipit-source-id: 89f6728b0766c30b74e25f7af1be8e6b8a7e6397
Summary: Currently this is the default, but I plan to toggle the default to False shortly. False is better for build speed, as it forces you to separate deps and exported_deps.
Reviewed By: williamtwilson
Differential Revision: D16785991
fbshipit-source-id: 8cb73b87f1dfa50f21c0c12df1579054cdc99e6e
Summary:
# What's the problem?
`RCTSurfacePresenter._scheduler` is deallocated in `RCTSurfacePresenter.handleBridgeWillReloadNotification`.
It shouldn't be used before `RCTSurfacePresenter.handleJavaScriptDidLoadNotification` is called because that's when new `RCTSurfacePresenter._batchedBridge` is created, scheduler depends on this new `RCTSurfacePresenter._batchedBridge`.
But it is, it means that it is created with the old bridge, this means that it gets deallocated right away.
First access point of old bridge is in `RCTSurfacePresenter.setMinimumSize`.
# What's the fix?
Make sure surface has correct stage before calling layout methods.
The other idea was to return early in `RCTSurfacePresenter.setMinimumSize` in case bridge isn't setup.
# Problems?
1. Following error still appears after reload
{F176556210}
2. There is a white space for a while. By white space a mean the screen stays white for a short period of time before displaying content.
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D16762443
fbshipit-source-id: 5a2a880b0f5345f268291c86811264f42f6058b3
Summary:
If you have following scenario
1. Have <Image> component with valid URL
2. Due to user action set <Image> to incorrect URL (something that 404s)
Currently 1st image stay visible to the user.
This is the case for both Fabric and Paper.
Paper is being fixed -> https://github.com/facebook/react-native/pull/25919
Reviewed By: fkgozali
Differential Revision: D16708532
fbshipit-source-id: ffdea5421faead4730e7b117a3b9f6e21869da70
Summary: The previous rename from RCT->RN prefix ended up causing some confusions on which prefix to use for which files and under what circumstances. To avoid further confusion before we're done with the re-architecture project, let's keep them as RCT.
Reviewed By: mdvacca
Differential Revision: D16705566
fbshipit-source-id: 395bff771c84e5ded6b2261a84c7549df1e6c5e5
Summary:
Updated the message from
> Loading from pre-bundled file
to
> Connect to Metro to develop JavaScript
I also added a new RCT_PACKAGER_NAME so other packagers can override "Metro"
Reviewed By: yungsters, cpojer
Differential Revision: D16427501
fbshipit-source-id: 1b7f9e261f7521ba930c6248087fe6f3c3659cb7
Summary: For some reason the conversion from a BOOL object to `bool` (C++ style) may lead to incorrect boolean value. This fixes the value provided to the builder to be of `bool` type instead.
Reviewed By: JoshuaGross
Differential Revision: D16657766
fbshipit-source-id: b66922aceadd20d16226a07f73b24ee0a3b825dc
Summary: It's actually the first module in OSS which is typed with taking advantages of codegen.
Reviewed By: RSNara
Differential Revision: D16620334
fbshipit-source-id: 65d6656506f2a4c68d493939ecfa65ba975abead
Summary: This diff implements the JSResponderHandler methods in the core of RN (scheduler API and friends)
Reviewed By: ejanzer
Differential Revision: D16543437
fbshipit-source-id: dac03e30c4330d182ecf134f3174ba942dbf7289
Summary: Fabric ObjC(++) files will be prefixed by RN* for the time being, this codemod is a simple rename. This includes `interface` and `protocol` definition
Reviewed By: PeteTheHeat, yungsters
Differential Revision: D16611524
fbshipit-source-id: 868d2571ea2414dde4cbb3b75b1334b779b5d832
Summary:
Duplicate category method implementations cause undefined behavior in Objective-C; one is chosen essentially at random. The linker also issues a noisy warning about this (which is how I noticed this case).
It didn't matter in this particular case since both implementations do the same thing, but we should clean this up so people don't get desensitized to these linker warnings. There is no need to have two implementations.
Reviewed By: fkgozali
Differential Revision: D16587219
fbshipit-source-id: 56dc3493735443c476484092f4a7eacfcddee8cb
Summary:
The activityIndicatorViewStyle property overrides the previous set color
if it's changed. Depending on the property set order you may end in a state
that the color property will never be respected since it first sets
the color and then the activityIndicatorViewStyle property (which overrides
the color property). In order to prevent this problem
before setting the new activityIndicatorViewStyle save the old
color and override it after activityIndicatorViewStyle is set. Thus
always respecting the user's color.
## Changelog
[iOS] [Fixed] - Do not override ActivityIndicator color when setting its size
Pull Request resolved: https://github.com/facebook/react-native/pull/25849
Test Plan:
Using the code below on iOS notice that the last ActivityIndicator will always have its color set to white while te testID is provided
### Without the patch
Notice the white -> blue transition when disabling the testID
### With the patch
Color remains unchanged
```javascript
import React from "react";
import { View, StyleSheet, ActivityIndicator, Button } from "react-native";
const App = () => {
const [enableTestID, onSetEnableTestID] = React.useState(true);
const onPress = React.useCallback(() => {
onSetEnableTestID(!enableTestID);
}, [enableTestID]);
return (
<View style={styles.container}>
<ActivityIndicator size="large" color="red" />
<ActivityIndicator size="small" color="red" />
<ActivityIndicator size="small" />
<ActivityIndicator color="green" />
<ActivityIndicator
key={enableTestID.toString()}
size="large"
color="blue"
testID={enableTestID ? 'please work' : undefined}
/>
<Button
title={enableTestID ? 'Disable testID' : 'enable testID'}
onPress={onPress}
/>
</View>
);
};
export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: "center",
justifyContent: "center",
backgroundColor: "black"
},
});
```
Closes https://github.com/facebook/react-native/issues/25319
Reviewed By: cpojer
Differential Revision: D16559929
Pulled By: sammy-SC
fbshipit-source-id: ac6fd572b9f91ee5a2cbe46f8c46c1f46a1ba8b3
Summary:
# Disclaimer:
I might be missing something as the solution I implemented here seems like something that was considered by original author. If this solution isn't good, I have a plan B.
# Problem:
`onDismiss` prop isn't being called once the modal is dismissed, this diff fixes it.
Also I've noticed that `onDismiss` is meant to only work on iOS, why is that? By landing this diff, it'll be called on Android as well so we need to change the docs (https://facebook.github.io/react-native/docs/modal.html#ondismiss).
## Video that shows the problem
Following code is in playground.js P70222409 which just increments number everytime onDismiss is called
{F166303269}
Reviewed By: shergin
Differential Revision: D16109536
fbshipit-source-id: 3fba56f5671912387b217f03b613dffd89614c9d
Summary: I think it's possible that there's a race condition between creating the scheduler and setting the delegate leading to bugs like T47272192.
Reviewed By: mdvacca
Differential Revision: D16537737
fbshipit-source-id: 9c579537658be5a9aeed37c0e4935c997cabb6aa
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
UIManager.measureLayoutRelativeToParent will not be supported as part of fabric.
This diff deprecates this method in the current version or React Native.
Reviewed By: fkgozali
Differential Revision: D16471845
fbshipit-source-id: acfda9bfb2dd8553ff8e359ea2c8d7d88a14c6d2
grabbou
Radek CzemerysandMike Grabowski
gaodengandgrabbou
James Treanorandgrabbou
Kevin Gozaliandgrabbou
Mehdi Mulaniandgrabbou
Peter ArganyandFacebook Github Bot
Ramanpreet NaraandFacebook Github Bot
Adam ErnstandFacebook Github Bot
Samuel SuslaandFacebook Github Bot
Rick HanlonandFacebook Github Bot
Michał OsadnikandFacebook Github Bot
David VaccaandFacebook Github Bot
Guilherme IscaroandFacebook Github Bot
Joshua GrossandFacebook Github Bot
zhongwuzwandFacebook Github Bot
Valentin SherginandFacebook Github Bot
