Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46205
When React.Activity unmounts and remounts effects, we fail to re-attach the native view to the NativeAnimated nodes, which causes animations to stop working.
Changelog: [Internal]
Reviewed By: sammy-SC, bvanderhoof
Differential Revision: D61662164
fbshipit-source-id: 8e86502f7258beba02d5e60b31864974d7288af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46179
Changelog: [Internal]
**Context**
- When debugging E2E tests, we found RNTester Legacy Arch builds were rendering border radius w/ percentages in a strange way
- The issues was only noticeable on production e2e builds
- Support for percentage on borderRadius ViewStyle props was added in D56198302
- This should be fabric only, but the same props are parsed on Paper
**Change**
- Add Custom Conversion for BorderRadius on Paper
- Only Parse integer border radius values
Reviewed By: philIip
Differential Revision: D61686841
fbshipit-source-id: cc24d3dbdb82b1dcb90f18fc44d5d13d3e6465b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46188
UBSAN identified undefined behavior when argCount == 0 (defining a variable array of zero length).
Plus variable arrays in C++ are a clang extension.
[ChangeLog]: [General] [Fixed] - Undefined behavior fix in MethodInvoker
Reviewed By: nlutsenko
Differential Revision: D61725776
fbshipit-source-id: 3729080eae8e78b65a558305f68782ae99edbc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46143
Before `drop-shadow` was not creating a stacking context causing its children to get flattened and not receive the shadow effect.
This was due to incorrect parsing on C++. We didn't notice since we don't support `drop-shadow` on iOS and Android gets the parsed prop directly
Changelog: [Internal]
Reviewed By: NickGerleman, joevilches
Differential Revision: D61617699
fbshipit-source-id: a8bfbb0043fcd2b2867923eb937a6be8e9004f13
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - Line break mode for TextInput components. **This includes iOS updates to consume new cpp functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46129
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656969
Pulled By: cipolleschi
fbshipit-source-id: 4c6ed983ad15841ce52443bba13962d45c04e756
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - Line break mode for TextInput components. **This includes cpp changes and new functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46130
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656894
Pulled By: cipolleschi
fbshipit-source-id: 9a25387cb27cded072e76575e6d2fca01963c621
Summary:
A previous attempt at fixing this issue used a relative path (https://github.com/facebook/react-native/issues/45208), this doesn't work if the user runs bundle install outside of the `ios/`
folder, using the `--project-directory=ios` argument.
## Changelog:
[iOS][Fixed] support bundle install from outside the ios folder using --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/46186
Test Plan:
Ran the command in a project with `react-native-firebase/app` using the
`--project-directory`, confirmed that it's fixed when using the absolute
path.
closes: reactwg/react-native-releases#341
Reviewed By: cipolleschi
Differential Revision: D61719821
Pulled By: blakef
fbshipit-source-id: d83429dd29c9e8cc066ab9843ad95fdfc0af8dea
Summary:
This PR adds few missing text content types on iOS (available from iOS 15)
- dateTime
- flightNumber
- shipmentTrackingNumber
## Changelog:
[IOS] [ADDED] - Add support for missing text content types
Pull Request resolved: https://github.com/facebook/react-native/pull/42788
Test Plan: Make sure that `RNTester` builds and runs successfully
Reviewed By: robhogan
Differential Revision: D61656748
Pulled By: cipolleschi
fbshipit-source-id: e960eded5f049d3c4bf76a5a4e3159b240546288
Summary:
I couldn't find a reference nor a reason for this method. It's a bit hard to grep, so let me know if I missed something.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61558809
fbshipit-source-id: d977440ff98b2a5bf115d19bfa4acbcf6d216b2a
Summary:
FIXES https://github.com/facebook/react-native/issues/45858
When working with UIRefreshControl in a custom React Native component, we encountered a problem where the refresh control did not behave correctly if it was offscreen. Specifically, attempts to programmatically begin or end refreshing were ignored if the control was not visible. This typically manifested as the refresh control not updating its state properly when it was re-rendered or moved in the view hierarchy.
Happening only on old-arch.
**Problem Details**
**Offscreen Refresh Control Ignored:** The UIRefreshControl would ignore calls to beginRefreshing and endRefreshing if it was not currently visible on the screen.
**Inconsistent State:** The internal state _currentRefreshingState might not match the actual state of the UIRefreshControl, leading to unexpected behavior.
**Steps to Fix**
**Track Visibility with didMoveToWindow:**
Implement the didMoveToWindow method to track when the refresh control is added to or removed from the window.
Use a flag _hasMovedToWindow to keep track of this state.
And check this flag should be true whenever we start or end refreshing
## Changelog:
[IOS] [FIXED] - Fixed an issue where the refresh control would not behave correctly if it was offscreen.
Pull Request resolved: https://github.com/facebook/react-native/pull/45996
Test Plan:
Issue Screen recording
https://github.com/user-attachments/assets/73b45c27-19c2-4eeb-991e-33b45f0a6d97
Fix Screen Recording :
https://github.com/user-attachments/assets/ffc6b6e6-fc68-498c-abdf-3144c31caa86
Reviewed By: realsoelynn
Differential Revision: D61657472
Pulled By: cipolleschi
fbshipit-source-id: 7a369f8e3ca902536a7608fbe1b89cec7734c418
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46176
Noticed that ModalHostView's event dispatching would sometimes fallback to RCTEventEmitter, which is not supported in the new architecture. Instead, we should propagate the reactTag to the inner content view so we can correctly associate the right UIManager and host component with events emitted.
Changelog: [Android][Fixed] PointerEvents from Modal would not be dispatched correctly in new architecture.
Reviewed By: bvanderhoof
Differential Revision: D61671005
fbshipit-source-id: 6aad1ff609da81cf5e8f71c4e91be30713494679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45966
JSI performs the check itself, no need to do it here. Plus, bytecode
bundles must not be zero terminated.
## Changelog:
[IOS] [FIXED] - Fixes NSDataBigString length calculation
Reviewed By: realsoelynn
Differential Revision: D61058869
fbshipit-source-id: 15b99ef13f9aebd11ff410d02c21db8e46cc6ac3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46156
Changelog: [internal]
This improves the handling of disconnected nodes in `IntersectionObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61656597
fbshipit-source-id: 6a39c878acc976ddc0789260106da104a3f2a57f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46157
Changelog: [internal]
This improves the handling of disconnected nodes in `MutationObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61655856
fbshipit-source-id: d18a885350ef000fc563c85f6775ba864d184ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46138
jorge-cab noticed that filters on iOS do not fit the shape of the layer if we have rounded corners. Fix is pretty straight forward.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61612655
fbshipit-source-id: 91785ed10a039e031c5440bde131c1583ba3992a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46146
Changelog: [Internal]
`unit` is of type `UnitType`, so there's no reason to have a default case here.
i found this because my build failed when pulling in this dependency, there was a compiler flag that enforced that all cases must be enumerated. this seems like the right practice anyways.
Reviewed By: NickGerleman
Differential Revision: D61635463
fbshipit-source-id: b84b5518f2a17e792309f85ae91514a17abad295
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46103
Reducing the boundary of rerender of virtual lists. Previously with prop: "strictMode={true}" the VirtualizedList still re rendered each CellRenderer component. Because method getDerivedStateFromProps generated every time a new uniq state and the cells didn’t have a PureComponent. It helps to improve react performance for lists which have 5+ elements.
I reused recomended approach from react doc https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization
changelog: [internal]
Optimizing CellRenderer of VirtualizedList
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D61493434
fbshipit-source-id: 917a33e48bd2f18e8ac150e5701d2e7c45dbe879
Summary:
Clean up some dead code after some refactoring of RCTParagraphComponentView. cc cipolleschi
## Changelog:
[IOS] [FIXED] - Clean up RCTParagraphComponentView & RCTParagraphTextView
Pull Request resolved: https://github.com/facebook/react-native/pull/46125
Test Plan: CI green.
Reviewed By: christophpurrer
Differential Revision: D61603193
Pulled By: cipolleschi
fbshipit-source-id: a357e8c5355707b2296462de513010acda4ee6ea
Summary:
In the recent 0.75 release I've noticed new `CONFIG_CMD` option in `react-native-xcode.sh`. But this option was not used. Insted when set `CONFIG_APP` was used.
This seems like a bug. As the usage before this PR would be as follow:
```bash
export CONFIG_CMD=true
export CONFIG_APP="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
After this PR
```
export CONFIG_CMD="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
This PR also removed unused explicite `--config-cmd "$CONFIG"` flag, as this is always overwriten by the code above, by default to `--config-cmd" "$NODE_BINARY $NODE_ARGS $REACT_NATIVE_DIR/cli.js config`.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS][Fixed] - Use CONFIG_CMD if set
Pull Request resolved: https://github.com/facebook/react-native/pull/46112
Test Plan: I've set `CONFIG_CMD` and run Xcode Release build to check that the set command is executed.
Reviewed By: christophpurrer
Differential Revision: D61545010
Pulled By: blakef
fbshipit-source-id: ebbf8ebc08404bc6816277518a3b86c6f7e41e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46131
React native 0.75.0, 0.75.1 and 0.75.2 has been published to NPM without the latest tag, despite the tag being on the commit.
When debugging why that's happened, I realized that we were not downloading the tags when checking out the repo.
This change fixes that.
{F1816667285}
## Changelog:
[Internal] - Publish React native as latest when the latest tag is specified on git
Reviewed By: cortinico
Differential Revision: D61593398
fbshipit-source-id: 96bf8346207f0bd0b01f60ee09879210d12d30af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46132
Temporaily disable the `nativeSourceCodeFetching` capability — which reverts this to the legacy handling in the Inspector Proxy.
This is because we've noticed performance issues when loading large bundle source maps, particularly on Android, with a nontrivial path to optimising this ([raising the frontend `IO.read` size](https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/97) further is leading to WebSocket disconnections on Android 😐).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61543480
fbshipit-source-id: ee66b4cebd40f8cc6466270c5875df744d2b588a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46113
changelog: [internal]
This showed promised in local tracing but that failed to translate to real perf improvement. Unshipping.
Reviewed By: christophpurrer
Differential Revision: D61537744
fbshipit-source-id: 03a2a69a6fed32a6b493bc17372e3783b9db2d1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46122
Implements a JavaScript cache for `colorScheme` in the `Appearance` module, so that we avoid potentially expensive and unnecessary native property accesses.
Changelog:
[General][Changed] - Improved `Appearance.getColorScheme` performance
Reviewed By: rickhanlonii
Differential Revision: D61567880
fbshipit-source-id: ca316946d68114b05239daa17105c85e637efe07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46120
Currently, the implementation of `Appearance` duplicates the validation logic of string `colorScheme` values multiple times.
This leads to more complicated code and also unnecessary work in certain edge cases (e.g. when `NativeAppearance` is not registered).
This refactors `Appearance` to be simpler and to do less work. I've also configured `NativeAppearance.setColorScheme` to be non-nullable because it has existed since 2023.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567881
fbshipit-source-id: 61cb51709dc716ad97ae1397105414e74fe57a28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46121
Updates `Appearance` on Android to supply the native module to `NativeEventEmitter` so that the native listener count can be managed like it is on iOS.
This was previously required by macOS and iOS. Android and Windows also already implement:
```
interface NativeModule {
addListener(eventType: string): void;
removeListeners(count: number): void;
}
```
So we should start passing `NativeAppearance` into the `NativeEventEmitter` constructor across all platforms.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567883
fbshipit-source-id: 1b3b76de9be3f35cacba1acbc43f6dcc0b41fde5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45859
"Fabric without SVCs" configuration is nearly gone, and so it doesn't make sense to need to add no-op methods, on normally Paper only code, etc to satisfy native viewconfig. These particular warnings are then more often noise, than things we need to action on.
Checking for native code to be present can also break development where users are using distributed native app, slightly older than JS.
This keeps the warning, only if static viewconfigs are missing native view config attributes (i.e. new prop would only be exposed to Paper, instead of only exposed to Fabric)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60575253
fbshipit-source-id: 1c118274b92eb7922c0dd92df060b24e44fceb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46116
If your app raises an early js exception, and you cold start it, often you'll see this error:
```
SurfaceRegistryBinding::startSurface failed. Global was not installed.
```
{F1807125099}
The reason why is because two different threads race to redbox:
* The nativemodule thread: the early js error (reported [here](https://fburl.com/code/vcrqzsdp))
* The javascript thread: the SurfaceRegistryBinding error (a subsequent native -> js call)
After this diff, the early js error will **not jump onto the nativemodule thread** to report this error.
This ensures that we "always" (to the best of my knowledge) see the early js error first.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D61339213
fbshipit-source-id: f1b9ab30150b87377817c2fd93ca349c406db48b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46104
We want to use `PrecomputedText` to store glyph-level measurements on underlying Android Spannable. This means we need to consistently reuse the same Spannable, instead of recreating them on measurement.
We have an opaque cache ID used by Android, for spannables originating from uncontrolled TextInput on UI-thread side. We also have `AttributedStringBox`, for a kind of similar purpose on iOS, which allows passing opaque pointer to the `TextLayoutManager`. This is only used for the `measure` function.
This change makes us consistently use `AttributedStringBox` at the TextLayoutManager boundary, to let us migrate calls across TextLayoutManager to all pass opaque handle to underlying Spannable we will store, instead of passing the AttributedString each time. For now, every place previously passing an AttributedString value still passes one.
There were also some egregious cases of accepting very large structures by value, causing unneeded copies. I changed the APIs to accept anything potentially larger than two pointers to pass by reference instead.
This change is technically breaking, to any 3p code calling into TextLayoutManager (IIRC live-markdown exposed prefabs for this, but should be able to adapt fairly easily).
Changelog:
[General][Breaking] - Always use AttributedStringBox instead of AttributedString in TextLayoutManager
Reviewed By: joevilches
Differential Revision: D61484999
fbshipit-source-id: 07c5600cd917f2dab3d24559a25f27e0872ebddc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46080
1. Force the examples to be alphabetized, where the hand-maintained list has some examples that are not
2. Remove reundant/not useful UI
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61430910
fbshipit-source-id: 1f3e116fe81502faa7a72f2720912e26c9f04bb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46076
This will add the shadows to iOS as well. let's see if anyone notices 🙂. I also removed dead styles, and removed some of the extra (excessive) padding specific to Android where the previous shadows would overlap.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D61421903
fbshipit-source-id: 887fa5aa96e3b0b4f81114ee814897c218db2b76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46117
Currently in large cursive blocks like layout effect we can't tell what the slow leaf function is. With this fixed I'm able to root cause more complex issues in layout effects.
Reviewed By: NickGerleman
Differential Revision: D61486415
fbshipit-source-id: 5a4043b35eedcabcbea86953aac2173f66d7257b
Summary:
Fixes these issues:
- https://github.com/facebook/react-native/issues/46070
- https://github.com/facebook/react-native/issues/39362
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fixed black strip coming when hiding status bar
`setHidden` function is responsible for hiding status bar
https://github.com/facebook/react-native/blob/25d6a152cc720e0d5f860dab228ac2e43321d9e4/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/statusbar/StatusBarModule.kt#L122
**What real issue is?** **_For android devices with camera area on top a black strip is coming after hidding status bar._**
Previous Implementation:
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
Log.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
It seems that FLAG_FULLSCREEN flag are not enough to draw content in camera area.
**Solution:**
In order to tackle this, android exposes 2 flags:
- [layoutInDisplayCutOutMode](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#layoutInDisplayCutoutMode): The window is always allowed to extend into the [DisplayCutout](https://developer.android.com/reference/android/view/DisplayCutout) areas on the short edges of the screen. [Android 9.0 and above]
- [setDecorFitsSystemWindows](https://developer.android.com/reference/android/view/Window#setDecorFitsSystemWindows(boolean)): allows content to be able to extend into the cutout area. [Android 10.0 and above]
By adding this flag we are now able to hide status bar properly.
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
FLog.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
// Ensure the content extends into the cutout area
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
window.setDecorFitsSystemWindows(false)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT
window.setDecorFitsSystemWindows(true)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
**_Note: This will work above Android 11 and above_**
Pull Request resolved: https://github.com/facebook/react-native/pull/46086
Test Plan:
- Tested by author of this issue
- Sharing here the videos of before and after fix
Device Detail:
Oneplus9 5G OS 11
**Before fix:**
https://github.com/user-attachments/assets/589098ff-a3fa-4962-a15b-ceacbfd03d2d
**After fix:**
https://github.com/user-attachments/assets/a87dd8e4-3624-4e09-99da-a14f9e19fcc6
Reviewed By: cipolleschi
Differential Revision: D61509889
Pulled By: alanleedev
fbshipit-source-id: 733962a3bed2efba71588a4d2fdf7c9c386bc3b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46101
Remove overriding thread priority for RN Main Thread as it is not possible to update main thread.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D61448536
fbshipit-source-id: 44ec28a875e3208df042ac11bdd17a7287836ebb
Tim Yung
Pieter De Baets
Ingrid Wang
Shawn Dempsey
Riley Berton
Jorge Cabiedes Acosta
shubhamguptadream11
Blake Friedman
Kacper Rozniata
Jan Kassens
zhongwuzw
Deepanshu.shukla
Samuel Susla
Tzvetan Mikov
Rubén Norte
Joe Vilches
Jakub Piasecki
Phillip Pan
Nick Gerleman
Thomas Nardone
David Vacca
Andrei Marchenko
Soe Lynn
Krystof Woldrich
Riccardo Cipolleschi
Alex Hunt
Ramanpreet Nara
generatedunixname89002005232357
Benoit Girard
Alan Lee