Razor regression in ASP .NET Core 9.0 (script type=importmap and others)

[AlexBAV]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The following razor snippet renders to nothing (is completely ignored??) in ASP.NET Core 9.0. Used to work correctly in previous version:

<script type="importmap">
	 {
		 "imports": {
		 }
	}
</script>

Looks like a bug in server-side script tag helper.

IMPORTANT! Suggested Workaround:

See below for a suggested workaround.

Expected Behavior

Should render "as is", without modifications

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

9.0.100

Anything else?

No response

[ahazelwood]

I would like to upgrade to 9.0, however this is hitting me on a asp.net core mvc project upgrading from net8.0. Any suggestions for how to get it to render correctly would be greatly appreciated. I concur that it should not override anything but render it as written.

[AlexBAV]

I currently use the following workaround for tag helpers that definitely should not be processed on a server side:

<!script type="importmap">...</!script>

<!tag> syntax is an official way to turn off tag helper processing.

However, I'm still sure that tag helper should not remove a tag if it cannot process it on a server side.

[ahazelwood]

Thanks Alexanderm, that’s a nice addition to know. I hadn’t come across that before. However, this should be fixed as it is an unexpected condition. At the very least, the documentation for importmap should indicate this as a temporary workaround until they are able to fix it. Thanks for the pointer. From: Alexander Bessonov ***@***.***> Sent: Thursday, November 21, 2024 4:20 AM To: dotnet/aspnetcore ***@***.***> Cc: Andre Hazelwood ***@***.***>; Comment ***@***.***> Subject: Re: [dotnet/aspnetcore] Razor regression in ASP .NET Core 9.0 (Issue #58973) I currently use the following workaround for tag helpers that definitely should not be processed on a server side: <!script type="importmap">...</!script> <!tag> syntax is an official way to turn off tag helper processing. However, I'm still sure that tag helper should not remove a tag if it cannot process it on a server side. — Reply to this email directly, view it on GitHub<#58973 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACS73GFMU2IM5ND3H5IIV32BWQTLAVCNFSM6AAAAABR2WEKWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJQGQ3TQMBYHE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[AlexBAV]

BTW, I suggest using this workaround for all "non-default" usages of script tag. It looks like they correctly recognize <script type="text/javascript">, <script type="module"> and <script>. All other usages should be guarded.

We, for example also had to implement a workaround for <script type="application/ld+json"> as it was also removed after upgrade to ASP.NET Core 9.0

[StevePy]

This one caught me as well, a bit sweaty when my importmap (part of _Layout.cshtml) wasn't rendered, considering the relatively good feeling I had combining razor views with ES6 modules. Fortunately the work-around with the <!script type="importmap"> works a treat, but I can't see how that should be an expected breaking change since it's kind of a necessity for module scripts which are recognized. Fortunately a small work-around and pretty much everything else with the switch to .Net 9 has been relatively painless.

[seangwright]

I just spent a lot of time trying to figure out why my perfectly valid <script type="importmap"> element wasn't working and my scripts weren't loading.

It turned out the import map wasn't showing up in my HTML response from ASPNET Core...

When I add the ! to the <script> element it renders but now VS Code has lost any concept of Razor formatting this file with the C# dev kit. 🤦🤦

[seangwright]

Here's the cause of the issue
https://github.com/dotnet/aspnetcore/blob/v9.0.2/src/Mvc/Mvc.TagHelpers/src/ScriptTagHelper.cs#L251

public override void Process(TagHelperContext context, TagHelperOutput output)
{
    ArgumentNullException.ThrowIfNull(context);
    ArgumentNullException.ThrowIfNull(output);

    if (string.Equals(Type, "importmap", StringComparison.OrdinalIgnoreCase))
    {
        // This is an importmap script, we'll write out the import map and
        // stop processing.
        var importMap = ImportMap ?? ViewContext.HttpContext.GetEndpoint()?.Metadata.GetMetadata<ImportMapDefinition>();
        if (importMap == null)
        {
            // No importmap found, nothing to do.
            output.SuppressOutput();
            return;
        }

        // ...
    }

    // ...
}

Because the ScriptTagHelper targets every <script> with a type attribute it will always execute for a <script type="importmap"> element.

Additionally, if you aren't using the import map feature that's part of Razor components then ASP.NET Core assumes the <script type="importmap"> is invalid and suppresses the output!

Hey, guess what ASP.NET Core... you don't get to decide if valid HTML is rendered or not 😠.

It looks like the regression was added in this PR #56045

[marchy]

Nice chase-down @seangwright.

This is definitely a big with the .NET 9 framework. Team please resolve this. We are NOT using the new static asset pipeline and the behaviour of the rendering of our website should not change by upgrading – this is an unintentional regression.

[donnyv]

The worst part about this bug is that this post doesn't come up as a solution when you Google it. A stackoverflow post comes up about using the new asp-importmap="@data". As @seangwright correctly said. Asp.net should not be changing how html elements are rendered or should be rendered. Unless a "asp-*" attribute is added. Can't believe this got by testing. Spent way to long on this issue.

[seangwright]

@AlexBAV could you change the title of this issue to mention "importmap"? It might make it easier for others to find.

[AlexBAV]

@AlexBAV could you change the title of this issue to mention "importmap"? It might make it easier for others to find.

Is it better now?

I've also modified a top-level post with a link to the workaround.