Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WASM] Issues with callback parameters marshaling #101637

Closed
maxkatz6 opened this issue Apr 27, 2024 · 0 comments · Fixed by #101638
Closed

[WASM] Issues with callback parameters marshaling #101637

maxkatz6 opened this issue Apr 27, 2024 · 0 comments · Fixed by #101638

Comments

@maxkatz6
Copy link
Contributor

Description

That's a simple bug, which I will send a PR for. Not sure if this issue is really necessary but creating just in case.

After trying out .NET 9 preview and nightly builds with Avalonia we have found an issue with some of our JSImport interop methods.
Specifically, this one was acting weird, raising an error "Value is not an integer" each time when third callback parameter had a decimal point.

Additionally, if you change other two argument types to double, it will work as expected.

Reproduction Steps

JS method:

export function jsFunc(callback) {
    callback(10, 20, 15.5);
}

.NET mapping:

[JSImport("jsFunc", "moduleName")]
public static partial void JsFunc(
    [JSMarshalAs<JSType.Function<JSType.Number, JSType.Number, JSType.Number>>]
    Action<int, int, double> callback);

After that it's enough to call this method, for example:

JsFunc((a, b, c) => Console.WriteLine($"{a} {b} {c}"))

Expected behavior

Callback parameters should be converted independently from each other. Changing type of second parameter should not affect how third parameter is converter.

Actual behavior

Third parameter is casted to the type of second parameter.

Regression?

Yes, it's a regression compared to .NET 8.

Known Workarounds

Adjust JSImport definition to expect second and third callback parameters to be of the same type.

Configuration

No response

Other information

No response

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Apr 27, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Apr 27, 2024
@jkotas jkotas added arch-wasm WebAssembly architecture area-Interop-mono area-System.Runtime.InteropServices.JavaScript and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners area-Interop-mono labels Apr 27, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Apr 27, 2024
@github-actions github-actions bot locked and limited conversation to collaborators May 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants