[Bug] Strange behavior when app loses focus application refresh and starts at index page.

[arivera12]

This test have been run on Android.

I have been facing a strange behavior on web app when ever I open an external link that use the browser, move from the application window to another and return back or exactly when I pull a file from the device the app refreshes and goes back to the index page? It even happens when I block and unblock my phone. Why the applications does this when the application window loses focus?

[Daddoon]

There is actually two cases when this behavior may happen:

• The app has been put in background, then foreground but the HTTP port of the webserver are not available anymore for whatever reason. As it can be problematic, the app restart on a new port

• The app started loading in the WebView, but you put the app in foreground and BlazorMobile initialisation to native was not finished or Blazor WASM did not finish Blazor framework loading before getting put in background: In order to avoid inconsistent app state, the app restart.

• Another possible issue is if you put a regular Blazor app without inheriting from MobileApp component, and without calling the BlazorMobilService.Init() code at your app start. Theses calls notify to Native that it has loaded when it's finished. If they are not present they may fallback in the second point listed here as the app believe it has not loaded properly.

Note: I don't have your behavior, tested on the template code and also on a business app shipped to one of my client. So you may be in one of theses issue.

Check your code first, and if you still have the issue, tell what is the OS version, targeted API and CPU architecture. Then only, send a repro project if you think it's a bug.

[arivera12]

I really have no idea what could be wrong. I will attach a project which reproduces this behavior. I also still receiving the socket communication error #182 but don't know why this is happening at all which also reproduces in this project. I tried uploading here the solution but is more than then 10MB allowed here. I am uploading to mediafire I will post the sample project when upload is completed.

[Daddoon]

Don't forget to delete all your obj and bin folders before upload here as they are taking a lot of disk space, but generated at compile time.

You may also create a repository on Github that i can fork then.

[Daddoon]

Do you have this issue while deploying the base template ?

[arivera12]

Do you have this issue while deploying the base template ?

I will test base template and reply back

[arivera12]

It doesn't happens on base template. But don't know why does this happens at all. I added a test project to see if you can tell what is wrong with sockets connection and this random error on android. Project size is only 14MB.

Project

[Daddoon]

Thanks !

I reproduced your bug on your project.
By looking closely to the console output i see:

Loaded assembly: System.Numerics.dll
Loaded assembly: System.Runtime.Serialization.dll
Loaded assembly: System.Data.dll
INFO: Detected Blazor implementation: WebAssembly (Client-side)
03-30 14:11:55.547 I/mono-stdout(13599): INFO: Detected Blazor implementation: WebAssembly (Client-side)
03-30 14:11:55.674 I/Choreographer(13599): Skipped 61 frames!  The application may be doing too much work on its main thread.
INFO: BlazorMobile was unable to connect to native through websocket server to execute task caf83b02-3bd0-456e-a534-eda29ede8cc3
03-30 14:11:55.676 I/mono-stdout(13599): INFO: BlazorMobile was unable to connect to native through websocket server to execute task caf83b02-3bd0-456e-a534-eda29ede8cc3

Notice the last message. It seem that for whatever reason, your app fail to connect to the native side when startup, and therefore your app is never able to say to native that it loaded properly at boot, that's why when resuming, it reload !

I'm investigating why your app don't work out of the box.

[arivera12]

As you can see I added my stuff on your template on the project I shared but this error even reproduces on my machine with fresh template.

[Daddoon]

Thanks for reporting your issue.

After investigations, it seem that there is two bugs.

• The first one seem more like a regression on my side. It seem that if you don't set the remote debugging options and info at the Blazor start, the access point to native return an empty value instead of the default value.

Workaround before i fix this correctly: Call

BlazorMobileService.EnableClientToDeviceRemoteDebugging("127.0.0.1", 8888);

In your Program.cs file of your Blazor WASM project. You should keep 127.0.0.1 for workarounding the current issue when the app load from native. Of course change the value to anything else if you needed to remote / test debug the WASM app too to device (but normally you don't, you usually use Blazor.Server configuration instead !). Otherwise the port must be the same as your remote app (by default 8888 should be fine).

• It seem that one of your plugin, or any actions, done on in the Index.razor page seems to interfere with the normal BlazorMobile boot. I don't know why yet, but discovered that commenting the component rendering on this page and the AfterRender code fixed the initialization.

I don't have a direct workaround before i fix this without you modify your project a little (i think).
One workaround would be to write a condition on your Index.razor page, that say that if the BlazorMobileService.Init does not called the success delegate you put in your Program.cs file, you don't render anything.

Then from the Success delegate, just change the boolean condition and ask to re-render your index page.

The real fix in my opinion, in order to avoid tricky change would be that the plugin use his own "boot page" and then redirect anything to the regular page of your app when ready. But this is an evolution i must do too.

[Daddoon]

As you can see I added my stuff on your template on the project I shared but this error even reproduces on my machine with fresh template.

Yes but in your case here it's different than from what i just replied (some minutes after your post :p ) : The error is here because the Remote debugging endpoint is not set and/or the debug functionnality is maybe not enabled in native with WebApplicationFactory.EnableDebugFeatures(); , like written in the documentation.

[Daddoon]

If you set the right info for remote debugging everything is fine (i just tested).
For your project, see the previous posts.

[arivera12]

Let me read stuff u write 2 fast hahahahaha

[Daddoon]

I was writing while you answered !

[arivera12]

Sorry for my misunderstanding. I didn't understand what were the changes you made to workaround this. I even commented my index.razor page and I still receive the same error. Can you tell me exactly what you did or send me the fix back here? Screenshots maybe be enough and fast for this.

[Daddoon]

Here is your workarounded project:

EventsNet.workaround.zip

I moved BlazorMobileService.Init call into your Index.razor page, and managed to delay the render of your components after BlazorMobile initialization. Of course this is a workaround, you should be able in the future to do this without doing any kind of trickery code at start. See updated code in Index.razor .

Otherwise, you will notice that i called the remote debugging method to 127.0.0.1:8888 in Program.cs . You should not have to call that normally, as it's for redirecting where to connect, but same, because of the actual regression it's a workaround.

You should be able to not have any issue in the future soon even without this line.

I just tested by debugging the GeckoView component remotely with WebIDE (not available anymore but still present in Firefox 67 with SHIFT+F8) and everything work fine now.

Will update this issue when this is resolved officially in the BlazorMobile library !
Thanks for the reports !

[arivera12]

Ok I will try

[Daddoon]

Just to keep you updated, i done some updates for the next version.

• When doing remote debugging without having set a debug endpoint, the console will write an explicit error message and how to solve this issue if it was intended, instead of not managing this issue.
• Getting from this previous point, if it fail for this same reason, the code should now fallback to the default behavior, meaning return a value back even if it's an exception thrown, instead of forgetting to return the task failure.
• But more important, i updated the BlazorMobile init workflow. In the next version, you will be able to boot your app and your libraries without having to workaround/hack your code logic. You will be able to start anything you want without conflict.

I will keep you updated when a new version will be released !

[Daddoon]

Closing, as it will be available in next version.

[arivera12]

@Daddoon my project has a lot of dependencies its a good project for testing your updates in my opinion. Thanks for keeping me in the loop.

[Daddoon]

I already tested with the test project you send me so it should be ok !
But yes, it's good for testing with a more "difficult" environment !

Internally the new way is like "Load Blazor....Render BlazorMobile and wait for Init...Then render anything from the user app", so i think even if you put a lot of thing it should be ok, as your app logic will be loaded after the BlazorMobile component.

If you want to take a look, you may try to fork the current BlazorMobile 3.2.5 branch, and try to compile source, and retrieve nuget packages, even if this build is not final, as i'm investigating some other points not related to this issue.

The migration guide has been also updated already on this branch, so you should be able to see how to migrate.

[Daddoon]

A new version has been released !

See migration here: https://github.com/Daddoon/BlazorMobile/blob/master/MIGRATION.md#blazormobile-324-preview2201605-to-325-preview3201683

[arivera12]

@Daddoon I have been very busy I will test and give feedback!