Maui-Blazor App With Android WebView 105.x Stops Responding #9882
Assignees
Labels
area-blazor
Blazor Hybrid / Desktop, BlazorWebView
external
investigate
p/1
Work that is important, and has been scheduled for release in this or an upcoming sprint
platform/android 🤖
t/bug
Something isn't working
Milestone
Comments
jsuarezruiz
added
area-blazor
|
We're having the same issue. Application "hungs" within seconds of usage.
|
|
Experiencing a similar problem since Friday across Android 9 & 11 and Android device manufacturers. I have noticed the following log entries on my Samsung Galaxy A31 dev. device when pressing app buttons [GPUAUX] [AUX]GuiExtAuxCheckAuxPath:630: Null anb Hauwei P20 I hope these logs help. |
|
@Eilon would a repro without Blazor be possible here so it can be investigated by the WebView folks? |
|
@Thomr77 @GarageGadget can you please confirm if this is on a published application or in development mode. This may be related to this StackOverflow post where hot reload was identified as a potential culprit of that error. |
|
In our case it is a published application ( https://play.google.com/store/apps/details?id=hu.healthwhatelse ). We are receiving user feedbacks about the problem since 4th of september. Switching to version 104.x of Android System WebView and restarting the application instantly fixes the issue. Yet it is impossible to force all our users to downgrade manually The issue is also reproducible using the emulator (both Debug and Release modes) --> using 105+ version of the webview results in application stops responding after few page switches. And everything comes back to normal if the version of the webview is switched 104.x |
|
@TanayParikh the problem exists in Release and Debug configurations. You can reproduce the problem by using the default .NET Maui Blazor template. |
|
@TanayParikh - Cheers - We are experiencing this with published Apps and also Apps in development mode. I am sorry to ask but we are in quite a bad spot now as users that are automatically upgraded to 105 WebView cannot run our products, we really cannot ask them to uninstall 105 - will this get priority? |
|
I think I have the same issue you are having right now. I will give out the full logs I got below when running in my Samsung Physical Device. This is a serious Prod Issue. My user is complaining too. Will this be a hotfix priority ? I noitice that when running in 105. I received these log when tapping on the screen. If I run on 103, I don't see those logs. Full Logs: |
|
@jonathanpeppers looks like this is caused by something low level and we'd need some help from you with this, as it doesn't seem to be Blazor specific. |
|
Well, the good news is that I can repro this in an emulator. I got to click 156 and then the app hangs. |
|
And it only repros with Android WebView Beta (I used version 106.0.5249.23). The non-Beta ones I tried both worked: 91.0.4472.114 came installed in the image, and then I updated to latest non-beta release 104.0.5112.97. |
|
Repros in debug mode too. Sometimes I got to 50, sometimes around 100, and one time to 230. But at least this could be helpful to understand why it's happening. |
|
Using the F12 tools, there's no weird allocations, no weird CPU usage, nothing weird at all... it just stops after a while. And it's not like it's hanging - it just stops accepting clicks. Will debug more. |
|
I added an HTML button with alert('hey') and that continues to work. So it's just the Blazor part of things that isn't working (which doesn't mean Blazor is broken - it could be that the message channel is not working). |
|
The click on the Blazor button is being correctly processed by the Blazor JS code because I can see it ends up calling SendMessage. But then a message never comes back... (receiveMessage is never called) I added some instrumentation and I see a bunch of these happening: |
|
I confirmed with some breakpoints in the .NET BlazorWebView code that the .NET code is not receiving the web message once things stop working. Not sure if the web message channel is busted due to incorrect usage, or perhaps there's an issue with the Android WebView beta. |
|
@Eilon usually things like this we would file an issue with Google: https://source.android.com/docs/setup/contribute/report-bugs Is there a particular browser feature being used here that is failing? Is there an alternate JavaScript API? |
|
@jonathanpeppers it's a common browser feature called WebMessagePort/Channel: https://developer.android.com/reference/android/webkit/WebMessagePort It's a way of passing messages between the stuff that runs within the browser ("JavaScript code") and whoever is hosting the code ("C# code" or "Java"). For some reason, the messages just seem to... stop. I'll dig in a bit more and then file a bug if it seems appropriate. Thank you for the pointer! (I couldn't find that page when I searched!) |
|
From the JS side, this is what it looks like when it goes from "working" to "broken": Click on Counter
Click on Counter
Click on Counter
Click on Counter (from here on it is broken)
Click on Counter
Click on Counter
Click on Counter
Click on Counter
Click on Counter
If you refresh just the WebView (such as by pressing F5 in the F12 Dev Tools), everything resets and starts working again. So, it seems that something is breaking the web message channel. |
|
I have good news and bad news. The good news is I have a fix: add the JS logging code The bad news is that the good news is true 😁 So I do suspect that there could be a bug in the Android WebView Beta. I'll file a bug tomorrow. |
|
Logging the event prevents the crash? 😮 |
|
Just a tip, Google might look into a bug report more quickly if you can send a pure Java or Kotlin example. Maybe you can reproduce in a single html page and throw that in a web view? The response we have gotten in the past, "what is all this C# business?". |
|
Just wanted to chime in that this happens with the non-Beta version of WebView too. The reason I noticed (and my users as well) is that Android automatically installed the latest WebView in the background. |
|
Just wanted to second this. We have a production app and we're seeing more and more users who can no longer interact with elements on the page, effectively rendering it worthless. I can confirm that updating to 105.x breaks it, and downgrading fixes it. So as more of our users update the app breaks. |
|
Sounds like it's in Google's hands now. There is some activity on that bug request, so fingers crossed. Instructing my users to downgrade their WebView seems to be working well so far. |
|
For those experiencing this issue, I would encourage providing feedback/thumbs up in the Google issue. I imagine this may get more visibility if there's greater community engagement (and the impact is clear). |
|
This just happened to me while I was developing my app. My device started downloading some updates including the Android System WebView update and the app started to act like described in this issue. I would have been lost if it wasn't for this issue, hopefully Google will release a fix soon. |
|
Could as many as possible (ask co-workers) to tick the 'I am Impacted' counter in the Google issue
This way it should get higher priority and get resolved faster. |
|
I noticed some issues in at least 2 other web based apps I had installed already that are present with 105, but work with an earlier version. It's interesting that their description of the update on the play store for 105 only reads "Bug fixes and speedy performance improvements" No mention of mass panic, global outages, or what they actually fixed... |
samhouts
added
the
p/1
|
Google marked this issue with P3 priority which will not be fixed in a short period of time (Google status docs). I don't know if there is any solution to work around this issue since this is a PROD issue on Android device. We have a production application and our users cannot use it for about 2 weeks. |
|
@arthastheking113 - Thanks for this - I thought about this priority too. For us it is the same - asking users to uninstall WebView 105 is already a very high ask, and then Android re-installs it the next day and the user has to uninstall it again - there is no real workaround - what can be done? Like @TanayParikh says, it is really important that we all post how this impacts us/our products in the Google issue - otherwise they do not know especially as its topic is about 106 Beta when it is about the currently installed WebView 105. |
|
Seems that Google has acknowledged the severity early this morning and has bumped the priority to S1 and priority P0. |
|
How can somebody uninstall the WebView 105? I would like to know so my apps that uses blazor hybrid can at least work for a day until its fixed. |
https://play.google.com/store/apps/details?id=com.google.android.webview&hl=en_US&gl=US Then tap Uninstall. |
As imperfect a solution as this is it does work very well. We pushed an update to production yesterday that checks the system webview version on startup and displays an alternate view if it has the offending version "105.0.5195.79". I realize 106 beta doesn't work either, but I didn't want to cast the version net too wide for when a fix comes out. This alternate view explains the issue, and gives a link to the webview on the play store and a way to exit the app. Obviously hoping that this is very short lived, but it does look better than an unresponsive app with no explanation, and mounting support calls. This view was built with native controls (obviously) so that the buttons work. EDIT: I imagine after they do release a fix we'll keep this alternate view, but change the text to indicate that they should update their webview to a later version rather than uninstall. That should pick up any stragglers that come late to the party. |
|
Update: This issue will be fixed in Webview version 105.0.5195.136. Currently, newest Webview version is 105.0.5195.124 , I guess we will need to wait for 3-7 days to receive 105.0.5195.136 update. |
|
Man, this got resolved speedily by Google. I was fearing the worst... |
|
It has just made the WebView 105.0.5195.136 available on our Samsung SM-T870 and installed it, and it is all working well again!! Thank you all very much!! |
|
Now that it looks like the fix for the bug in Android is starting to go public (per https://issuetracker.google.com/issues/245837736), I am closing this issue. Thank you everyone here, at Google, and my Microsoft colleagues for such a quick response! |
|
How do I get the latest update from google? When I go to the google play store, still shows September 5 which is the version with the bug. |
Perhaps it's a gradual roll-out? The best place to ask would be on the Google Issue Tracker because the release is coming from them. |
You can download the update via Google Play Store. I've just done it and can confirm the latest update fixes the problem. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
On Android Devices (API 31) where the Android System WebView has been updated to 105.x, Maui-Blazor apps stop responding when interacting with them for a few seconds after launch.
Once interaction has stopped, some basic browser functionality is still available (e.g. scrolling the page or button state changes) but anything that involves JavaScript fails (callbacks etc).
Once the 105.x WebView is uninstalled the Maui-Blazor apps work correctly again.
We have just noticed this first on a Samsung SM-T870 tablet on Friday where the new WebView was installed but also later on other Android devices.
Update: We have also tried WebView 106 Beta which shows the same issue as 105.
Steps to Reproduce
Watch the Output for the message indicating it has failed (see log section).
Note: The failing point seems to be linked to how much JavaScript interaction there is - Apps that have more heavy usage will fail pretty much immediately post launch.
Link to public reproduction project repository
https://github.com/Thomr77/MauiBlazorWebView105
Version with bug
6.0.486 (current)
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
Android API 31 With Android System WebView 105.x and 106.x Beta.
Did you find any workaround?
None.
Relevant log output
Failing is linked to Output:
[lazorwebview10] Explicit concurrent copying GC freed 31190(2115KB) AllocSpace objects, 0(0B) LOS objects, 64% free, 3380KB/9524KB, paused 21us,22us total 7.232ms
The text was updated successfully, but these errors were encountered: