Summary:
`JNIEnv`'s `FindClass(..)` function takes the classes in the standard
`foo/bar/Baz` class specification (unless they're special, like arrays).
Specifying them with `Lfoo/bar/Baz;` results in a
`ClassNotFoundException` being raised -- which is especially unhelpful
when intending to re-throw an exception.
The docs for `JNIEnv#FindClass(..)` can be found [here][jnienv].
[jnienv]:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#:~:text=The%20name%20argument,java/lang/String%22
## Changelog
[Android] [Fixed] - Correctly resolve classes with FindClass(..)
Pull Request resolved: https://github.com/facebook/react-native/pull/34533
Test Plan:
No exact test plan. However, if an exception is thrown during the
rendering process, a fatal `ClassNotFoundException` is raised, rather
than having the error be passed up to the `ReactNativeManager`.
Fixes: facebook/yoga#1120
Reviewed By: amir-shalem
Differential Revision: D39133326
Pulled By: jacdebug
fbshipit-source-id: 86283b7d21aed49ed0e9027b2aef85f0108cdf9a
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
This adds the `inputMode` prop to the TextInput component as requested on https://github.com/facebook/react-native/issues/34424, mapping web [inputMode types](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to equivalent [keyboardType](https://reactnative.dev/docs/textinput#keyboardtype) values. This PR also updates RNTester TextInputExample in order to facilitate the manual QA.
### Caveats
~~This only adds support to `text`, `decimal`, `numeric`, `tel`, `search`, `email`, and `url` types.~~
#### `inputMode="none"`
**Currently mapped to `default` keyboard type.**
The main problem with this input mode is that it's not supported natively neither on Android or iOS. Android `TextView` does accept `none` as `android:inputType` but that makes the text not editable, which wouldn't really solve our problem. `UITextInput` on iOS on the other hand doesn't even have something similar to avoid displaying the virtual keyboard.
If we really want to add the support for `inputMode="none"` one interesting approach we could take is to do something similar to what WebKit has done (https://github.com/WebKit/WebKit/commit/3b5f0c8ecf9de23f79524ed02e290837ab8334cd). In order to achieve this behavior, they had to return a `UIView` with a bounds of `CGRectZero` as the inputView of the `WKContentView` when inputmode=none is present.
~~I guess the real question here should be, do we really want to add this? Or perhaps should we just map `inputMode="none"` to `keyboardType="default"`~~
Android docs: https://developer.android.com/reference/android/widget/TextView#attr_android:inputType
iOS docs: https://developer.apple.com/documentation/uikit/uikeyboardtype?language=objc
#### `inputMode="search"` on Android
**Currently mapped to `default` keyboard type.**
Android `TextView` does not offers any options like `UIKeyboardTypeWebSearch` on iOS to be used as `search` with `android:inputType` and that's probably the reason why `keyboardType="web-search"` is iOS only. I checked how this is handled on the browser on my Android device and it seems that Chrome just uses the default keyboard, maybe we should do the same?
### Open questions
- ~~What should be done about `inputMode="none"`?~~ Add it and map it to `default` keyboard type.
- ~~Which keyboard should we show on Android when `inputMode="search"`?~~ Use the `default` keyboard the same way Chrome does
## Changelog
[General] [Added] - Add inputMode prop to TextInput component
## Test Plan
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Input modes` section
https://user-images.githubusercontent.com/11707729/185691224-3042e828-a008-4bd0-bb3d-010a6a18dfd5.mov
Pull Request resolved: https://github.com/facebook/react-native/pull/34460
Reviewed By: necolas
Differential Revision: D38900724
Pulled By: cipolleschi
fbshipit-source-id: 60d405ccdbfad588b272fbb6b220b64ffdfc4b14
Summary:
When the webview is updated by play store, all apps that has loaded webview gets killed. For background see https://issuetracker.google.com/issues/228611949?pli=1
We have a long-running app and don't want this to happen and while we are not using webview anywhere, we are using websockets that loads it for reading cookies, however we are not using cookies to authenticate the websocket and thus want to disable the webview to avoid loading it unnecessarily and then getting killed unnecessarily.
The webview has support for beeing disabled https://developer.android.com/reference/android/webkit/WebView#disableWebView() however as-is this crashes React Native. It seems to me like this case is very similar to not having web view installed and should be handled in the same way.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Avoid crash in ForwardingCookieHandler if webview is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34483
Test Plan: Add `WebView.disableWebView();` as the first line in `MainActivity.onCreate`.
Reviewed By: christophpurrer
Differential Revision: D38981827
Pulled By: cipolleschi
fbshipit-source-id: 335a8420568ad0c80b834ae8a3b164e55ebe26f3
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`:
https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298
does not work when the react native project has a parent folder with a space in the the name, for example:
`/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h`
This is because the `sed` command thinks that the part after the space is a separate argument.
This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future.
## Changelog
Add single quotes around the file parameter in the `sed` command
[iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space
Pull Request resolved: https://github.com/facebook/react-native/pull/34510
Test Plan:
Checkout the main branch.
Create a React Native project in a folder that has a space in the name.
When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed.
Run the build to reproduce the `Time.h:52:17: error`.
Checkout this branch.
Run `pod install` and notice the `sed` error is gone.
Run the build, the error should be gone.
Reviewed By: sammy-SC
Differential Revision: D39082262
Pulled By: cipolleschi
fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.
this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
There are cases where we want to pass an enum type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```enum Quality { SD, HD, }```
Approach:
- We are not generating an ```enum``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed enum types at this time, e.g. ```export enum StringOption { One = 'one', Two = 2, Three = 'three', };``` will not work. See: https://www.typescriptlang.org/docs/handbook/enums.html#heterogeneous-enums
- We only support untyped (default to String), String, and Number enum properties
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Enum Type support for C++ TurboModules
Reviewed By: RSNara
Differential Revision: D38880963
fbshipit-source-id: f2399b29948306bc555429b6f96c43ea4c39c46e
Summary:
This adds the `tabIndex` Android only prop to View as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `focusable` prop to `tabIndex` so that `tabIndex={0}` maps to `focusable={true}` and `tabIndex={-1}` represents ` focusable={false}`.
## Changelog
[Android] [Added] - Add tabIndex prop to View component
Pull Request resolved: https://github.com/facebook/react-native/pull/34486
Test Plan: I'm still investigating the best way to test this but we're are just mapping this to an existing prop
Reviewed By: GijsWeterings
Differential Revision: D38957303
Pulled By: necolas
fbshipit-source-id: d00db854e11cb3457329c1547b69cff60afb34cf
Summary:
## Context
```isRootViewVisible``` doesn't work as expected for non-Venice: when enter Marketplace tab, ```isRootViewVisible``` should returns true with Marketplace tab's rootViewTag, but it returns false.
## Root cause
```rootViewTag``` is added to "mVisibleRootTags" in "FbReactRootVisibilityTracker" when ```BaseFbReactFragment.onViewDidAppear()``` gets called, but ```BaseFbReactFragment.onViewDidAppear()``` is called earlier than when the ```rootViewTag``` is set.
## Fix
Move setRootViewTag to earlier when RootView is created instead of in startSurface or mounting.
Changelog:
[Android][Changed] - Move setRootViewTag to earlier when RootView is created
Reviewed By: RSNara
Differential Revision: D38586584
fbshipit-source-id: aec3ed37eb62289a19794e68b1a6b5ca213cb14a
Summary:
This diff introduces the API that will be used to describe React Native Components written in C++
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725766
fbshipit-source-id: 292e28409ac6be8f9a1c2209b8c558e0e2cb96ea
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5
Summary:
Small typo fix.
## Changelog
[General] [Fixed] - Typo in AssetSourceResolver
Pull Request resolved: https://github.com/facebook/react-native/pull/34520
Test Plan: No test plan is required. Just check the file changes.
Reviewed By: NickGerleman
Differential Revision: D39087572
Pulled By: cipolleschi
fbshipit-source-id: a79253d2486ee21fbf5683177b21ec534607d65d
Summary:
- Just a small typo fix
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Typo in build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/34517
Test Plan: - Check out the diff changes
Reviewed By: lunaleaps
Differential Revision: D39082272
Pulled By: cipolleschi
fbshipit-source-id: d62938d5a1e6802c6e7f44186adbbfa1a6715cf8
Summary: Changelog: [Internal] - Make AccessibilityInfo public type an exact object
Reviewed By: NickGerleman
Differential Revision: D38921820
fbshipit-source-id: 6f264595814a817fb1101788942f9127d9cc85c1
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34499
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D39051081
Pulled By: cipolleschi
fbshipit-source-id: 857e24a19a77b85f0593945e6838216ceb5b0f5d
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
https://github.com/facebook/react-native/issues/31056#issuecomment-786349025
>Re-implement accessibilityHint on Android so that rather that concatenate into the contentDescription, it sets the toolTipText property on the AccessibilityNodeInfo (not on the view). This is the closest analog to iOS's hint that Android has, as the text is announced after the contentDescription rather than part of it. It will will not adhere to users preferences on whether they want hints disabled or not, and still has no pause before it like real hints have, but it's far closer than using the contentDescription directly.
fixes https://github.com/facebook/react-native/issues/31056
## Changelog
[Android] [Fixed] - Re-implement accessibilityHint on Android to use AccessibililltyNodeInfo#setToolTipText instead of contentDescription
Pull Request resolved: https://github.com/facebook/react-native/pull/34427
Test Plan: https://user-images.githubusercontent.com/24992535/184837154-5c65dbf1-1031-4d56-ac1e-066af7e08edc.mp4
Reviewed By: christophpurrer
Differential Revision: D38982158
Pulled By: cipolleschi
fbshipit-source-id: 7a616e6df9f83bd21ca02cc26b5918986a1d64f8
Summary:
from the original design of `StyleSheet.setStyleAttributePreprocessor()` in https://github.com/facebook/react-native/issues/11138, the overwriting warning shows when the existing preprocess is be overwritten. the behavior changes from https://github.com/facebook/react-native/commit/33b385825c72. This PR revises the logic back to original design.
## Changelog
[Internal] [Fixed] - Show warning only when overwriting existing preprocessor in `StyleSheet.setStyleAttributePreprocessor()`
Pull Request resolved: https://github.com/facebook/react-native/pull/34479
Test Plan:
Unit Test
```
PASS Libraries/StyleSheet/__tests__/StyleSheet-test.js
setStyleAttributePreprocessor
✓ should not show warning when set preprocessor first time (2 ms)
✓ should show warning when overwrite the preprocessor (1 ms)
```
Reviewed By: dmitryrykun
Differential Revision: D38940676
Pulled By: cipolleschi
fbshipit-source-id: 80cf30fff62f4a02c17f7f42b3260a6011d5fc82
Summary:
When a view is rendered with a combination of `overflow: hidden` and `borderRadius: >0`, the `ReactViewGroup` would apply the border radius using Canvas `clipPath`. In Android graphics, clipPath is not an anti-aliased operation and caused aliasing artifacts.
Changing the method to a bitmask using the `PorterDuff` method results in the same functionality, but with hardware accelerated antialiasing.
https://github.com/facebook/react-native/issues/24486
Changelog:
[Android][Change] - Views with overflow: hidden and borderRadius: >0 now render anti-aliased borders.
Reviewed By: javache
Differential Revision: D38914878
fbshipit-source-id: 45ac7e4aece7a76c4216412175e49d3d73b6f391
Summary:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in https://github.com/vonovak/react-native/commit/f319ff321c4b7c0929b99e3ebe7e1ce1fa50b34c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](https://github.com/facebook/react-native/blob/f3db6cc52792e3006a16408df4ae40f3aee19a86/React/CoreModules/RCTAlertController.m#L24).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>
</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
This PR bumps the Hermes cache keys because they got corrupted due to some sync delay between Hermes and React Native.
## Changelog
[iOS] [Fixed] - CI broken due to Hermes Commit
Pull Request resolved: https://github.com/facebook/react-native/pull/34491
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38976132
Pulled By: cipolleschi
fbshipit-source-id: 16df11ede8947d8376d316b126eefcf0177d16de
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Evan Charlton
Ramanpreet Nara
Mitch Powell
Pieter De Baets
Gabriel Donadel Dall'Agnol
Rasmus Eneman
Matt Blagden
Gabriel Rogan
Kudo Chien
Christoph Purrer
Lulu Wu
Daksh Bhardwaj
David Vacca
Luna Wei
dhruvtailor7
Jérémy Barbet
Paige Sun
Harrison Spain
Lorenzo Sciandra
hurali97
fabriziobertoglio1987
Shawn Shihang Wei
Vojtech Novak
Marshall Roch
Riccardo Cipolleschi
Vincent Riemer
Samuel Susla
