In the Blazor.Browser.JS code, after it inserts a markup block, should run the same logic that it would if it had constructed the DOM attribute-by-attribute. But it doesn't, which means that things like:
<select value=@someValue>
<option value="a">Item 1</option>
<option value="b">Item 2</option>
</select>
... don't pre-populate the dropdown with the correct initial selection if (for example) someValue equals "a".
To fix this, we need to run a pass through the inserted subtree to apply the captured values.
Moving this to the backlog since we haven't heard anyone complain about this yet.
Moving this to the backlog since we haven't heard anyone complain about this yet.
@danroth27 it looks that this bug is an unpleasant surprise for some people: #5625, #6427. Maybe it is worth fixing.
@Andrzej-W Thanks for the heads up!
Please fix this
If this is impacting #9716 we do need this or no binding to select. And I haven't test it yet, but most likely it will impact binding to other complex controls like radio groups and treeviews?
Please make sure this works https://github.com/aspnet/AspNetCore/issues/9694 as part of the fix, as closing the reference as a dupe.
I see this is getting pushed down the road. Is there a workaround for the time being? I attempted to use a standard select with enumerations as per @VR-Architect and it wouldn't work for me. My example code is a part of #9694.
Me to. I have had the same problem. The option value string constants in the razor code don't seem to get recognized unless they refer to a C# variable. For example, if in the C# code you did this:
const string lettera = "a";
const string letterb = "b";
string someValue = letterb;
then in the HTML code you can do this:
<select value=@someValue>
<option value="@lettera">Item 1</option>
<option value="@letterb">Item 2</option>
</select>
That works!
When you replace @lettera and @letterb with the strings "a" and "b", then the value=@someValue stops setting the correct value.
@mkArtakMSFT I moved this to preview 8 because I also have #9716 in preview 8, and it's very likely that these things are part of the same thing. It doesn't really make sense to split them up across milestones.
Please let me know if you disagree with this!
@mkArtakMSFT Since this is already now fixed in master, should we move it the preview 7 milestone so it can show up in the release notes for that?
Is this issue fixed? The select bind element is not working consistently. Sometimes it gets right, but other times it gets the first element.
I'm not able to use select elements at all for CRUD purposes.
Is there any workaround?
Could you post a new issue with repro steps? Thanks.