SupplyParameterFromForm doesn't work when there's a referenced class with an abstract member

[neoGeneva]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a form that's [SupplyParameterFromForm] to bind a class. That class has a property that references another class which is abstract and has abstract members.

When attempting to submit the form the class is not bound, no validation errors are shown, and no exception is thrown. Using the debugger I discovered an error value deep in the EditContext: No method 'PushPrefix' on type 'Microsoft.AspNetCore.Components.Endpoints.FormMapping.FormDataReader' is compatible with the supplied arguments.

I can use [IgnoreDataMember] on the property to work around the issue for myself, though it was quite a pain figuring out what the issue even was.

Ideally when an exception is thrown internally then there should be more visibility to it, either a runtime error or something in the validation messages. Also, it would be good to have a specific error for this case letting people know they can't bind to class with abstract members.

Expected Behavior

The form should be bound or an exception should be thrown

Steps To Reproduce

Example repo is here: https://github.com/neoGeneva/BlazorBindingIssue

If you run the project and submit the form it'll show you the error which I've used reflection to dig out, there might be a better way to get the issue but I'm new to Blazor and couldn't find one.

If you update BindingModel.cs to remove the reference to AbstractModel then rerun the project the there error is gone and the form binds correctly.

Exceptions (if any)

No response

.NET Version

10.0.100

Anything else?

No response

[javiercn]

@neoGeneva thanks for contacting us.

This behavior is by design. model binding in Blazor doesn't support polymorphism, all types on the graph must be concrete and constructible (with the exception of some well-known bindings for collections).

When the form data mapper encounters an abstract type like AbstractModel, it cannot instantiate it because:

1. Abstract classes cannot be directly instantiated
2. Form data doesn't contain type discriminator information to determine which concrete derived type to create

Using [IgnoreDataMember] on the property is the correct approach if you don't want to bind to it. If you do want to bind to it then you need to have a concrete type you can use. We don't currently have extensibility around model binding to support this.

I've filed #65137 to track a review of the error case scenarios to make sure the errors surface appropriately.

I suspect they don't surface unless you have a validation summary on the form.

[neoGeneva]

@javiercn Sweet, thanks. I agree, having an error is the way to go. From my testing it doesn't show when <ValidationSummary /> is used. Also, binding for the model fails entirely. Ideally, it'd just be the nested object that doesn't bind and not the entire root object.

[javiercn]

@neoGeneva thanks for the details.

We will use the other issue to track changes/improvements in this area.

[neoGeneva]

All good, thanks @javiercn. I logged another issue, #65010, which is also related to error visibility on model binding failures, and might need to be rolled into #65137 too.