microsoft
JSException(s) at the circuit startup after upgrading from 4.7.2 to 4.8
Call stack is:
Microsoft.JSInterop.JSException
HResult=0x80131500
Message=element.addEventListener is not a function
TypeError: element.addEventListener is not a function
at Module.RegisterKeyCode (http://localhost:5067/_content/Microsoft.FluentUI.AspNetCore.Components/Components/KeyCode/FluentKeyCode.razor.js:47:17)
at http://localhost:5067/_framework/blazor.web.js:1:3244
at new Promise (
I'm not sure if it is problem with 4.8 or should I add something to FluentUi initialization code.
This is usually a case of the old script being cached to aggressively. Doing a 'hard refresh' should get you going again.
This is usually a case of the old script being cached to aggressively. Doing a 'hard refresh' should get you going again.
I had this issue this morning, Ctrl-F5 worked in local Dev, but not for the azure app service. I had to dig into Edge cache settings and clear all "Cached images and files". Seems ok after that.
From my perspective as a programmer, it is understandable. But from my users' perspective, it is unfortunately unacceptable.
I could explain to them that they have to press Reload once after the new version of my webapp is available.
But for every non-technical user, opening browser settings, finding private settings, and clearing the browser cache is too much.
Wouldn't it be possible to prevent the browser from caching the script between FluentUI versions? So that aggressive or non-aggressive caching doesn't matter.
For example, encoding the library version number in the script's name?
Ctrl F5 worked within the page. However, if I navigate to another page it happens again.
@hevilhuy then your script has not been fully refreshed. It definitely works with the new script.
From my perspective as a programmer, it is understandable. But from my users' perspective, it is unfortunately unacceptable.
I could explain to them that they have to press Reload once after the new version of my webapp is available.
But for every non-technical user, opening browser settings, finding private settings, and clearing the browser cache is too much.
Wouldn't it be possible to prevent the browser from caching the script between FluentUI versions? So that aggressive or non-aggressive caching doesn't matter.
For example, encoding the library version number in the script's name?
Agreed, it's very difficult to explain this process clients most time, 4.8.1 this issue is still there.
This is usually a case of the old script being cached to aggressively. Doing a 'hard refresh' should get you going again.
It seems that the browser caches scripts in a completely standard way. 'Refresh' of the page helps but only if the page actually loads those scripts.
Why wouldn't the page load scripts? Because FluentUi-Blazor has nearly 300 script files and each script is loaded dynamically only when needed.
So the solution would have to involve combining these scripts into one and loading it explicitly in the app.razor file. But the unminified js scripts would be as large as 22MB...
The workaround for today is to create a page containing ALL the used Blazor components, load it in the browser, and then refresh the page
For example, encoding the library version number in the script's name?
The script we create must be named Microsoft.FluentUI.AspNetCore.Components.lib.module.js to have it automatically included by Blazor. Unfortunately, we do not have any option if getting a version number in there. This is being solved in .NET 9. I don't think any solution exists for .NET 8.
Any guidance appreciated!
@MarvinKlein1508 How do you mean? We don not include this script anywhere. Loading it is completely handled by Blazor.
For me, the fix in NET 9 is fine. RC1 will probably appear in two months, and then it can be tested.
@vnbaaij here: https://github.com/microsoft/fluentui-blazor/blob/292c7f4f925a85e486ff0c929e84121d59d9202d/src/Core/DesignTokens/DesignToken.razor.cs#L70
Ah, right. But that is not the 'main' import (which is done by Blazor automatically). This one is just to get to the needed functions from the DesignToken code.
I can try to add a suffix there but I doubt it will have effect for the general case as this will only be called after one of the design tokens is used.
Hi, for me it is unacceptable that in a production environment you have to force all the clients of a web app to do a hard refresh in their browser. This bug prevents me from upgrading from version 4.7.2 to later versions. I'm sorry for the polemical tone, but it seems like a serious problem for those who use fluentui-blazor in a production environment.
It is polemical indeed. No need for that, I think
We re-openend the issue (after the issue-poster closed it!), said we are looking into it and asked our community for help on how to solve this here (because we don't know).
You telling us it is unacceptable is not getting us to a solution sooner. Please keep in mind how this project is set up and how support works (as shown on the homepage of the docs site):
The Microsoft Fluent UI Blazor library is an open-source project. ...
The library is not an official part of ASP.NET Core. This means the packages are not officially supported and we are not committed to shipping updates as part of any official .NET updates. It is built and maintained by Microsoft employees (and external contributors) and offers support, like most other open-source projects, on a best effort base through the GitHub repository only. No support is offered through any of Microsoft's official support channels.
Hi Vincent, I'm sorry again if the tone of my comment was too polemical. It is very clear to me that the Fluentui-Blazor project is an open source project. I use it profitably and I can only thank you for the excellent work done. It was the frustration of not being able to keep my application updated that made me write "unacceptable", since I am unable to provide a solution. I apologize again if the comment seemed inappropriate and I am willing to remove it.
Hi Francesco, thanks for getting back. No need to remove things. I'm a strong believer in transparency and we do not need to hide stuff. My response was coming out of frustration a bit as well. We're all only human. 😑.
I would really like to find a solution for the issue but as said, I don't have one. It is not like we can stop updating the script occasionally but I can't think of a way to force an automatic refresh. Community help is needed and appreciated.
Hi @vnbaaij
in our productive app I'm using a workaround to get around on this.
public class ClearSiteDataMiddleware
{
private readonly RequestDelegate _next;
public ClearSiteDataMiddleware(RequestDelegate next)
{
_next = next;
}
public async Task InvokeAsync(HttpContext context)
{
// Add the Clear-Site-Data header to the response
context.Response.OnStarting(() =>
{
//context.Response.Headers.Append("Clear-Site-Data", "\"cache\", \"storage\"");
context.Response.Headers.Append("Clear-Site-Data", "\"cache\"");
return Task.CompletedTask;
});
// Call the next middleware in the pipeline
await _next(context);
}
}
This middleware will force the cache to be removed. The only downside is that this will happen on every request. Perhaps you can implement this with checking localStorage first. No entry = no refresh. Entry found and version != current version force refresh.
Why don't you pull the packages with this issue? For us this broke our Blazor website 😢
@MarvinKlein1508 thanks, I've added this workaround as a temporary solution!
Why don't you pull the packages with this issue? For us this broke our Blazor website 😢
Or you could just roll your packages back to 3.7.x
Why don't you pull the packages with this issue? For us this broke our Blazor website 😢
Because technically there is nothing wrong with the packages.
This will be a returning thing is we need to make changes in the included script. There's will be an out of box solution in .NET 9
This new feature will solve some of these problems: #2388
After PR approval, you can use the Preview Feed to validate that: https://github.com/microsoft/fluentui-blazor/blob/dev/docs/using-latest-daily.md
Version 4.9.2 containing the fix to include assembly version in the script links has been released and is available on NuGet now.