Chrome Mobile 91 may result in WebAssembly load error

[rodriguezrm]

Solution is working OK on Desktop / Chrome

Solution is working OK on Android / Edge, Firefox, Opera and Samsung Internet

Tested and able to reproduced on two different Samsung devices, Galaxy 6 and Galaxy Notes 20 using Chrome

Note: Page was working ok on same devices previous last chrome update.

Page is crashing "RELOAD" message, ONLY on Android Chrome Version: 91.0.4472.101

Solution environment

Project Sdk="Microsoft.NET.Sdk.Web"

PropertyGroup
TargetFramework>netstandard2.1</TargetFramework
RazorLangVersion>3.0</RazorLangVersion
Nullable>enable</Nullable
/PropertyGroup

ItemGroup
PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="3.2.1" /
PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Build" Version="3.2.1" PrivateAssets="all" /
PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="3.2.1" PrivateAssets="all" /
PackageReference Include="Microsoft.AspNetCore.Http.Extensions" Version="2.2.0" /
PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="3.1.7" /
PackageReference Include="Microsoft.AspNetCore.SignalR.Protocols.MessagePack" Version="3.1.7" /
PackageReference Include="Microsoft.AspNetCore.WebUtilities" Version="2.2.0" /
PackageReference Include="System.Net.Http.Json" Version="3.2.1" /
ItemGroup

Error

dotnet.3.2.0.js:1 Stacktrace:

dotnet.3.2.0.js:1 Error
at 640908 (dotnet.3.2.0.js:1)
at _emscripten_asm_const_iii (dotnet.3.2.0.js:1)
at wasm_logger (:wasm-function[3126]:0x9ab09)
at eglib_log_adapter (:wasm-function[6030]:0x10e78d)
at monoeg_g_logstr (:wasm-function[4574]:0xc99e6)
at monoeg_g_logv_nofree (:wasm-function[2192]:0x60c59)
at monoeg_g_log (:wasm-function[132]:0x2ffc)
at g_error_xsx (:wasm-function[5875]:0x103f51)
at interp_exec_method (:wasm-function[1120]:0x2d3e7)
at interp_runtime_invoke (:wasm-function[5655]:0xf7391)
blazor.webassembly.js:1 Unimplemented opcode: 0303 d.vt at 0x0
f.printErr @ blazor.webassembly.js:1
blazor.webassembly.js:1
f.printErr @ blazor.webassembly.js:1
blazor.webassembly.js:1 undefined
blazor.webassembly.js:1 undefined
f.printErr @ blazor.webassembly.js:1
dotnet.3.2.0.js:1 Uncaught (in promise) RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.
at abort (dotnet.3.2.0.js:1)
at _abort (dotnet.3.2.0.js:1)
at wasm_logger (:wasm-function[3126]:0x9ab2b)
at eglib_log_adapter (:wasm-function[6030]:0x10e78d)
at monoeg_g_logstr (:wasm-function[4574]:0xc99e6)
at monoeg_g_logv_nofree (:wasm-function[2192]:0x60c59)
at monoeg_g_log (:wasm-function[132]:0x2ffc)
at g_error_xsx (:wasm-function[5875]:0x103f51)
at interp_exec_method (:wasm-function[1120]:0x2d3e7)
at interp_runtime_invoke (:wasm-function[5655]:0xf7391)

[javiercn]

@rodriguezrm thanks for contacting us.

In order for us to reproduce this issue we would need a minimal repro project as a publicly accessible github repository as well as detailed steps on how to reproduce the issue.

[rodriguezrm]

thanks @javiercn doing that. I'll let you know when done

[rodriguezrm]

Hi there

@javiercn fyi

I created a new project from scratch using blazor templated from VS 2019.

https://github.com/rodriguezrm/HelloBlazorWorld

I was able to reproduce the error. Same error.

In order to reproduce it

• Using Samsung device (like Galaxy Note20)
• Update chrome to version 91.0.4472.101
• Navigate https:///HelloBlazorWorld/

While loading the page you will get below error.

dotnet.3.2.0.js:1 Error
at 640908 (dotnet.3.2.0.js:1)
at _emscripten_asm_const_iii (dotnet.3.2.0.js:1)
at wasm_logger (:wasm-function[3126]:0x9ab09)
at eglib_log_adapter (:wasm-function[6030]:0x10e78d)
at monoeg_g_logstr (:wasm-function[4574]:0xc99e6)
at monoeg_g_logv_nofree (:wasm-function[2192]:0x60c59)
at monoeg_g_log (:wasm-function[132]:0x2ffc)
at g_error_xsx (:wasm-function[5875]:0x103f51)
at interp_exec_method (:wasm-function[1120]:0x2d3e7)
at interp_runtime_invoke (:wasm-function[5655]:0xf7391)
blazor.webassembly.js:1 Unimplemented opcode: 0303 d.vt at 0x0
f.printErr @ blazor.webassembly.js:1
blazor.webassembly.js:1
f.printErr @ blazor.webassembly.js:1
blazor.webassembly.js:1 undefined
blazor.webassembly.js:1 undefined
f.printErr @ blazor.webassembly.js:1
dotnet.3.2.0.js:1 Uncaught (in promise) RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.
at abort (dotnet.3.2.0.js:1)
at _abort (dotnet.3.2.0.js:1)
at wasm_logger (:wasm-function[3126]:0x9ab2b)
at eglib_log_adapter (:wasm-function[6030]:0x10e78d)
at monoeg_g_logstr (:wasm-function[4574]:0xc99e6)
at monoeg_g_logv_nofree (:wasm-function[2192]:0x60c59)
at monoeg_g_log (:wasm-function[132]:0x2ffc)
at g_error_xsx (:wasm-function[5875]:0x103f51)
at interp_exec_method (:wasm-function[1120]:0x2d3e7)
at interp_runtime_invoke (:wasm-function[5655]:0xf7391)

[aarrtturas]

Yes this is very big problem. On mobile google chrome 91... version. Working app is not working any more on this browser. It simply is not loading. On other browsers it performs well. But it looks like it is not only related with chrome 91.. for android, but for desktop chrome 91... as well. I tried creating from blank template BLAZOR wasm 5.0.7 from Visual studio and first time you run in in desktom google chrome 91... it loads only in 30 seconds or more. All next times it loads in 3 s. So what browser is dooing 27 s or more? After cleaning google chrome history - again loads in 30 seconds or more. This is very bad situation. Can any one imagine web page in production with 30 s first load time !!! What is going on actually? Now we have BLAZOR wasm with different load times or not working any more depending on browser from 3 s - 30 s or more.

[srpeirce]

@javiercn I had this exact issue reported to us today on Chrome 91 Android. This seems to be affecting ALL Blazor WASM sites regardless of version that I have tested.

https://powered4.tv

[srpeirce]

It worked perfectly on Android Chrome 90, then errors as soon as I installed the update for 91. [91.0.4472.101].

Reproduced on Android 9, Android 10, and Android 11

[srpeirce]

Confirmed it works in Latest Android Edge [46.04.4.5157]

[javiercn]

@rodriguezrm just noticed that you are using version 3.2.1 of the wasm assemblies which is out of support (the only currently supported version is 5.0)

[javiercn]

For all folks affected here, does this repro for you on 5.0 and an out of the box template?

[SteveSandersonMS]

Ping @lewing, @danroth27 - looks like we'll need to prioritise this. Based on the error message, do you think Samsung Chrome 91 might have changed the max stack size or something?

[srpeirce]

@Bigtalljosh Just experiment.
[I maybe embelished from the sites I was looking at before].

Vanilla net5.0 wasm project works
Vanilla net6.0 preview 4 project works

Example of a 3.1 functions. Client is a standard 2.1 library wasm that does not work [non-vanilla]: https://strifesolutions.com/

[Bigtalljosh]

Tried to test with Preview 5 with the same vanilla blazor wasm VS template app but
Between
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Server" Version="6.0.0-preview.4.21253.5" />
And
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Server" Version="6.0.0-preview.5.21301.17" />
Something breaks resulting in

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1] An unhandled exception has occurred while executing the request. System.MissingMethodException: Method not found: 'Microsoft.Extensions.Primitives.StringValues Microsoft.AspNetCore.Http.IHeaderDictionary.get_AcceptEncoding()'. at Microsoft.AspNetCore.Components.WebAssembly.Server.ContentEncodingNegotiator.NegotiateEncoding(HttpContext context) at Microsoft.AspNetCore.Components.WebAssembly.Server.ContentEncodingNegotiator.InvokeAsync(HttpContext context) in Microsoft.AspNetCore.Components.WebAssembly.Server.dll:token 0x600000c+0x0 at Microsoft.AspNetCore.Builder.ComponentsWebAssemblyApplicationBuilderExtensions.<>c__DisplayClass0_0.<b__2>d.MoveNext() in Microsoft.AspNetCore.Components.WebAssembly.Server.dll:token 0x6000057+0x80 --- End of stack trace from previous location --- at Microsoft.AspNetCore.Builder.Extensions.MapWhenMiddleware.Invoke(HttpContext context) in Microsoft.AspNetCore.Http.Abstractions.dll:token 0x6000084+0xa7 at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.Invoke(HttpContext context) in Microsoft.AspNetCore.Http.Abstractions.dll:token 0x600007b+0x1ec at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context) in Microsoft.AspNetCore.Diagnostics.dll:token 0x60000aa+0x82

[SteveSandersonMS]

@Bigtalljosh That's definitely unrelated. Your error is coming from server-side code. If you think this is a bug could you please file it separately? However be sure you're creating your project normally from the project template using an up-to-date SDK, rather than changing any package references after it was created.

[Bigtalljosh]

Yeah sorry I should've been clear, I only mention so you know why we haven't tested preview 5 yet 😅

[aarrtturas]

NET 5 5.0.7 blazor wasm VS out of the box template. Works on android 11 google chrome 91...
But I have the same NET 5 5.0.7 wasm project and it does not work on android 11 google chrome 91... it works in other browsers. And older android google chrome. I downloaded google chrome beta 92... and project works as well.
Android USB debug mode with google chrome - gives nothing. Just no errors, it looks like it just waits for something.
But out of the box template on desktop google chrome 91... first time loads in only 30 s. or more, and next times it loads in 3 s. After cleaning history it loads in 30 s. again.

[SteveSandersonMS]

More info:

• I installed Chrome 91.0.4472.101 into the Android Emulator (PC) and the issue doesn't appear to repro. I was able to load and use https://powered4.tv without issue.
• According to this comment and this comment, default out-of-box new projects of all versions seem to work fine on any browser.

So the issue seems specific to a combination of:

• Something that is being done in particular applications
• ... on Chrome 91 specifically (not 90 or 92)
• ... on particular hardware, since it doesn't repro in Chrome 91 when emulated

For people who have a working repro of this issue, are you able to break it down to determine what specifically you're doing differently from the default project template that triggers the issue? If you can find a minimal change that introduces the problem, we'll be in a much better position to know if it's something fixable in the framework vs an application bug (related to a specific browser) or something else.

[aarrtturas]

Not sure but first idea was relation with installed packages like in this description of issue Megabit/Blazorise#2448

[rodriguezrm]

@SteveSandersonMS I'm also getting the same error using https://powered4.tv

Using Galaxy 6 and GalaxyNote20 and Chrome Version 91.0.4472.101

Maybe you cannot reproduce it because emulator...idk

[srpeirce]

@SteveSandersonMS I checked and you can re-create the issue using BrowserStack - I had to login to the app store to update Chrome to latest. We haven't made any changes to Powered4.tv yet so can still see the issue.

I just deleted half the code and deployed to our test environment and reached a point where the app is working. I am AFK for a few hours but will try and isolate the problem and produce a minimal change that introduces the problem later tonight.

[srpeirce]

I have struggled to create a minimum example as I see lots of weird behaviour. I have been trying to use my Galaxy Note 8.

The Problem

I have been moving dependency by dependency to try and isolate the problem.

• I would remove 1 dependency and the error would go away but performance would be appalling (e.g. literally multiple minutes for site to initialise).
• I would then put that feature back and confirm the error had returned.
• I would then remove something random like a the pages that aren't being used, and the error would go away but move to horrendous performance [Noting - I had left the previous dependency in-place.

I started the other way with a new project and then adding some features but have not yet caused the problem.

I became worried that there is something weird with the phone I'm testing on so I have paid for BrowserStack. I discovered something interesting.

First Load - Works with latest Android. Never Again [Galaxy S21]

• Login to BrowserStack
• Choose any Android phone (Galaxy S21)
• Login to PlayStore
• Search Chrome, and Update
• Check the version

• Navigate to Powered4.tv

• Everything works - it is pre-rendered but we can tell as the cookie banner. Also, we only pre render the top sliders - Tru Heel Heat Wrestling onwards is loaded on app start [Excuse the styling for hamburger menu - we need to fix that :/]
  

• Refresh - The page, and now errors
  

• I tried clearing all site data inside Chrome, but it still errored.

• Removing all data via the App Info in Android seems to resolve the issue
  

• It works first load, until a refresh and then does not work again
  

First Load - Galaxy S10

• Login to BrowserStack
• Choose any Android phone (Galaxy S10)
• Login to PlayStore
• Search Chrome, and Update
• Check the version

• Navigate to Powered4.tv - it errors. I tried clearing app storage to confirm, and again, it errors.
  

This is the same behaviour as my Galaxy Note 8 that I have

=======

I can try again later. Happy to hop on a call if that would be helpful. This isn't a fun bug hah 🤣

[SteveSandersonMS]

Thanks for all the extra info, @srpeirce. I appreciate that diagnosing this is a very tedious process. I'm setting up some conversations with the runtime team internally to figure out what we can do.

In the meantime, the more info you can find, the better. It's unclear whether the "bad initialization perf" and the "error" cases are two separate problems, or two manifestations of the same problem. Does the "bad initialization perf" issue reduce in severity with the more features you remove? Or is there some single underlying thing that makes the difference between "starts fast like normal" vs "takes several minutes"? It might be possible to use a binary-search-like debugging strategy (e.g., remove half of the pages, then another half, then half of the features from the remaining page, etc). Alternatively start with the default project and add half of your production app dependencies, then another other half, etc. Again, I know that's super time-consuming. If you did end up with a minimal repro of the slow-startup case, we'd definitely want to see the code for debugging.

BTW are you also able to repro the issue being solved with Chrome 92 Beta? If it is some defect that Chrome introduced in 91 that was immediately fixed in 92, it might be that it's truly a browser issue, and maybe the Chromium team might be convinced to backport the 92 fix to the 91.x release.

[SteveSandersonMS]

Example of a 3.1 functions. Client is a standard 2.1 library wasm that does not work [non-vanilla]: https://strifesolutions.com/

To clarify, are you saying that also https://strifesolutions.com/ reproduces the problem? If so that's really interesting because it looks like a far more minimal site and would give us a much better chance of diagnosis. Is it your site? If so, is there any chance you'd be willing to give us access to the source code for it so we can investigate?

[Bigtalljosh]

Hi @SteveSandersonMS, StrifeSolutions is one of mine, happy to give you access. I was able to reproduce using a Pixel 3 on Browserstack on both Powered4.tv and strifesolutions.com.

Will add you as collaborator in a moment

[Bigtalljosh]

Apologies should've mentioned. You should have access now. Please let me know if you still don't. StrifeSolutionsLtd

[SteveSandersonMS]

Thanks @jberlyn. I'm guessing the answer will be no, but did you by any chance change something in your production site (https://lkc.berlyn.me/) to fix the issue? Because I can no longer repro it. There did seem to be a problem yesterday (in that the "loading" screen kept spinning indefinitely, although there was no error message, so maybe that wasn't the same issue), but today:

• I tried Galaxy S21 and Pixel 5 devices, both with Chrome 91.0.4472.101
• I tried under the default config (tiering enabled), then with the flags set to force TurboFan on, and then set to force TurboFan off (clearing all cache data in between each trial)

... and under every combination, the site loaded and worked correctly.

Once again I don't know if this means Chrome has somehow fixed this, despite the version number not changing (maybe they are A/B testing something?), or if it means the issue just rarely happens, but when it does happen the bad state gets cached on a device so to those people it looks like it happens consistently.

[Mauricio-Ghetler]

Yesterday was published a new version of Chrome 91 for Android (was 91.0.4472.101 and now is 91.0.4472.120) see https://chromereleases.googleblog.com/2021/ but from what I understood it will only be available in the coming weeks , the date is vague. I suggest we try to perform next tests in this new version asap.

[PatrizioR]

@m

a new version of Chrome 91 for Android (was 91.0.4472.101 and now is 91.0.4472.120)

Sadly same problem with various blazor apps

Android 91.0.4472.101 and 91.0.4472.120 same problem.

Here is an app:
PasswordHashGeneratorBlazor 5.0.1

I will try to change to dotnet 6 preview 5 and let you know. I remember this problem occured with chrome already like one year ago didn't it?

[Mauricio-Ghetler]

@Patrizio I don't remember another version of Chrome for Android that had such a serious issue with Wasm Apps, maybe some of the other colleagues in this thread can remember. Anyway, thanks for the information about version 91...120, which has the same problem. Good luck with .Net6 Preview5!

[srpeirce]

@PatrizioR - If straight upgrade to ne6 preview 5 doesn't work, try relinking the runtime: https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-5/#reduced-blazor-webassembly-download-size-with-runtime-relinking

This worked for me!

[jberlyn]

@SteveSandersonMS There had been two commits to master that were deployed to production. Nothing that adjusted the framework versions. I did however add PWA support, so maybe the service worker fetched the new state and caused the app to not be broken anymore?

Commits (only yourself and @danroth27 should be able to see these):
https://github.com/jberlyn/legendary-kingdoms-companion/commit/ac38e77c154c1c9b4004b5e8759784f1ba9203ed
https://github.com/jberlyn/legendary-kingdoms-companion/commit/c65f11f14b046671cad65b1cb62d7847194a05fe

[PatrizioR]

@Patrizio Good luck with .Net6 Preview5!

Hello Mauricio, upgrade to dotnet 6 preview 5 worked. Needed to clear browser cache/space for that website (again, already did that many times before the upgrade, when I still had no clue what the cause was) and reload the website.

Thanks again for your help.

Anyway I wonder how people with a productive app will handle that problem (hard to tell customers to clear cache and delete space also don't know what will happen to locale storage/index db stuff then.

Good luck to all others, I will now slowly update all my apps to dotnet 6 preview 5 and see how things are going

[Mauricio-Ghetler]

@Patrizio This is certainly good news! It's unfortunate that we don't have an alternative with .Net 5 yet but I've never been against upgrading versions, even though .Net 6 preview 5 is beta.
I'm in the MVP phase on a project focused on real estate, which is obviously Mobile First, and I need to move to the next phase.
In Brazil (the first geography we will focus on) more than 90% of the population uses Android and of these, almost 100% uses Chrome, that is, I don't have many options... I'll wait until the end of this week for some magic solution in .Net 5 but if it doesn't come, I'll try the upgrade as it worked for you.
Thank you so much for sharing this positive information!

[Mauricio-Ghetler]

Good morning everybody. My App has also been implemented if bugs in .Net6 Preview 5, it fixes Loading bug in Chrome91. Good luck to everyone!

[cyberdarius]

Chrome Mobile 91.0.4472.101 on all tests. Updated to .NET6 preview5

Phisical Device (Pixel 2 XL)
.Net 6 - Preview 5: No error, No console data (clear). but page is frozen. Left it for X mins keeping browser tab active and did not do anything.

.NET 6 - Preview 5 with linking (dotnet workload install microsoft-net-sdk-blazorwebassembly-aot before publish) - No error, No console data (clear). but page is frozen. Left it for X mins keeping browser tab active and did not do anything.

.NET 6 - Preview 5 with linking (dotnet workload install microsoft-net-sdk-blazorwebassembly-aot before publish) + Assembly trimming checked. - App does not start, but errors are cacthed:

Streaming compilation failed. Falling back to ArrayBuffer instantiation. RangeError: WebAssembly.instantiate(): Out of memory: wasm memory
blazor.webassembly.js:1 TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
at blazor.webassembly.js:1
at async blazor.webassembly.js:1
at async blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
at blazor.webassembly.js:1
at async blazor.webassembly.js:1
at async blazor.webassembly.js:1

---

.NET 6 - Preview 5 with linking and assembly trimming and true to client Csproj - same as above.

Even with:
<script src="_framework/blazor.webassembly.js"></script>
<script type="text/javascript">WebAssembly.instantiateStreaming = undefined;</script>

it doesn't work

With chrome mobile beta (future 92) and other browser works as expected.

With chome 91 AND suggested feature flags it works as expected in all cases.
chrome://flags/#enable-webassembly-baseline
chrome://flags/#disable-webassembly-tiering

[tesar-tech]

So there is no solution for .net 5 and .net 6? Does somebody know the release date for chrome 92?

[ScottyLightnin]

I can confirm that the pain of updating to .net 6 preview also did not resolve the issue for me. To be honest, this seems like a pretty serious problem, given Chrome Mobile 91's extensive reach.
Microsoft, are you sure you're giving this enough attention?
https://www.virtualbikerace.com is our production app that won't consistently load in Chrome Mobile 91, which given that we're in the middle of the Tour de France, is really lousy timing.

[jeffputz]

If Google follows their usual cadence, 92 will likely be out in another week or two. To be clear, Blazor is not broken... WASM in a general sense is broken on Chrome. If you haven't commented on the Chromium bug, you should.

[ScottyLightnin]

If Google follows their usual cadence, 92 will likely be out in another week or two. To be clear, Blazor is not broken... WASM in a general sense is broken on Chrome. If you haven't commented on the Chromium bug, you should.

Happy to do so, do you have a link handy? I did not see it referenced in this thread..

[jeffputz]

https://bugs.chromium.org/p/chromium/issues/detail?id=1214508

[andreimilto]

I'm experiencing a very similar problem on the latest version of Opera for Android, so this browser might be affected as well.

[andreimilto]

Disabling invariant globalization solved the problem for my website.

I had invariant globalization enabled in the .csproj in order to reduce the download size, as the documentation suggests:

<PropertyGroup>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

The website didn't load correctly in the current stable versions of Chrome and Opera for Android. Most times it would get stuck during loading without any error, after a few refresh attempts it would sometimes load ok and then after another refresh get stuck again. At the same time it worked fine in Firefox for Android and in desktop browsers.
After commenting out the above-mentioned code fragment and redeploying the site, it now loads without any issue in Chrome and Opera for Android as well other browsers.

Here's a minimal reproducible example:

1. Create a new Blazor WASM project targeting .NET 5.0 from the standard template: https://github.com/andreimilto/GlobalizationBreaksBlazor/tree/main/src
2. Set InvariantGlobalization to true in the project file.
3. Publish to folder (settings: release, net5.0, self-contained, browser-wasm, trim unused assemblies, delete all existing files prior to publish): https://github.com/andreimilto/GlobalizationBreaksBlazor/tree/main/deploy
4. Deploy to server: https://globalizationbreaksblazor.pages.dev/
5. Open the deployed website in a browser:
   ❌ Chrome for Android (version 91.0.4472.120) gets stuck on loading, displays error pop-up at the bottom
   ❌ Opera for Android (version 64.1.3282.59829) gets stuck on loading, displays error pop-up at the bottom
   ✔️ Firefox for Android loads ok
   ✔️ Firefox for Windows loads ok
   ✔️ Chrome for Windows loads ok
   ✔️ Edge for Windows loads ok
   ✔️ Opera for Windows loads ok
6. Disable invariant globalization, republish and redeploy: https://fix.globalizationbreaksblazor.pages.dev/
7. Open the deployed website in a browser:
   ✔️ Chrome for Android loads ok
   ✔️ Opera for Android loads ok
   ✔️ Firefox for Android loads ok
   ✔️ Firefox for Windows loads ok
   ✔️ Chrome for Windows loads ok
   ✔️ Edge for Windows loads ok
   ✔️ Opera for Windows loads ok

In case of my website the problem demonstrated itself a little differently: there was no error pop-up when the loading got stock. That's probably because the website had a service-worker and the example above doesn't.

Hope this wasn't too many words and that it will help you pinpoint the issue.

[shatindle]

We're seeing this issue on our app too. Works fine on firefiox mobile and iOS Chrome, but Android Chrome 91 does not work. It partially loads if we enable InvariantGlobalization but errors, and turning it off or leaving it out gets stuck on "Loading..."

[3x0dv5]

My app is on Blazor 6.0.0-preview.6.21355.2

Chrome 91.0.4472.164 on Android - Does not work
Chrome Beta 92.0.4515.105 on Android - Works fine
Chrome Canary 94.0.4581.0 on Android - Works fine

Edge 46.06.4.5160 on Android - Works fine

I do not use Invariant Globalization and I don't do AOT as it generates much bigger files, and performance has not been a problem so far.

[jeffputz]

Chrome 92 for Android was released today, and they say it will be rolling out in "the next few weeks." I don't know if you can force the update, but once someone does, we should verify that our WASM apps work again with no feature flags set.
https://chromereleases.googleblog.com/2021/07/chrome-for-android-update_01500789893.html

[daniel-p-tech]

What solution does Microsoft recommend? My Blazor app stopped working on Chrome for Android 91 and I spent several hours trying to figure out why until I ran across this issue.

According to the comment posted by Google engineer, the underlying issue will be fixed in v92, but they don't really know what caused it... That doesn't give me much confidence that it will not happen again. This is a potential disaster for a small startup that made a bet on Blazor. Fortunately, my app is currently still in development and not in production yet.

https://bugs.chromium.org/p/chromium/issues/detail?id=1214508#c8

Isn't Microsoft involved in contributing to the Chromium project now that it ditched the old Edge?

Have you considered running automated tests on each popular browser that could detect catastrophic bugs that prevent a Blazor app from launching?

Thanks.

[danroth27]

@daniel-p-tech Unfortunately, because the issue hasn't been diagnosed, it's difficult to be sure that this issue will stay fixed. But we are looking at adding Blazor tests for beta and canary browser builds to catch these kinds of regressions earlier.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!