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:
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:
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:
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:
Changelog:
[Internal] - Replace `useImperativeHandle` usage with new `useMergeRef` which will keep both the forwarded and internal ref handle up to date (in case the instance ever changes). That being said, this change was not motivated in fear of a stale ref but more an intention to show that `useImperativeHandle`'s use case is more about creating a selective API and `useMergeRef` is better suited for publishing ref updates.
Reviewed By: yungsters
Differential Revision: D28950632
fbshipit-source-id: 594afda02693545aab77f24566180c338b58bb8b
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## 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
-->
[iOS] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
This PR aims to enable support for foreground ripple in Pressable. This makes it possible to show ripple on top of custom child components like Image as shown in the below example.
## 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
-->
[Android] [Added] - Support for foreground ripple in Pressable
Pull Request resolved: https://github.com/facebook/react-native/pull/31632
Test Plan:
- Pass property useForeground: true in android_ripple config to verify the changes.
https://user-images.githubusercontent.com/23293248/120111371-4cecbf00-c18f-11eb-8acb-d10718d5483c.mov
Reviewed By: kacieb
Differential Revision: D28926493
Pulled By: yungsters
fbshipit-source-id: 12a6ba71a7dc6ed60fbaeb651f015cace38e03b1
Summary:
Creates a `useAnimatedProps` hook that is compatible with concurrent mode, and uses this in `createAnimatedComponent_EXPERIMENTAL`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28390393
fbshipit-source-id: d8aa471507a5d096832b93caf63a24f71733deda
Summary:
Creates `useRefEffect` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862440
fbshipit-source-id: 50e0099c1a3e0a0f506bf82e68984fc5a032f101
Summary:
Creates `useMergeRefs` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862439
fbshipit-source-id: 60eac7bcd6cceb06ee82181386b4712d642f5404
Summary:
Remove `defaultProps` from `Picker` of components, replace it with destructuring assignment.
## 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
-->
[JavaScript] [Changed] - Remove defaultProps from picker
close https://github.com/facebook/react-native/issues/31603
Pull Request resolved: https://github.com/facebook/react-native/pull/31644
Test Plan: all test suite and CI passes.
Reviewed By: TheSavior
Differential Revision: D28886320
Pulled By: lunaleaps
fbshipit-source-id: d88a922dffeebe2bce019250d460b5e43a0af562
Summary:
When maxLength is defined in <TextInput>, if the last character at max length is an emoji, the content of the input is cleared:
{F620865178} {F620865237}
Related Github issues:
https://github.com/facebook/react-native/issues/10929https://github.com/facebook/react-native/issues/10964
## Root cause:
When NSString was created, unicode characters were 16-bit long, so Objective-C considers every unicode character as 16-bit. However, unicode was later extended to more than 16bit, for example, emojis, which causes NSString substring method cuts off at the wrong position.
Example:
```
NSString *s = @"abc{emoji:1f601}";
NSInteger len = s.length; //length is 5 (as {emoji:1f601} occupies two 16-bit characters)
NSString *s3 = [s substringToIndex: 3]; //s3 is "abc"
NSString *s4 = [s substringToIndex: 4]; //s4 is null!
```
If string s, "abc{emoji:1f601}", is entered in <TextInput>, which has max length 4, it will truncate the string to the first 4 characters, "cutting" the emoji in half which causes encoding error and returns null. The text input is cleared.
## Solution:
If the character at max length is longer than 16-bit, truncate the character BEFORE it instead. In the previous example, truncate till index 3 instead of 4. The end result will be "abc" and the emoji is dropped.
## Changelog:
[iOS] [Fixed] - <TextInput> content is reset when emoji is entered at the max length
Reviewed By: p-sun
Differential Revision: D28821909
fbshipit-source-id: 4720d864970b554160ed5388f65b352ce95a6199
Summary:
The RN OSS release process includes manual testing that a new template app can be started under various platforms, JS engines, etc. This should ideally be automated, to help reduce wasted engineer-time, and to allow reliably increasing release velocity.
`react-native-windows` does already have tests to create and build template projects across our matrix, but they do not do any runtime validation on the newly created app. Adding a `testID` to the new app screen header gives us something to search for in black-box testing to validate that the app started successfully. This should help catch cases where a sample project in repo has changes not reflected in a newly created template app.
## 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] [Added] - Add testID to NewAppScreen Header Component
Pull Request resolved: https://github.com/facebook/react-native/pull/31652
Test Plan: Did not manually validate the change, though did check that `ImageBackground` forwards props to `Image`, and that `Image` is aware of `testID` and will forward to the native component.
Reviewed By: kacieb
Differential Revision: D28907197
Pulled By: p-sun
fbshipit-source-id: db3974294afba25878383f1955cad37b69d95da3
Summary:
This fixes how ES modules are handled in Jest tests in the react-native codebase.
They caused some problems before because `import` statements weren't inlined as `require` calls were, so there were some errors in tests when migrating from CommonJS to ESM.
This changes the transform that Jest uses to inline import statements the same way, so we can migrate everything without issues in tests.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D28899692
fbshipit-source-id: 027690f57ca3b5613c261a1089c0635af76662b2
Summary:
Creates an experimental stub implementation of `createAnimatedComponent` to be implemented in future commits.
Changelog:
[Internal]
Reviewed By: lunaleaps, kacieb
Differential Revision: D28799738
fbshipit-source-id: dc3fbee557db353de6807bd87561f8f372d7cab5
Summary:
Sets up an injection mechanism for experimenting in production with an alternate implementation of `createAnimatedComponent`.
This will be used to implement and refine a new `createAnimatedComponent` that is compatible with concurrent rendering.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28799739
fbshipit-source-id: 46ba2dd6137f7bf73ce8a659698533ed3985516f
Summary:
While it is possible in the React Native implementation for Android to provide a custom configuration for HTTP requests, the iOS implementation does not allow for the same customization. As the NSURLSession used for HTTP requests on iOS is configured internally, one may for instance not supply an ephemeral configuration for HTTP requests. Other concerns related to the given problem have been addressed in the community: https://github.com/react-native-community/discussions-and-proposals/issues/166. I did make a PR with an RFC in the community repo, but after some discussion in the said repo, I figured I might as well make a PR with a suggestion :)
## Changelog
[iOS] [Added] - Allow for configuring the NSURLSessionConfiguration
Implement a C function `RCTSetCustomNSURLSessionConfigurationProvider` which gives the app programmer the ability to provide a block which provides an NSURLSessionConfiguration that will be used for all HTTP requests instead of the default configuration. The provided block will be called when the session configuration is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/27701
Test Plan: Unsure if this can be tested in any other way than uncommenting the example code in `RNTester/RNTester/AppDelegate.mm`.
Reviewed By: yungsters
Differential Revision: D28680384
Pulled By: JoshuaGross
fbshipit-source-id: ae24399955581a1cc9f4202f0f6f497bfe067a5c
Summary:
Since moving Switch to a function component it is no longer possible to get the native switch ref. This adds forwardRef so it is possible again.
## Changelog
[General] [Fixed] - Fix Switch ref forwarding
Pull Request resolved: https://github.com/facebook/react-native/pull/31629
Test Plan: Tested the change in an app using react-native-gesture-handler, which tries to set a ref on Switch. Also made sure flow still passes.
Reviewed By: TheSavior
Differential Revision: D28839605
Pulled By: lunaleaps
fbshipit-source-id: 1fee86145caeabb60c0010bb9062dddca419f7ca
Summary:
As suggested by motiz88 on D28421692 (https://github.com/facebook/react-native/commit/883e0d5752b952c829c8d45504d3532f52bb272f), make sure to still report fatal "warnings".
Changelog:
[General][Fixed] Report fatal errors even if its `type` is "warn".
Reviewed By: motiz88
Differential Revision: D28815228
fbshipit-source-id: 8d3b77958ef687a4ce64bdfccbf6ce2dc5557eaf
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Accessibility service does not announce "selected" on accessibilityState = {selected: true} of the Button Component.
Issue link - https://github.com/facebook/react-native/issues/30956
## 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
-->
[General] [Added] - Add accessibilityState prop to Slider component
Pull Request resolved: https://github.com/facebook/react-native/pull/31145
Test Plan:
Verified accessibility states are read by voiceover and talkback. Some state values aren't handled by iOS and have been identified.
Added snapshot tests to test accessibilityState.disabled = disabled values
`js1 test Slider-test`
Reviewed By: yungsters
Differential Revision: D28337723
Pulled By: lunaleaps
fbshipit-source-id: 72a54d8d9dcf1fafb9785c81da99f32a21f3df00
Summary:
Changes `ExceptionsManager` in React Native so that errors with a `type` property equal to `'warn'` are not reported.
This change is banking on the fact that `type` is a non-standard and uncommon property on `Error` instances. If this ends up being problematic, we can instead change this to use a `unstable_type` or `unstable_level` property instead.
Changelog:
[General][Changed] - ExceptionsManager will no longer report exceptions with `type === 'warn'`.
Reviewed By: motiz88
Differential Revision: D28421692
fbshipit-source-id: 3ca19e29f32c8c5cad6dac637dcb930944fb24ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Cleans up `reactConsoleErrorHandler` in `ExceptionsManager` using modern language features, and fixes a minor edge case with how warning-like errors are handled.
Changelog:
[General][Fixed] - Avoid downgrading `console.error` when passed warning-like objects.
Reviewed By: GijsWeterings
Differential Revision: D28418488
fbshipit-source-id: 394e8608c2c81c794c9a0fc155142dcfcfe1c661
Arthur Lee
Martin Sherburn
Tim Yung
Daniel Sainati
Samuel Susla
Kacie Bawiec
Luna Wei
Nishan Bende
Birkir Gudjonsson
Andrei Shikov
Kermit
Shuhao Zhang
Nick Gerleman
Rubén Norte
Håkon Knutzen
Janic Duplessis
Paige Sun
Dennis Urtubia
Evgen Filatov
Andrew Coates
Rick Hanlon
Ramanpreet Nara
Sladyn Nunes
Erich Graham
Connor Tumbleson
