[Validation] JavaScript functions can return ElementReference to .NET
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 276
Description
**Scenario contact:** @dariatiurina
## Scenario
**This scenario validates that a reported bug is fixed.** A team is integrating a JavaScript form helper into a Blazor contact form. JavaScript identifies the next field that needs attention and returns its DOM element to .NET. The .NET handler then passes the returned reference to another JavaScript function to highlight that input.
In .NET 10 and earlier, a DOM element returned from JavaScript could not be deserialized into an `ElementReference`, even when Blazor had already captured the element. The call threw:
```
Microsoft.JSInterop.JSException: An exception occurred executing JS interop: __internalId is required.
```
.NET 11 allows JavaScript to return elements that Blazor has captured via `@ref`. This does not extend to arbitrary DOM elements that Blazor has never captured.
## Minimum build
.NET 11 RC1
## Configurations to cover
* Blazor Web App
* [ ] Static SSR
* [x] Interactive Server
* [x] Interactive WebAssembly
* [ ] Interactive Auto
* [x] Standalone WebAssembly
* [ ] Hybrid (MAUI)
The serialization runs in the browser JavaScript and applies to any interactive render mode.
## Also exercise
* [ ] Published output
* [x] An existing .NET 10 app upgraded to .NET 11
* [ ] Trimming or ahead-of-time compilation
* [ ] More than one server instance, or a proxy in front
* [ ] Hot Reload
* [ ] An IDE as well as the command line
* [ ] Container
## What to build
A small contact form with two or three labeled inputs and a "Find next field" button that does not submit the form. Capture each candidate input with `@ref`. A simple selection rule such as choosing the first empty field is enough. A full validation library is not needed.
Put the JavaScript functions in a collocated `.razor.js` module and call them through an imported module reference from the button's .NET event handler, after the inputs have rendered. The selection function should locate an input itself and return it to .NET as an `ElementReference`, without receiving that input as an argument.
Pass the returned reference from .NET to a second JavaScript call that applies a visible outline or background color to the received element. The selection function must not apply the highlight itself: returning the element to .NET and using the returned reference in another call is the feature under test.
## Things to try
* Start with the .NET 10 app and capture the deserialization failure, then upgrade to .NET 11 and repeat with the same component and module.
* Leave different fields empty so JavaScript selects at least two different inputs across interactions. Keep at least one candidate available, and check that each action applies the style to the expected input.
* As an optional boundary check, return a separate input with no `@ref`. This should still fail with `__internalId is required` and is not a .NET 11 regression.
## Expected behavior
JavaScript can select a Blazor-captured input and return it to .NET. The returned reference resolves to that same input when passed back to JavaScript to change its appearance.
### Must hold
* The JavaScript-selected input deserializes to an `ElementReference` without exception, even though that input was not passed to the current call.
* The second interop call applies the style to the selected input, including when changed form values cause a different input to be selected.
* On .NET 10, the same captured-input return fails with `__internalId is required`.
## Evidence to capture
Capture which field each action selected.
## Documentation to use
[Call JavaScript functions from .NET methods](https://learn.microsoft.com/aspnet/core/blazor/javascript-interoperability/call-javascript-from-dotnet)
## What to report
Report results using the format described in the [validation testing manual](https://github.com/dotnet/aspnetcore/issues/68479). Include link to a repository with the test app.
Contributor guide
Assessment
This issue has not been assessed yet.