To expand on some of what Stephane is saying and maybe give some perspective on issues with the current approach... this upgrade introduced some bugs, which happens, this maybe being one of the more critical ones (without any warnings or errors, all forms are now broken and won't submit). I appreciate the openness, quick action, and suggestions on how to work around it. However, the official fix won't be available until the next update. Putting the several months of waiting and temporary workarounds aside, this also means that in order to receive the fix for this one specific bug, we must also install the next update. Since updates typically come with at least some bugs (some more critical than others), we essentially have to accept the risk of additional bugs as the "price we pay" to get the current bug fixed. We cannot fix current known bugs without opening ourselves up to the risk of additional new unknown bugs.

Going back to what Thomas was asking about, something like a simple hotfix in the meantime would solve these issues. We wouldn't have to wait a couple months for the next update and we wouldn't be forced to take on the risk of potential new bugs associated with installing the next new full update. I also understand that this update included some pretty major changes, but this is not specific to this particular update. This is not the first time I've found myself waiting for the next update to be released so I can get a fix I've been waiting for.

I agree with Thomas, the problem here is the general quality. At each release, there are some new few bugs like this one. It seems that there is a lack of tests.
And bug fixing should be much faster. We can't wait two months before a bug is fixed. The bug is marked as Completed but we can't access the correction, it is not logical.
Often, waiting the correction, the response is "there is a workaround". I hate this kind of response, we can't update all our code at each bug (and we will have to come back to it later).
To improve this, the bugs should be fixed very quickly and a prerelease version should be generated immediatly.

I have three main questions.

 

1. How does something like this happen as a regression?  What steps are being taken to ensure something like this doesn't happen again?  I realize as well as anyone regressions happen, but something as simple as a submit button not working causes serious concern.
2. When a critical regression is found, why isn't it added to the release notes?? https://www.telerik.com/support/whats-new/aspnet-core-ui/release-history/ui-for-asp-net-core-r1-2022(-version-2022-1-119) instead we are left to hunt down the regressions 
3. Can this be released as a hotfix for 2022?

If you use tag helpers, another workaround can be to add a custom button tag helper like this :

```csharp

[HtmlTargetElement("kendo-button")]
public class SubmitButtonFixTagHelper : ButtonTagHelper
{
    public SubmitButtonFixTagHelper(IKendoHtmlGenerator generator) : base(generator)
    {
    }

    public string Type { get; set; }

    public override int Order => 1;

    protected override Dictionary<string, object> SerializeSettings()
    {
        var settings = base.SerializeSettings();
        if (Type != null)
        {
            settings["type"] = Type;
        }
        return settings;
    }
}

```

I, too, ran into this problem Friday last week (figured out the cause after troubleshooting, came here today to report it but saw it had already been reported).

 

FWIW, I looked at the source and found ButtonTagHelper's WriteHtml() method has the following line of code:

htmlAttributes.Add("type", "button");

 

I looked at the Button class (to compare the Tag Helper code above to the HTML Helper code) and found it does not contain the same line of code.