Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38475
We added `scrollEventThrottle` for android in D35735978, but the experiment was never executed and the flag got removed in D39449184.
Since the same feature is on iOS and the implementation here is the same to iOS (https://fburl.com/code/htcuhq4w), it should be safe to support.
Changelog:
[Android][Add] - Add scrollEventThrottle prop support for android
Reviewed By: cortinico
Differential Revision: D47492259
fbshipit-source-id: 09a2bead652bfef4a2c70b996cf66f6983604db2
Summary:
These changes are intended to resolve https://github.com/facebook/react-native/issues/11068.
## Changelog:
[Android] [Fixed] - Fix letters duplication when using autoCapitalize
Pull Request resolved: https://github.com/facebook/react-native/pull/35929
Test Plan:
I took the `RewriteExample` from `TextInputSharedExamples.js` duplicated it, updated the labels, attached to the same screen. Modified its `onChangeText` function, from `text = text.replace(/ /g, '_');` to `text = text.toLowerCase();` then tested via rn-tester as shown in the video:
- No duplicate characters
- Characters are updated to be lowercase
- Long pressing delete properly deletes, doesn’t stop after deleting one character
- Suggestions (selected from keyboard) work and are updated to lowercase when it becomes part of the input text
- Moving the cursor and typing works, cursor position is kept as it should
- Moving the cursor and deleting works
- Selection portion and deleting it works, cursor position is kept as it should
https://user-images.githubusercontent.com/14225329/213890296-2f194e21-2cf9-493f-a516-5e0212ed070e.mp4
Note: I have tested manually with 0.67.4, because later versions failed on my machine with cmake and argument errors when building the rn-tester from Android Studio to any device.
Help regarding that would be appreciated.
## Possible Future Improvements
As it can be seen the video, the letter duplication is resolved, however since the lowercase modification happens on the Javascript side, it takes a couple milliseconds and the Uppercase can still be shown momentarily while typing.
## Technical details, why the solution works
I've debugged a simple AppCompatEditText with calling the same `getText().replace` in `doAfterTextChanged` with a bit of delay and noticed a difference to the `ReactEditText`.
The ReactEditText removes the `android.view.inputmethod.ComposingText` Span in `manageSpans` before calling replace (ComposingText is `Spanned.SPAN_EXCLUSIVE_EXCLUSIVE`).
That `ComposingText` Span is used in `android.view.inputmethod.BaseInputConnection` `private replaceText` to find from what point the text should be replaced from when applying suggestions or typing new letters. Without that Span, it defaults to the selection position, which is usually the end of the text causing duplication of the old "word".
**In simple terms, while typing with suggestions on the keyboard, each new letter is handled similarly as clicking a suggestion would be, aka replacing the current "word" with the new "word". (let's say "Ar" word with "Are" word)**
Another way to describe it:
While typing with suggestions, with the ComposingText Span the TextView keeps track of what word completions are suggested for on the keyboard UI. When receiving a new letter input, it replaces the current "word" with a new "word", and without the Span, it replaces nothing at the end (selection point) with the new word which results in character duplication.
It also seems to make sense then why without suggestions (like password-visible and secureTextEntry) the issue hasn't occurred.
### Examples
How the issue happened:
> - User types: A (ComposingText Span becomes (0,1), composingWord: "A")
> - Javascript replaced A with a, ComposingText Span was removed from getText()
> - User types a new character: r (ComposingText, defaulting to selection, from selection, empty string is replaced with word "Ar")
> => Complete text: aAr => letter duplication.
How it works with the changes applied:
> - User types: A (ComposingText Span becomes (0,1), composingWord: "A")
> - Javascript replaces A with a, (ComposingText Span (0,1) is re-set after replace)
> - User types a new character: r (ComposingText (0,1), "a" word is replaced with word "Ar". ComposingText becomes (0,2) "Ar")
> - Javascript replaced Ar with ar, (ComposingText Span (0,2) is re-set after replace)
> => Complete text: ar => no letter duplication
> - User selects suggestion "Are" (ComposingText Span (0,2) "ar" is replaced with new word and space "Are ")
> - CompleteText: "Are "
> - Javascript replaces "Are " with "are " (ComposingText Span doesn't exist, no string after space " ")
Note: the Editable.replace also removes the ComposingText, if it doesn't cover the whole text, that's why we need to re-setSpan them even if we wouldn't remove them in `manageSpans`.
## Note
This is my first attempt to contribute so if I missed something or messed up, please point out and I will try to adapt.
Reviewed By: NickGerleman
Differential Revision: D47243817
Pulled By: lunaleaps
fbshipit-source-id: 5f3551d17466f2c7cd1aa89ffb09af50e065b52e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38321
This diff adds the native method in `ReactMarker.java` file so that any logs in the android side will call into C++. Given that currently the C++ uses the native implementation from hosting platforms, this allows any call (either from C++ or android) will end up calling the C++ method after logging is done.
The motivation of this change is to allow us to collect timing information from hosting platforms, and report back to JS performance startup API. We will have items that are logged before the JNI part is loaded, and those will be cached and sent over in the next diff.
Changelog:
[Android][Internal] - Implemented native method for Android LogMarker API to report timing values to C++.
Reviewed By: mdvacca
Differential Revision: D43806115
fbshipit-source-id: 11497bdc0af8d1b0299a797c636bb7af7a6ddda4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38356
fix the correct case of this event
Changelog:
[General][Fixed] - fix the correct case of this event
Reviewed By: javache
Differential Revision: D47480741
fbshipit-source-id: a600f4921c59c571f2da251b36674a98c8c7e51f
Summary:
I was getting the following error when trying to run RN Tester on Android.
```
A problem occurred configuring project ':packages:react-native:ReactAndroid'.
> Could not determine the dependencies of task ':react-native-gradle-plugin:compileKotlin'.
> No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific} for MAC_OS on aarch64.
> No locally installed toolchains match and toolchain download repositories have not been configured.
```
This is fixed by adding the `org.gradle.toolchains.foojay-resolver-convention` plugin in settings.gradle, this was done already for the root one, but not in the one in `react-native-gradle-plugin`.
## Changelog:
[INTERNAL] [FIXED] - Add missing toolchains plugin in react-native-gradle-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/38292
Test Plan: Build RN Tester on android
Reviewed By: mdvacca
Differential Revision: D47371772
Pulled By: cortinico
fbshipit-source-id: 8eaa5de9559720a7b37d11b3ddceb5fb84753a40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38357
## Context
On iOS, NSNotificationCenter facilitates event dispatch:
- People can dispatch events **to** objects.
- People can subscribe to events coming **from** objects.
(By specifying objects, NSNotificationCenter also implements event filtering).
The TuboModule system uses NSNotificationCenter to implement module invalidation:
- The bridge dispatches invalidation notifications to its parentBridge object.
- The TurboModuleManager listens to those invalidation notifications from the parentBridge object.
## Problem
In some apps, the TurboModuleManager never invalidates modules.
The bridge dispatches its invalidation notifications to nil: the parentBridge gets deallocated before bridge invalidation finishes.
But, the TurboModuleManager never receives those invalidation notifications: it is listening to invalidation notifications coming from a non-nil parentBridge.
## Fix
Make the TurboModuleManager listen to invalidation notifications from all objects. It will just manually noop invalidation if the notification's bridge object doesn't match its own bridge object. (This is existing logic).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D47485910
fbshipit-source-id: 163403ef01f7d164a0e482f0f770a801d572503b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38349
## Changelog:
[Internal] -
This backs out an earlier commit because we have two separate internal tests' setups that broke as a side effect of it.
In both cases the setup was arguably inconsistent, however the plan is to temporarily revert this nevertheless, fix the tests first and then resubmit.
Reviewed By: javache
Differential Revision: D47469176
fbshipit-source-id: 532253b032b010b037d7b6f6581147f5531f7ee1
Summary:
I noticed that `onMomentumScrollEnd` is called multiple times on Android.
1. It is always called three times with the last value
2. It is sometimes called many times befire the scrolling stops when the pagingEnabled prop is true
See:
<img src="https://user-images.githubusercontent.com/17070498/137640334-301b32a7-3f59-403f-ba7e-a898666aaf3e.png" width="400"/>
I used the following code to get the logs:
```
import React from 'react';
import {SafeAreaView, ScrollView, Text, View} from 'react-native';
const App = () => {
const onMomentumScrollEnd = ({nativeEvent}) => {
console.log(
'onMomentumScrollEnd',
nativeEvent.contentOffset.x,
nativeEvent.contentOffset.y,
);
};
const onMomentumScrollBegin = ({nativeEvent}) => {
console.log(
'onMomentumScrollBegin',
nativeEvent.contentOffset.x,
nativeEvent.contentOffset.y,
);
};
return (
<SafeAreaView>
<ScrollView
horizontal
pagingEnabled
onMomentumScrollEnd={onMomentumScrollEnd}
onMomentumScrollBegin={onMomentumScrollBegin}>
{new Array(10).fill(0).map((_, index) => {
return (
<View
style={{width: 400, height: 400, backgroundColor: 'red'}}
key={index}>
<Text>{index}</Text>
</View>
);
})}
</ScrollView>
</SafeAreaView>
);
};
export default App;
```
From what I understood:
1. We do not check that `mStableFrames` is >= 3 when emitting the event (line 798) and we keep executing the runnable, so it is emitted until `mStableFrames` equals 3. When `mStableFrames` equals 3 we stop executing the runnable (line 809). That's why it gets called 3 times.
2. When `pagingEnabled` is true, the `postOnAnimationDelayed` method is called twice (line 794 and line 806). I believe it causes the runnable to be executing too often, and the `onMomentumScrollEnd` event to be emitted too many times.
I updated the code so:
1. The event is emitted only once, and at the same time we stop executing the runnable
2. The `postOnAnimationDelayed` method is called at most once per execution of the runnable
## Changelog
[Android] [Fixed] - Fix ScrollView's onMomentumScrollEnd being called multiple times on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/32433
Test Plan: I tested using the code above with every combination of `horizontal` and `pagingEnabled` values.
Reviewed By: NickGerleman
Differential Revision: D47297163
Pulled By: ryancat
fbshipit-source-id: 7c31175d941ff13bed20dac03fb92d2b56e94dec
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
This is the native part, where we add a new internal prop named `isInvertedVirtualizedList`, which can in a follow up change be used to achieve the final fix as proposed in https://github.com/facebook/react-native/pull/37913
However as NickGerleman pointed out, its important that we first ship the native change.
## 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
-->
[ANDROID] [ADDED] - Native part of fixing ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38071
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `isInvertedVirtualizedList` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: rozele
Differential Revision: D47062200
Pulled By: NickGerleman
fbshipit-source-id: d20eebeec757d9aaeced8561f53556bbb4a492e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38339
## Changelog:
[Internal] -
In D13050583, the `Platform.isTesting` was unconditionally forced to `false` in `__DEV__` on JS side.
On some platforms, we may want to run tests in the release mode.
This hoists these gatings down to the corresponding platforms' native modules.
Reviewed By: ryancat
Differential Revision: D47438069
fbshipit-source-id: 5bae3df9873f659f65179df93e727108d0062047
Summary:
Bumped Flipper version from `0.182.0` to `0.201.0` (which is currently latest version). New version contain NDK 25, which is necessarily for us since we would like to bump NDK in React Native to 25, see [here](https://github.com/facebook/react-native/pull/37974) for more context.
## Changelog:
[General] [Changed] - Bump Flipper to 0.204.0
Pull Request resolved: https://github.com/facebook/react-native/pull/38260
Test Plan: CI Green ✅
Reviewed By: NickGerleman, mdvacca
Differential Revision: D47373525
Pulled By: cortinico
fbshipit-source-id: d1d5f03cb2f00bc8b9064af986b7c3b6e7ccae3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38319
The TurboModule interop layer's bridge proxy emits logs.
These logs aren't very actionable (yet). (We will make them more useful eventually).
So, this diff adds bridge proxy log-levels (backed by a server-side flag).
Longer term, **all of** React Native's backwards compatibility layers will output logs (not just the bridge proxy). So, we might replace this specific control with something more general.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D47407548
fbshipit-source-id: 2bd79d2a8d52a46d25852a6a23f9cebea0580f9c
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.72.3
Pull Request resolved: https://github.com/facebook/react-native/pull/38312
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D47402979
Pulled By: lunaleaps
fbshipit-source-id: c126ed5af26301a4f21a15a186db9b178d70b2ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38302
X-link: https://github.com/facebook/hermes/pull/1052
Make Runtime a friend of these types so we can use `Runtime::make` with
all of them. Simplify the Hermes API code to do this.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D47373807
fbshipit-source-id: c9530b6c159592e36bb0929badba0542f0c7db78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38301
Changelog: [Internal] - Add dispatchEvent API to EventEmitter that accepts an EventPayload directly
This diff adds a deeper overload of dispatchEvent to EventEmitter which accepts a caller-provided EventPayload subclass, and modifies TouchEventEmitter's dispatchPointerEvent method to use it so that the typed PointerEvent is actually sent through the event pipeline.
Reviewed By: NickGerleman
Differential Revision: D47351851
fbshipit-source-id: a6fdabbfc9b8287c564252f5cc7296fa75044a1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38128
changelog: [internal]
This is debug code that should not have been committed. It is harmless but still should be removed.
Reviewed By: NickGerleman
Differential Revision: D47127817
fbshipit-source-id: 6a13cbf0bf678ef5b7c5e8148e28ce78fba7d6de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38303
X-link: https://github.com/facebook/yoga/pull/1327
This bumps Yoga to C++ 17 for a few reasons:
1. New versions of C++ may introduce behavior changes (e.g. evaluation order) and deprecations. Keeping the version closer to the version of large users helps avoid that.
2. C++ 17 unblocks some new bits I have wanted to use at times, like `std::optional`, `std::variant`, `if constexpr`, `[[nodiscard]]`.
3. There are already changes in C++ 20 that would be directly useful to Yoga, like `std::bit_cast` to avoid `memcpy` style type punning.
There has been some contention around C++ versions before, but by the time the next stable version of Yoga is out, it will have been more than 6 years (~2 C++ versions) since a stable version of Clang/LLVM with C++ 17 support. I would not like to go back further than n-2.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D47383922
fbshipit-source-id: eb95d4853f2168b68d6df5fddb797236eac55870
Summary:
Fixes https://github.com/facebook/react-native/issues/28602
When creating a `RCTFrameUpdate`, ensure it is created with the correct unix timestamp in seconds. This is needed to match the `NSTimeInterval` type defined in the header.
Previously, it was using the `CADisplayLink`'s `timestamp` property, which is not an `NSTimeInterval` but is instead a `CFTimeInterval` (note the different class prefix). This is the host time converted to seconds, which is the number of seconds since the device was turned on and therefore not a unix timestamp as expected.
This was causing issues with the `window.requestIdleCallback` timers as the timer code was expecting this `timestamp` property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. The code does this calculation is here:
https://github.com/facebook/react-native/blob/4d920fe7c991eaec61d229a71df30b0f6c446d38/React/CoreModules/RCTTiming.mm#L262
As one of these is a valid unix timestamp and the other is a much smaller number (number of seconds since device turn on), the `if` statement following this calculation never passes and the callbacks are never called.
This regression seems to have been introduced with this pull request: https://github.com/facebook/react-native/pull/26114
## 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] [Fixed] - Fixed window.requestIdleCallback not firing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29895
Test Plan: I have tested this by patching my React Native code and testing that idle callbacks are correctly called. There is a reproduction case of the issue in the linked issue.
Reviewed By: NickGerleman
Differential Revision: D47381404
Pulled By: sammy-SC
fbshipit-source-id: fd166741889b0084e1def8dedf6e4018adfd570f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38279
Changelog: [Internal] - Make PointerEvent a subclass of EventPayload
This is another refactor diff in preparation of intercepting events in UIManagerBinding to accomplish the Pointer Capture APIs (and more) by making the PointerEvent struct implement EventPayload. Now that this struct will be passed to the event pipeline itself we'll be able to determine in UIManagerBinding that the event is a PointerEvent by dynamic casting and access the event's properties without converting to/from JSI values.
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D47300801
fbshipit-source-id: 4d80378803af0c31dca068ef2b99e34fab426d84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38276
Changelog: [Internal] Refactor Fabric event pipeline to accept typed event payloads
As a first step towards my project of managing the Pointer Capture API by intercepting events in UIManagerBinding I need infrastructure to be able to safely & efficently read the properties of the event payload which is what this diff lays the ground work of addressing.
Currently the events are passed from the EventEmitter all the way to UIManagerBinding with only a ValueFactory (std::function lambda) which is called to produce the jsi::Value. My diff introduces a new virtual base class, EventPayload, which provides the same functionality but in a member function, asJSIValue. To ease the transition to this new paradigm I also introduce the first concrete subclass of EventPayload: ValueFactoryEventPayload — which simply stores and calls a ValueFactory so that we can incrementally migrate to typed events (or frankly, continue to be used for events that we don't *need* to be typed, as the only real use-case in the beginning will be for Pointer Events).
This diff notably does not change any behavior and should behave the exact same way it did before — it is in later diffs where I will begin applying this to the pointer events.
Reviewed By: NickGerleman
Differential Revision: D47299631
fbshipit-source-id: d31d95a5fe09c3404800dd0da0322b198948a851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38295
Move constant to class instance so customers can use strongly typed name, feedback from D46159001
Changelog:
[Internal] [Changed] - Add module name constant to codegen'd class for downstream use
Reviewed By: christophpurrer
Differential Revision: D47095993
fbshipit-source-id: 741d0d837bf912d6b32e5f12c5df871563d46686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38206
This test will ensure that the TurboModule interop layer works in Catalyst.
It will navigate to the sample legacy module screen, and ensure that all methods work.
Steps:
1. Open up Catalyst
2. Navigate to the Legacy Native Module example
3. Click "Run all tests"
4. Validate that all tests match expectations.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D46917689
fbshipit-source-id: 071f9324fa3719648c1a390bde4ba00a4e687e44
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.72.2
Pull Request resolved: https://github.com/facebook/react-native/pull/38286
Test Plan: N/A
Reviewed By: cortinico, GijsWeterings
Differential Revision: D47364735
Pulled By: rshest
fbshipit-source-id: 8c884915aedb13929949a1a8bd72c389aa83d102
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38288
This wasn't compiling since we need to cast to the (unshared) base component type.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D47362923
fbshipit-source-id: 2116c16eb90ee9efbd9d0ec45655220c0f7fed9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38287
Enable automatic (within Meta) sync checks between these duplicated definitions across the RN and Metro repositories, by using a common naming convention.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D47361815
fbshipit-source-id: bb55e5a1c21bf44be9016150a56a9eaa3b33078b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38275
This bumps the version of Fresco to the latest major.
I add to add a couple of changes:
1. Some of the infra has been moved to a different package called `middleware` which I had to add
2. Flipper Fresco plugin has changed ownership, so I had to use the new coordinates.
Changelog:
[Android] [Changed] - Fresco to 3.0.0
Reviewed By: mdvacca
Differential Revision: D47337443
fbshipit-source-id: 1df78e624bcbf0200145fbee5780e2a1697fcb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38233
When call ReactHost.destroy multiple times on same thread, the synchronization we have now can not protect us from concurrent issues such as ```ConcurrentModificationException```, to avoid this case this diff checks if ReactInstance has been reset, if so it means an early destroy has been called and we should not destroy again.
Changelog:
[Android][Changed] - Avoid duplicate destroy on same thread
Reviewed By: fkgozali
Differential Revision: D47276191
fbshipit-source-id: 2291b89cb980ca762abddb835e703abd095a93b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38274
Update oncall field on all of the react native android BUCK files
The goal is to prevent lint warnings
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47338271
fbshipit-source-id: 757a915458a2370dabe122fd3f4936409f8aef95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38255
Remove package comment from JSCExecutor
This class was made public as part of D30346032, seems it's safe for it to be public
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47309285
fbshipit-source-id: 061aeb3a803ded73cad7d45909ab22fe7489c811
Xin Chen
Gergely Hegedus
Juan Luis Herrero Estrada
Nicola Corti
Janic Duplessis
Kevin Gozali
Intl Scheduler
Ruslan Shestopalyuk
AntoineDoubovetzky
Hanno J. Gödecke
szymonrybczak
Nick Gerleman
Ramanpreet Nara
Lorenzo Sciandra
Neil Dhar
Samuel Susla
Fabrizio Cucci
George Zahariev
Vincent Riemer
Sunbreak
Matt Oakes
Christoph Purrer
Roy Berger
zerosrat
Pieter De Baets
Rob Hogan
Pieter De Baets
Tim Yung
Lulu Wu
David Vacca
