Summary: Changelog: [Internal] - Update XHR upload example to new post test server. Created new toilet here: http://ptsv2.com/t/react-native and configured to return the link to the post data
Reviewed By: kacieb
Differential Revision: D29082824
fbshipit-source-id: 0cb502286addf1de3d5053f73173551ddd180a96
Summary:
Before the DevMenu would just open up as a DialogBox. After this change, the DialogBox will have a title. This should help distinguish between the Bridgeless DevMenu and the Bridge DevMenu.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29071185
fbshipit-source-id: 72533f10b73b36cd890fe152c6de901c867159f2
Summary:
With bridgeless mode enabled, there can be two instances of DevSupportManager. Previously, both of them wrote to the same files on disk. After this change, each instance will write the bundle to different files on disk.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29068794
fbshipit-source-id: 67270be17d084cc89ab618ea54f729f9b595b5f7
Summary:
Google Chrome debugging is only supported by the bridge. So, it makes sense to move it to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29031514
fbshipit-source-id: 4d6b6bb3bc298be5fe4d9f96c0d019676fe256db
Summary:
This diff prevents a NullPointerException caused by a race condition in the tear down of React Native.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29135942
fbshipit-source-id: 76d5a1f16c2ca63a146b56c761f5f9595dcfe2a5
Summary:
The mount items executed before the view attach can fail with the RetryableMountingLayerException, which we should either retry or skip the item. This change updates logic for such items to catch these exceptions.
Instead of passing `MountingManager` to execute the items, this change now passes a reference to the `MountItemDispatcher` (abstracted through interface to resolve cycle between the manager and dispatcher). The dispatcher executes the queue directly and schedules retry together with the next batch.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29068063
fbshipit-source-id: 04030b21db188d5617c3448322d25ba77d5fbb9f
Summary:
Fixes https://github.com/facebook/react-native/issues/27099
When you upload a local file using XHR + the `FormData` API, RN uses `RCTNetworkTask` to retrieve the image file data from the local filesystem (request URL is a file:// URL) ([code pointer](https://github.com/facebook/react-native/blob/master/Libraries/Network/RCTNetworking.mm#L398)). As a result, if you are uploading a local image file that is in the app's directory `RCTNetworkTask` will end up using `RCTLocalAssetImageLoader` to load the image, which reads the image into a `UIImage` and then re-encodes it using `UIImageJPEGRepresentation` with a compression quality of 1.0, which is the higest ([code pointer](https://github.com/facebook/react-native/blob/4c5182c1cc8bafb15490adf602c87cb5bf289ffd/Libraries/Image/RCTImageLoader.mm#L1114)). Not only is this unnecessary, it ends up inflating the size of the jpg if it had been previously compressed to a lower quality.
With this PR, this issue is fixed by forcing the `RCTFileRequestHandler` to be used when retrieving local files for upload, regardless of whether they are images or not. As a result, any file to be uploaded gets read into `NSData` which is the format needed when appending to the multipart body.
I considered fixing this by modifying the behavior of how the handlers were chosen, but this felt like a safer fix since it will be scoped to just uploads and wont affect image fetching.
## Changelog
[iOS] [Fixed] - Avoid re-encoding images when uploading local files
Pull Request resolved: https://github.com/facebook/react-native/pull/31457
Test Plan:
The repro for this is a bit troublesome, especially because this issue doesn't repro in RNTester. There is [some code](https://github.com/facebook/react-native/blob/master/packages/rn-tester/RNTester/AppDelegate.mm#L220) that is to be overriding the handlers that will be used, excluding the `RCTImageLoader`. I had to repro this in a fresh new RN app.
1. Create a blank RN app
2. Put an image in the folder of the app's install location. This would be similar to where files might be placed after an app downloads or captures an image.
3. Set up a quick express server that accepts multipart form uploads and stores the files
4. Trigger an upload via react native
```
const data = new FormData();
data.append('image', {
uri:
'/Users/arthur.lee/Library/Developer/CoreSimulator/Devices/46CDD981 (https://github.com/facebook/react-native/commit/d0c8cb12f21604fd9730e275a52816d7fd00a826)-9164-4925-9025-1A76C0D9 (https://github.com/facebook/react-native/commit/1946aee3d9696384d38890269ea705cafd472827)F0F5/data/Containers/Bundle/Application/B1E8A764-6221-4EA9-BE9A-2CB1699FD218 (https://github.com/facebook/react-native/commit/1c92b1cff623ea3f3b78238b146ab001626ef305)/test.app/test.bundle/compressed.jpg',
type: 'image/jpeg',
name: 'image.jpeg',
});
fetch(`http://localhost:3000/upload`, {
method: 'POST',
headers: {'Content-Type': 'multipart/form-data'},
body: data,
}).then(console.log);
```
5. Trigger the upload with and without this patch
Original file:
```
$ ls -lh
total 448
-rw-r--r-- 1 arthur.lee staff 223K Apr 29 17:08 compressed.jpg
```
Uploaded file (with and without patch):
```
$ ls -lh
total 1624
-rw-r--r--@ 1 arthur.lee staff 584K Apr 29 17:11 image-nopatch.jpeg
-rw-r--r--@ 1 arthur.lee staff 223K Apr 29 17:20 image-withpatch.jpeg
```
Would appreciate pointers on whether this needs to be tested more extensively
Reviewed By: yungsters
Differential Revision: D28630805
Pulled By: PeteTheHeat
fbshipit-source-id: 606a6091fa3e817966548c5eb84b19cb8b9abb1c
Summary: Changelog: [Internal] - Remove picker from Modal example in RNTester in prep for deprecating Picker from RN
Reviewed By: kacieb
Differential Revision: D29082452
fbshipit-source-id: 01ee5ae2d0978721f7229d824f23cfbccfaf2813
Summary: Changelog: [Internal] - Remove Picker from accessibility example as a first step to deprecate Picker from react-native
Reviewed By: kacieb
Differential Revision: D29082453
fbshipit-source-id: d1d6eb0514453126351b41c2ca5d72d2c81f5dc9
Summary:
This feature is still causing some number of crashes, though prod impact is not yet determined. For safety I'm adding a feature flag so we can disable this if necessary.
Changelog: [internal]
Reviewed By: kacieb
Differential Revision: D29117957
fbshipit-source-id: 3b19bac9dd00735f51f5c9cba606378b2a62975e
Summary:
In the refactor in D28933824 (https://github.com/facebook/react-native/commit/6b601db8b83337415113a123d780fb64aa67af42), an early return was accidentally deleted. This causes incorrect measurements to be returned, which can break a few things including Text Inline Views.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29122235
fbshipit-source-id: 76c8991132e22cd4e0fc1c277447c4dba751adfb
Summary:
Changelog: [internal]
RuntimeScheduler can be accessed before any Fabric surface is rendered. Therefore, it needs to be created and installed in the runtime at the start up of the runtime.
Reviewed By: JoshuaGross
Differential Revision: D29091848
fbshipit-source-id: ff75ef8c4882550795e5d4a258355b651cb0e637
Summary:
If function name is an empty string then it would fail to parse the line. And not only that, it would cause the entire stack to be lost. This fixes the issue by replacing `.+?` with `.*?`.
For example this line fails to parse:
```
at global (:2:4)
```
Changelog:
[General][Fixed] - Fixed bug parsing hermes call stacks when the file name is empty
Reviewed By: yungsters
Differential Revision: D29063192
fbshipit-source-id: 604e457af51f852fe547e6424283631ae148897d
Summary:
Changelog: [internal]
Using keyboard's autocomplete did not insert space at the end of the word.
Reviewed By: fkgozali
Differential Revision: D29085654
fbshipit-source-id: 35fee726ea7d2030fdfa64300e045a303ea98ce9
Summary:
Changelog: [internal]
To prevent wrong TextInput becoming first responder, force a resign when preparing for a reuse.
Reviewed By: JoshuaGross
Differential Revision: D29085923
fbshipit-source-id: 246cdf0628f914c3928cc9c7499d029b77684f2c
Summary:
Rewrites `ReactNativeStyleAttributes` so that it is statically defined.
This means it will no longer require a handful of modules that defines `prop-types` only to use their keys.
Functionally, this should be equivalent to what was there before.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019308
fbshipit-source-id: 47f85a8c7703a133c68c20c7f3e14e1026ce4ff2
Summary:
Simplifies the Flow type for `ReactNativeStyleAttributes`, an internal module.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019311
fbshipit-source-id: cf95dac4b8c2261812cc1d753255dfb905540759
Summary:
Deletes `StyleSheetValidation` because it is `prop-types` in disguise.
Changelog:
[General][Removed] - `StyleSheet.create` will no longer do DEV-time validation.
Reviewed By: TheSavior
Differential Revision: D29019310
fbshipit-source-id: bfe886d8dc09a1aa8dac4a73bfd62f481e3eb9e9
Summary:
Removes the unnecessary dependency from `DeprecatedTextInputPropTypes` on `Text`. Just use `DeprecatedTextPropTypes` directly.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017596
fbshipit-source-id: b816c2261bf473e02473d84984cfb3d5a63ec8c1
Summary:
Moves `ImagePropTypes` out of `Image.android.js` in preparation for some cleanup.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017076
fbshipit-source-id: e7d3d6533f69dc2c54e7c25e215648d7c7ff1840
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Adding runtime type information adds greatly to the binary size, so react-native-windows builds without it. But some parts of the fabric code currently uses dynamic_cast, which means to use fabric we have to build with RTTI turned on. This PR removes the usages of dynamic_cast that are hit in release builds, which should allow react-native-windows to turn off RTTI in release builds.
Required for: https://github.com/microsoft/react-native-windows/issues/7981
One thing to note, the comment in ShadowNodeTraits indicates that core was reserving the first 16 bits. I'm adding two more. Is that ok? Should core be reserving more for future use?
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Remove uses of dynamic_cast in release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31694
Test Plan:
Verified that I can build react-native-windows with Fabric in release, without RTTI.
Boot / clicked around in RNW RNTester
Reviewed By: sammy-SC
Differential Revision: D29040383
Pulled By: JoshuaGross
fbshipit-source-id: e49286e59c4ba54faf0b4de5e244dfa1f7c3f193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement.
## Changelog
[Android] [Changed] - Bump Fresco to 2.5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31699
Test Plan: CI is green
Reviewed By: TheSavior
Differential Revision: D29031847
Pulled By: passy
fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344
Summary:
In the CONTRIBUTING.md file, when a user clicks on the hyperlink for either issues(line 33) or pull requests(line 34), they are directed to a filler page which has them click on an additional hyperlink to take them to the page they are looking for. The only thing present on the filler page is a hyperlink. So, in terms of usability, it does not make sense to have users go through an extra click to get to the page they want. I have changed the hyperlinks of Issues(line 33) and Pull Requests(line 34) to takes users directly to Triaging GitHub Issues and Managing-Pull-Requests
## Changelog
[GENERAL][CHANGED]-See lines 33 and 34 of https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md
Pull Request resolved: https://github.com/facebook/react-native/pull/31696
Test Plan: First, I ensured that the code lints and the test suite passes. For testing the links, I opened my fork in GitHub and opened the CONTRIBUTING.md file. I clicked on both hyperlinks to ensure that they both worked properly. No tests were added for this code.
Reviewed By: lunaleaps
Differential Revision: D29046728
Pulled By: TheSavior
fbshipit-source-id: 99ec989938660102aefa07862542dc9a007359ce
Summary:
As title
Changelog:
[General][Changed] Update Image.[android|ios].js to use import from instead of require
Reviewed By: TheSavior, yungsters
Differential Revision: D29003824
fbshipit-source-id: 0f98c730b1bd9cb581d2fcf6f4c0e911bb8c24b5
Summary:
added .hprof file is generated when building a release apk and it's size is > 300 MB, and we don't want it to be in the repo
## Changelog
[General] [Changed] - Remove .hprof
Pull Request resolved: https://github.com/facebook/react-native/pull/31679
Reviewed By: yungsters
Differential Revision: D28967470
Pulled By: PeteTheHeat
fbshipit-source-id: 521f653428ebdd2a33fb251ce18c4faada53bf27
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
https://github.com/facebook/react-native/issues/31345
The issue to` android/app/src/main/res/values/styles.xml.`
In the base application theme, there is an explicitly added item
`<item name="android:textColor">#000000</item>`
This leads the `textColor` of the app to be black even though the theme is actually DayNight.
A permanent fix would be to not have this item added by default when creating a new project, as it is buggy behavior
## Changelog
[General] [removed] - line `<item name="android:textColor">#000000</item>` in this file `android/app/src/main/res/values/styles.xml `for the inital setup
Pull Request resolved: https://github.com/facebook/react-native/pull/31487
Test Plan: Removing this has fixed the issue for me.
Reviewed By: yungsters
Differential Revision: D28966678
Pulled By: ShikaSD
fbshipit-source-id: 57c6b4b7b5f11847ea6e611c7567c0c03133c79d
Summary:
This PR sets project wide Kotlin version to 1.4.21, supported in Buck https://github.com/facebook/buck/tree/dev/third-party/java/kotlin.
We had to specify version for both kotlin-dsl and kotlin('jvm') plugins to remove version mismatch warnings in **react-native-gradle-plugin**. Also I expect more Kotlin code in RN, so instead of specifying version for each sub-project it's better to have project wide setting.
We don't need to load Kotlin in react-native-gradle-plugin because Kotlin is available RN project wide.
## Changelog
[Internal] [Changed] - Project wide Kotlin version set to 1.4.21
Pull Request resolved: https://github.com/facebook/react-native/pull/31645
Test Plan: Everything works as expected, no visible change for developers.
Reviewed By: yungsters
Differential Revision: D28991440
Pulled By: ShikaSD
fbshipit-source-id: 971fa6f50c12d916a56d0dcde7c65299496fb68a
Luna Wei
Ramanpreet Nara
David Vacca
Andrei Shikov
Arthur Lee
Joshua Gross
Samuel Susla
CodemodService FBSourceClangFormatLinterBot
Martin Sherburn
Tim Yung
Daniel Sainati
Andrew Coates
Michel Weststrate
Dulmandakh
Rui Ying
Justin
Kacie Bawiec
Hamza Jadid
Joel Arvidsson
Siddharth Verma