Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44905
Replaces the last template CI job.
Changelog: [Internal] [Changed] Use Helloworld in GHA CI workflow.
Reviewed By: cortinico
Differential Revision: D58466813
fbshipit-source-id: 333b9a4c71eec6901c78f144db48f365539c6a5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44936
# Changelog: [Internal]
Added a small test that uses `folly:ManualExecutor`, which reproduces the memory leak issue in Hermes' RemoteObjectsTable:
1. Send `Runtime.enable`
2. Evaluate `console.log(<object>);` to populate `RemoteObjectsTable`
3. Send `Page.reload` to reload VM
This test is expected to fail, because by the time it is published, the D58398254 hasn't landed.
Reviewed By: motiz88
Differential Revision: D58531763
fbshipit-source-id: 99af3bfce0a31fe905d5bf2bf433f62cfbc34897
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44887
The previous inexact object types and documentation for Share.share()'s arguments have led to confusion in how this library should be used. This diff updates the argument types to be more explicit, and rewrites some of the documentation for clarity.
Changelog:
[General][Breaking] Update `Share.share()`'s argument types to be more explicit.
Reviewed By: NickGerleman
Differential Revision: D58224906
fbshipit-source-id: 5ac8efe7caa0ecdd430fa7a1951c73c4acd8c6a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44938
Yoga is transitively included in Swift targets and needs to be modular.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58469454
fbshipit-source-id: 72bc6b5d3e5ee0710d9334a626e4e7297ce26b09
Summary:
Changelog: [ANDROID] [ADDED] - Add the ReactMarkerConstants.CONTENT_APPEARED support on Android in bridgeless mode.
This re-applies https://github.com/facebook/react-native/pull/43620 which was reverted because a CI job started failing because we forgot to update `packages/react-native/ReactAndroid/api/ReactAndroid.api`.
Reviewed By: cortinico
Differential Revision: D58535868
fbshipit-source-id: 9eec33c5e798850a7434a6c391abf2fc3fc9d0a6
Summary:
Changelog: [Internal]
Showing warnings in LogBox is noisy, confusing for web developers, and not the best use of screen real estate on mobile platforms. Since the Fusebox console offers a superior experience, as of this diff we'll suppress warnings in LogBox if we detect that Fusebox is available.
*The first time* a warning is suppressed, globally (i.e. at most once per app launch), we'll show a notification pointing the user towards Fusebox. When the notification is clicked, we call the `DevSettings.openDebugger` method and dismiss it.
The wording of the notification ("Open debugger to view warnings") is intentional:
1. It's short enough to fit on small screens in its entirety.
2. It doesn't actually say "*click here* to open the debugger". This is for the best because `DevSettings.openDebugger` is a best-effort method that might fail, and in the current implementation there's no reliable feedback to the user about the success/failure of the launch.
Reviewed By: huntie
Differential Revision: D57681446
fbshipit-source-id: fe6101785780de3bc586ade11f471f7c74707be1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44934
Resubmission of D57681447 with an updated `ReactAndroid.api`.
---
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: huntie
Differential Revision: D58529832
fbshipit-source-id: e5510f529a19e0149d8dce04fa610e6c2371cc79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44910
Props within the `Text` component are accessed both via destructuring the props object but also in some cases by using a "dot" access on the destructured `restProps`. However in all of the "dot" access cases the property is being overrided. Which means in the final JSX these properties get set twice, e.g. via the `restProps` spread then overrrided by static properties. This change just destructures all values to avoid this inefficiency.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58446569
fbshipit-source-id: 12a800f5e2218a1d95d57cc689a4c79caab480b4
Summary:
This change removes the need for the trigger-react-native-release.js script.
Thanks to the migration to Github Actions, we can now leverage the GHA workflow UI to trigger a Prepare Release job that creates a github tag that will spin a new release.
The pro of this approach are:
- less code to maintain: instead of a complex trigger release scripts, we only have to maintain two very straightforward scripts for the CI
- easier to trigger a release: instead of running a script, we can now just use the GH UI
The `trigger-react-native-release` script was doing the following steps:
- check that we are in the release branch ==> Already implemented in the GHA workflow
- Gets the branch name (not needed) ==> the job will automatically run on the stable branch
- Check for unsent changes (not needed) ==> we are not in a local environment
- get the gh token (not needed) ==> You need to be logged in GH and have write access to the repo
- get the version ==> provided as a parameter
- fails if the tag is already there ==> Functionality added in the workflow
- Parse and validate the version ==> Functionality added to the action prepare-release action + the JS Script
- Compute the npmTag ==> Functionality added to the action prepare-release action + the JS Script
- trigger the release workflow ==> The GH UI does that for us
## Changelog:
[Internal] - Remove the trigger-react-native-release.js
Pull Request resolved: https://github.com/facebook/react-native/pull/44898
Test Plan: Testing in Production!
Reviewed By: cortinico, huntie
Differential Revision: D58461470
Pulled By: cipolleschi
fbshipit-source-id: 32bb0ee91370c9483a29e2ca2e18e24557d5fd53
Summary:
Add 0.72.15 to Changelog
## Changelog:
[Internal] [Changed] - Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44904
Reviewed By: cipolleschi
Differential Revision: D58470819
Pulled By: cortinico
fbshipit-source-id: 20a1816811213ed9a69f1ede3579aa8fc661faf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44901
Point Gradle to the monorepo instead of a node_modules, as well as remove some commented out entries we're not interested in.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58287786
fbshipit-source-id: 92b3d15d05c55a2589bb8a6b75dc3d5d0f9756ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44647
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: hoxyq
Differential Revision: D57681447
fbshipit-source-id: ddb1fbd0f1c8d07bfa57d65c54e3a34bb7a470a8
Summary:
Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode. This is an important marker for TTI measurement.
## Changelog:
[ANDROID] [ADDED] - Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/43620
Test Plan:
adding this on RNTesterActivity to see if the log is executed
```kotlin
ReactMarker.addListener { name, tag, instanceKey ->
if (name == ReactMarkerConstants.CONTENT_APPEARED) {
Log.i("XXX", "XXX")
}
}
```
Reviewed By: cortinico
Differential Revision: D58459930
Pulled By: rubennorte
fbshipit-source-id: 4498a3623c506d228aea995c8aeafdb51fcc5b96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44925
I have the suspect this is causing our builds to be slower and especially causing the template tests to take 6 hours.
Let's try to disable it.
Changelog:
[Internal] [Changed] - Do not publish Gradle Scans
Reviewed By: cipolleschi
Differential Revision: D58520463
fbshipit-source-id: 028e16a725ea87e178ed4e0bf134737f32780544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44909
Today we wrap all `onPressIn` and `onPressOut` callbacks we pass to pressability so we can set the `highlighted` state. However highlighted state is only ever set to anything other that false on iOS. This change not only skips calling `setHighlighted(false)` on every press event but also skips wrapping the callback.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58391419
fbshipit-source-id: e79f51469609a59063098501f015f8078e3db79f
Summary:
This PR solves [this issue](https://github.com/facebook/react-native/issues/44151).
Inverted FlatList doesn't work (elements cannot be clicked) when the list is scrolled.
## 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
-->
[GENERAL] [FIXED] - Fix clicking items on the inverted FlatList on the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/44168
Test Plan:
# Steps
1. `buck2 install catalyst-ios` or `buck2 install catalyst-android`
2. Go to `RNTester Browser - Fabric` -> `FlatList` -> `Inverted`
3. Toggle inverted to `true`
4. Scroll to the top
5. Tap down and drag to either left or right
6. Expected is to have Red highlighted (which indicate Press Down) when dragged.
## iOS
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vCW | https://pxl.cl/53vDq |
## Android
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vFp | https://pxl.cl/53vFG |
## Reproducing steps from OSS
1. Use this reproducer: https://github.com/WoLewicki/reproducer-react-native/tree/%40wolewicki/flatlist-inverted
2. Apply changes from this PR & build the app.
3. Scroll a bit the list, so it changes the position.
4. The `onPress` should be fired when the button is clicked.
5. Do the following tests:
1. Add a `horizontal` prop to the FlatList - verify everything works.
2. Remove a `inverted` prop - verify everything works.
3. Remove a `inverted` prop and add a `horizontal` prop - verify everything works.
6. Test different combinations of transforms of the FlatList, example:
```javascript
<FlatList
inverted
horizontal
style={{
transform: [
{scaleY: -1},
{scaleY: -2},
{scaleY: -0.5},
{translateY: 20},
{translateY: -10},
{skewX: '10deg'},
{rotateX: '10deg'},
],
}}
/>
```
<details>
<summary>Reproducrer</summary>
https://github.com/facebook/react-native/assets/104823336/28cfe607-43e8-4f80-bbfb-59085ae0f986
</details>
<details>
<summary>RN tester</summary>
https://github.com/facebook/react-native/assets/104823336/e00cd488-d98f-4ece-9cab-b8a7212acb04
</details>
Reviewed By: arushikesarwani94
Differential Revision: D56441112
Pulled By: realsoelynn
fbshipit-source-id: 82c47f6bcc1f25cfbbd55aedf9652052bb86cf47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44912
While moving from CircleCI → GHA, we're removing this blocking folks landing PRs and just running on main. We will re-enable once GHA is stable.
Changelog: [General][Changed] Disable GHA on PRs until it's stable
Reviewed By: NickGerleman
Differential Revision: D58478000
fbshipit-source-id: 053ee53455956bf19b6f9113cb796346359ad4ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44803
This change introduces a new prop to the Android `Image` component: `resizeMultiplier`. This prop can be used when the `resizeMethod` is set to `resize`, and it directly modifies the resultant bitmap generated in memory from Fresco to be larger (or smaller) depending on the multiplier. A default of 1.0 means the bitmap size is designed to fit the destination dimensions. A multiplier greater than 1.0 will set the `ResizeOptions` provided to Fresco to be larger that the destination dimensions, and the resulting bitmap will be scaled from the hardware size.
This new prop is most useful in cases where the destination dimensions are quite small and the source image is significantly larger. The `resize` resize method performs downsampling and significant image quality is lost between the source and destination image sizes, often resulting in a blurry image. By using a multiplier, the decoded image is slightly larger than the target size but smaller than the source image (if the source image is large enough).
It's important to note that Fresco still chooses the closest power of 2 and will not scale the image larger than its source dimensions. If the multiplier yields `ResizeOptions` greater than the source dimensions, no downsampling occurs.
Here's an example:
If you have a source image with dimensions 200x200 and destination dimensions of 24x24, a `resizeMultiplier` of `2.0` will tell Fresco to downsample the image to 48x48. Fresco picks the closest power of 2 (so, 50x50) and decodes the image into a bitmap of that size. Without the multiplier, the closest power of 2 would be 25x25, which is half the quality.
## Changelog
[Android][Added] - Adds a new `Image` prop `resizeMultiplier` to help increase quality of small images on low DPI devices
Reviewed By: javache
Differential Revision: D58120352
fbshipit-source-id: e0ebf4bd899170134825a29f72a68621447106c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44885
Cleanup accessibility related props checks to ensure we are doing the minimal amount of work. e.g. reduce duplicate `null` checks and shift checks to conditional branches that use them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58390430
fbshipit-source-id: f2c8989b6520cda9f14f9a04cd4fd6e126c501fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44877
Changelog: [Internal]
We're seeing a sporadic iOS crash that suggests `[RCTBridge dealloc]` is being called off the main queue (despite a comment suggesting it shouldn't be). This exposes a race condition between destroying the `HostTarget` and attempting to unregister the instance+runtime from it . Here we use `RCTExecuteOnMainQueue` to make sure the `HostTarget` destruction is always sequenced after the `unregisterFromInspector()` call.
Reviewed By: huntie
Differential Revision: D58415684
fbshipit-source-id: a22e239c80c3204fe32b9e73719ffaa131feaffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44911
This diff reverts D58288489
D58288489: [RN][Fusebox][iOS] Implement new HostTargetMetadata fields (iOS) by huntie causes the following test failure:
Tests affected:
- [fbsource//xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern:testsAndroid - main](https://www.internalfb.com/intern/test/844425054538351/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5466028
Here are the tasks that are relevant to this breakage:
T191385299: 50+ tests unhealthy for react_native
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58475289
fbshipit-source-id: 3a4476d1350c4986cdb673bdb4ac52af353a00ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44495
## Summary
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, dark mode support, alignment of buttons, etc.
This change provides a fallback to the original `android.app.AlertDialog` if the current activity is not an AppCompat descendant.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57113950
fbshipit-source-id: ba5109c9d79b6ceb042ff93eebe796a2d14ebd63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44494
Pull Request resolved: https://github.com/facebook/react-native/pull/44880
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, alignment of buttons, etc.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
- This change requires all implementing activities to have a theme that inherits from `Theme.AppCompat`. Creation of any activities which do not have a descendant of this style will result in an `IllegalStateException`: https://www.internalfb.com/intern/signalinfra/exception_owners/?mid=5ee93f6ecd59f3d8ad82a78c213ea016&result_id=16044073705339118.281475102518721.1715097866
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57019423
fbshipit-source-id: 84d8f69d896d32e72434149c0e31735d358370a9
Summary:
This change migrates the GHA template jobs to the HelloWorld package for iOS.
## Changelog:
[Internal] - Move iOS template jobs to HelloWorld
Pull Request resolved: https://github.com/facebook/react-native/pull/44875
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D58459398
Pulled By: cipolleschi
fbshipit-source-id: 95404445d7375186860af5835b750b4735795434
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44811
Changelog:
[General][Fixed] - Debugger frontend socket-termination countdown now begins after the ping message is actually sent
The debugger is currently disconnected if a ping-pong message is missed.
This causes the debugger to be unusable if it happens to be lagging, e.g. when the initialisation is competing with the flood of log spam T191394188
There are a few ways to fix this as discused with motiz88 and robhogan:
1. Ensure the websocket has a chance to respond, e.g. in via web worker
1. Lengthen the time allowed for the pong resopnse
I've done some digging to find the root cause of the UI being blocked in CDT, However, profiling shows that most of the work is not simple to break up, i.e. the number of expensive re-layout calls. Diving into that rabbit hole could mean accidentally writing React.
Because we ping every 10 seconds, we could get un/lucky where CDT happens to be busy _at that exact moment_, making this a flaky symptom to fix, even if we lengthen the allowed time-to-respond.
# V2+
So upon further investigation, CDT websocket is actually responding to the pings in due time:
{F1679132204}
(CDT doesn't show the ping/pong API as frames, so a custom tick/tock message was used to visualise the timing)
Over here in dev-middleware, we currently start a timeout to terminate the socket after sending the ping:
https://www.internalfb.com/code/fbsource/[813870db697a8701f2512d25a7fed730f0ec6ed9]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/InspectorProxy.js?lines=306-307
If CDT doesn't respond in time, websocket would be terminated.
But we saw CDT respond immediately above, even during the log spam, so the delay must be coming from somewhere else.
The intuition is that during the log-spam, the middleware takes a perf hit too when it's processing the spam from the device and forwarding it to the CDT websocket.
We can confirm this by passing a "sent" callback via `socket.ping(cb)`:
9bdb58070d/lib/websocket.js (L246-L254)
This gives us the timing between calling `socket.ping()` and when the ping is actually sent.
Regular, stress-free operation without log-spam shows most pings are sent within the same millisecond:
{F1679223326}
With the pong response grace period at 5 seconds, there's plenty of time for CDT to `pong` back. That's why it has been working in most cases.
However, during the log-spam, we easily see this send-sent delay over 5 seconds. In extreme cases, almost 30 seconds would have passed before middleware sent a message to CDT, which then responded under 2 seconds:
{F1679163335}
This means while CDT is getting flooded and has observable lag in the UI, the smoking gun is actually the middleware.
Digging a little deeper, we know that incoming messages from the target goes into a Promise queue, including the console logs:
https://www.internalfb.com/code/fbsource/[d5d312082e9c]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/Device.js?lines=155-157
This means during the flood of logs from the target, the Promise queue keeps getting chained rapidly for each message.
Meanhile, the `ws` lib uses the underlying NodeJS `Socket.write` method for `ping(…)` and `send(…)`:
9bdb58070d/lib/sender.js (L349)
…which is guaranteed to fire the callback asynchronously:
https://github.com/nodejs/help/issues/1504#issuecomment-422879594
Promise queue is in the macro task queue, which gets priority before the micro task queue. So if the Promise queue is not cleared yet, the websocket queue will have a hard time getting executed in time – explaining the extreme send-sent durations during a log spam.
The fix is simple:
1. Start the terminate-socket-timer until the `ping` is actually sent
1. Treat any incoming message (along with `pong`s) as a terminate-socket-timer reset
1. This also applies if `pong` comes in between `send` and `sent`, which can happen sometimes due to the async nature of the callback:
{F1679288626}
# V1
~~In this diff, a more forgiving mechanism is introduced, i.e. CDT is allowed to miss a ping-pong roundtrip 3 times before the websocket connection is terminated.~~
~~This allows a bit more breathing room for CDT's initialisation during log spam while maintaining the same ping-pong interval for VS Code to keep the auto SSH tunnel alive.~~
Reviewed By: huntie
Differential Revision: D58220230
fbshipit-source-id: 7111c9878492d8755a6110a5cdf4ef622265001d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44894
Adds the new CDP domain `ReactNativeApplication`, with the following messages:
- `ReactNativeApplication.enable` (method) — Sent by the connected frontend to enable features under this domain.
- `ReactNativeApplication.metadataUpdated` (event) — Sent by the backend containing a metadata object about the host.
We intend to use this for displaying richer information in the debugger frontend, such as device information and React Native version.
Changelog:
[General][Added] - Add `ReactNativeApplication.[enable,metadataUpdated]` CDP messages for reading host metadata
Reviewed By: motiz88
Differential Revision: D58288490
fbshipit-source-id: 02384f0cdfaa35f1c5de9fad7ddd5aab483b2768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44878
A refactor moving `SessionMetadata` (now renamed as `HostTargetMetadata`) out of `inspectorTarget->connect()` calls into a `HostTargetDelegate::getMetadata` method. This provides a cleaner interface and location for extending metadata fields in future.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58288491
fbshipit-source-id: 67e8b9a3fb6d0b7966187fa98d9852222f242b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44897
changelog: [internal]
To get better understanding of where the time is spent, let's split IntBufferBatchMountItem systrace section into individual types.
Reviewed By: javache
Differential Revision: D58080444
fbshipit-source-id: d71dcc74a042c6c40270ca6f1dc7a8735c0471b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44895
Enables the new debugger stack (codename Fusebox) in RNTester.
This feature is experimental and is enabled for testing purposes only. This change **should not** be adopted as the default by React Native frameworks.
Changelog: [Internal]
Reviewed By: cortinico, rubennorte, NickGerleman
Differential Revision: D58366246
fbshipit-source-id: 809a1edb79ced4a7920457ed661cc3d863b35c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44879
This sets up publishing of Gradle scans for every build on GHA.
Changelog:
[Internal] [Changed] - Setup publishing of Gradle Scans on GHA
Reviewed By: blakef
Differential Revision: D58419361
fbshipit-source-id: f54365ad259324747248ef0bb726dc64964507f8
Blake Friedman
Riccardo Cipolleschi
Ruslan Lesiutin
Alex Taylor (alta)
Charles Dudley
Richard Howell
Rubén Norte
Moti Zilberman
Vitali Zaidman
Pieter Vanderwerff
Alex Hunt
Sergei Rybalkin
Alfonso Curbelo
Biki-das
Kudo Chien
Nicola Corti
Phillip Pan
Peter Abbondanzo
Jakub Kosmydel
Edmond Chui
Gijs Weterings
Christoph Purrer
Samuel Susla
Pieter De Baets
Fabrizio Cucci