BasicBlazorComponentClick test fails on Android API 27 and earlier

[pranavkm]

This test is one of 3 that affects the overall pass rate for the repo and we should prioritize fixing it.

[SteveSandersonMS]

Looks like increasing the timeout (#4543) didn't work: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5724063&view=ms.vss-test-web.build-test-results-tab&runId=32882308&resultId=100000&paneView=debug

System.Exception : Waited 7500ms but couldn't get controlDiv to have value '0'. Most recent value was 'null'.

However this doesn't look like flakiness to me. In all 5 of the most recent builds, android_device_tests_blazorwebview_X failed for all X<28, and passed for all X>=28. That can't be a coincidence, surely. This must mean that it works for Android API level 28 and above, but that the actual feature doesn't work on API level 27 and below. Note that API 28 = Android 9 (2018).

I'm assuming that since MAUI has tests going back to API level 23 (Android 6, 2015), that's what MAUI apps are supposed to support. We need to debug why BlazorWebView doesn't work that far back. It might be that we're using some JS APIs that didn't appear until later. Or it might be a problem in MAUI itself. I'm going to change the issue title to match this.

[SteveSandersonMS]

So it turns out I was wrong about the underlying functionality being broken. I've confirmed that BlazorWebView does actually work fine on API level 27. Even the test in question here (BasicBlazorComponentClick) runs and passes locally on API level 27.

As such, there must be some other reason why this test mechanism consistently fails on API <= 27 when running in CI, as in this build:

Inspecting logs from the API level 27 run, the following looks like a smoking gun:

02-08 09:52:06.736  5288  5288 I chromium: [INFO:CONSOLE(1)] "Uncaught SyntaxError: Unexpected token import", source: https://0.0.0.0/_framework/blazor.webview.js (1)
02-08 09:52:06.762  5288  5288 I chromium: [INFO:CONSOLE(2)] "Uncaught ReferenceError: Blazor is not defined", source:  (2)

Yes, it's very much not going to work if we use import and the browser engine is too old to support that. As for why the browser engine in CI is older than the one I get when using API level 27 locally, presumably the Chrome version isn't tied to the API level, so you could get different Android build or updates that affect the Chrome version independently of the API level. I don't know if the WebView browser engine version is determined by the installed Chrome app version, or whether that's a separate thing.

• Update If this doc is still current, then Android users can configure the WebView to use "any compatible Chrome version (Dev, Beta or Stable) that is installed on your device or the standalone Webview APK". That is going to make it tough to define a specific set of supported devices.

We need to work out how exactly we are defining the range of supported Android versions, and perhaps stop using import in blazor.webview.js.

[SteveSandersonMS]

Note that here's where we use dynamic import. It's not specific to blazor.webview.js:

https://github.com/dotnet/aspnetcore/blob/main/src/Components/Web.JS/src/JSInitializers/JSInitializers.ts#L26

const initializer = await import(/* webpackIgnore: true */ adjustedPath) as Partial<BlazorInitializer>;

[SteveSandersonMS]

According to the following, Chromium gained support for import in version 63 (December 6th, 2017).

The next major version of Android that was released after this date was Android 9 (Pie, August 6, 2018). This is also where API level 28 came in, which is also where our E2E test starts passing.

[SteveSandersonMS]

I'm not sure where we can get worthwhile statistics on the market share of different Chrome for Android versions. Online sources for browser market share data don't easily offer any breakdowns of Chrome for Android versions.

The statistics for Android < 9 versions look pretty bad:

Region	Usage of 8.1 and below
Worldwide	27.48%
Europe	21.15%
USA	17.75%
China	28.49%

However, presumably a lot of these end users aren't actually still on Chrome 62, even if their device was like that when they bought it. If a lot of the Blazor developer community needed to support Chrome 62, then we'd have got a lot more pushback about Blazor on .NET 6, since it uses import in blazor.webassembly.js and blazor.server.js. I don't recall getting any complaints about that.

@dotnet/aspnet-blazor-eng @danroth27 Have we already got a defined plan for Android version support? Is it meant to be the same as MAUI itself? I suspect we're going to have to define it as being "the same devices that can use Blazor Server and Blazor WebAssembly in their browser", which is currently Chrome 63+.

The only alternative would be to refactor blazor.webview.js so that it doesn't attempt to parse any JS code that includes the import keyword when you're not actually using JS initializers. Then at least it would work by default on older browsers, and it would be the JS initializers feature specifically that requires a newer browser. However this isn't a great direction for us to go in, as we wouldn't be testing broadly on such old devices and don't want to be heavily limited on implementing newer features that require more recent browsers.

[javiercn]

Wholeheartedly agree with @SteveSandersonMS here. Our support matrix should be the intersection between Maui and Blazor. Supporting things outside that creates a broken experience and forces us to expand the Blazor support matrix which would require big changes and would have a severe impact on libraries.

As a compromise, we could think of a way that lets users get access to the files at build time so that they can transpile the sources and include necessary polyfills without us providing any guarantee that everything would be supported. (We won't block you, but we won't consider that scenario part of our support matrix)

[danroth27]

Have we already got a defined plan for Android version support? Is it meant to be the same as MAUI itself? I suspect we're going to have to define it as being "the same devices that can use Blazor Server and Blazor WebAssembly in their browser", which is currently Chrome 63+.

Our Android version support should ideally be the same as .NET MAUI (.NET MAUI supported platforms), but I assume we can separately define what browser versions we support with Blazor. The data on browser version adoption, while not specific to mobile, seems to indicate pretty strongly that new Chrome browser versions are adopted rapidly. I think we can require a reasonably up to date browser. For Blazor we test on the latest browser versions. Why wouldn't we do the same for .NET MAUI Blazor?

[danroth27]

Adding @davidortinau and @jamesmontemagno to add their perspectives on our support matrix for MAUI.

[SteveSandersonMS]

For Blazor we test on the latest browser versions. Why wouldn't we do the same for .NET MAUI Blazor?

Agreed, that is what I was proposing and also what @javiercn's comment recommends. Sounds like we're all happy with that.

Further, it seems that even back on Android 5, which is the oldest that MAUI supports, it's possible to install a reasonably modern version of Chrome and the WebView will use it. So any given user whose device runs MAUI can also run a BlazorWebView app if they are willing to update their browser.

But even with all this, we'd be concluding that BlazorWebView's support range is a subset of MAUI's, since MAUI itself can also run on Android 5 even if the browser has not been updated. We couldn't strictly claim that BlazorWebView runs everywhere that MAUI does and might need to note that in some docs somewhere.

[Eilon]

There are 2 issues with old Android support, give me a sec to find them.

[Eilon]

These are the two "older Android" issues I know of:

1. Android 5 (very old): [Bug] [Android] [MAUI Blazor] Crash on Android 5 device/emulator #3023 <-- this is one we can fix in .NET MAUI whenever we want, but I fear it's a lot of work
2. Android 7.1 (kinda old): Net.Maui Blazor not running on Android 7.1 Tablet  aspnetcore#39086 (comment) <-- this one would need to be patched in .NET 6, or fixed in .NET 7

[danroth27]

But even with all this, we'd be concluding that BlazorWebView's support range is a subset of MAUI's, since MAUI itself can also run on Android 5 even if the browser has not been updated. We couldn't strictly claim that BlazorWebView runs everywhere that MAUI does and might need to note that in some docs somewhere.

Agreed. I'll follow up to make sure this gets documented.

[jamesmontemagno]

https://apilevels.com/ is a good reference point... It really depends RN for example also support API 21+ and iOS 11+. Ionic seems to be the same with v6 supporting 5.0+ with Chromium 60+ on Android but iOS i only iOS 13+ which is interesting.

So I think maybe it is just documentation and have a "recommended" lowest version. I target API 26 personally now adays.

[Laftek]

Is there any way how to detect browser version installed on the device from within MAUI? Or any other way how to check if the browser version will be compatible with MAUI Blazor?

I am asking for using this information to, for example display message: “Please update your browser app”.

I am new to this so sorry if thats stupid question. Thanks.

@jamesmontemagno @SteveSandersonMS

[Eilon]

@Laftek please log a new issue. Comments on closed items will likely not get seen.