Embedded.js does not find mono-config.js

[SerratedSharp]

When using embedded.js to load the package, it attempts to retrieve mono-config.js. The WASM package_ contains a mono-config.json but not a mono-config.js

When I inspect the embedded.js script throwing an error, it shows where it is attempting to generate a mono-config.js reference:

These are the script names declared further up in embedded.js that are the input to that reduce where they are all assumed to be *.js files:

I did a clean and rebuild and my WASM package contains the following:

The WASM project is .NET 7 and references Uno.Wasm.Bootstrap 7.0.27 and Uno.Foundation.Runtime.WebAssembly 4.9.45

I also created a fresh new .NET 7 console app in VS2022 17.7.0, copied the csproj definition per documentation with updated to 7.0.27 version, built to verify successful package generation, then added <WasmShellMode>BrowserEmbedded</WasmShellMode> to the csproj and cleaned then rebuilt. This package also did not contain a mono-config.js under bin/Debug/.net7.0/dist/ and I verified the emedded.js also includes the same script declaration that tries to load a mono.config.js. I have attached a zip of this project below. This is the csproj definition:

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

	<PropertyGroup>
		<OutputType>Exe</OutputType>
		<TargetFramework>net7.0</TargetFramework>
		<MonoRuntimeDebuggerEnabled Condition="'$(Configuration)'=='Debug'">true</MonoRuntimeDebuggerEnabled>
		<WasmShellMode>BrowserEmbedded</WasmShellMode>
	</PropertyGroup>

	<ItemGroup>
		<PackageReference Include="Uno.Wasm.Bootstrap" Version="7.0.27" />
		<PackageReference Include="Uno.Wasm.Bootstrap.DevServer" Version="7.0.27" PrivateAssets="all" />
	</ItemGroup>

</Project>

WasmEmbeddedTest.zip

[SerratedSharp]

Looks like this might have been fixed by this change:
#728

I am guessing this is probably in a more recent -dev build?

I'm more of a DevOps person so not familiar with github workflows. Is there a way to determine what release/version a particular commit or PR was included in?

[jeromelaban]

@SerratedSharp indeed, the fix for the embedded mode is included in the 8.0-dev pre-release builds. Those builds are targeting the upcoming .NET 8.

[SerratedSharp]

Using newest dev build it seems to be working now, no errors and the info body gets populated, but the white loading overlay doesn't disappear. Is it possible to give me a starter clue on what code controls detecting that loading is complete and hides/removes the overlay? I'd like to try and start getting familiar enough with the code base that I can troubleshoot myself.

[SerratedSharp]

One thing I noticed is I am getting duplicate uno-body elements. The one I declare per embedded mode instructions, and then an additional one added by the embedded.js

I don't know how the identifier unoRootElement would ever get set, nor find the declared uno-body. I did a repo search and it only appears here, so I am wondering where this var would be set/initialized. Thus it always drops into the else, and creates a new div which inserts a new uno-body in addition to the one already declared per embedded instructions.

The way other code like in the bootstrapper checks for the element is using document.getElementById("uno-body"); so I'd expect embedded.js to use the same technique here to check for, locate, and assign unoRootElement.

[SerratedSharp]

So I removed my own <div uno-body/> since one is always added by the js. Now only one uno-body exists, but it still doesn't hide the loader.

When I step through embedded.js and uno-bootstrap.js, it looks like the loader doesn't get removed when progress is complete, but instead waits for a mutation of the body. If I run this code in console to add a blank div in the uno-body then it triggers the mutation observer to remove the loader. What is the bootstrapper's mutation observer watching for? I.e. when loading is complete, what would normally happen to trigger the mutation observer?

var ub = document.getElementById('uno-body')
var newDiv = document.createElement("div");		
ub.appendChild(newDiv);

Repro, this is using .NET 8, latest dev build, WasmShellMode=BrowserEmbedded(set in build.props), and using my custom build.props to copy the wasm package into wwwroot(but I don't think this would effect how the javascript is handling the loader overlay):
UnoLoaderForever.zip

[jeromelaban]

This portion of the loader is aligned with this part in Uno. You may find what we do with the splashscreen there, given that the observer is looking for changes in the body:

Uno.Wasm.Bootstrap/src/Uno.Wasm.Bootstrap/ts/Uno/WebAssembly/Bootstrapper.ts

Line 317 in 70179ed

this.bodyObserver.observe(this.body, { childList: true });

[SerratedSharp]

@jeromelaban
So should Browser Embedded mode note that a splash screen or other content is required to trigger the loader overlay to hide, with some notes on how to listen for loading completed as part of the suggested boiler plate code? This isn't required until you switch to browser embedded mode so seems like a pitfall. Or better yet, could we implement a check for a class or attribute on the placeholder uno-body that allows the implementer to instruct the loader to auto hide on loading complete instead of waiting for a mutation. Something like <div id="uno-body" class="auto-hide-loader" /> ?

Any thoughts on the duplicate uno-body? It seems logical that Browser Embedded mode has you declare a placeholder body so you can control where on the page it appears, but the way the code actually behaves, the placeholder is ignored. I feel like there was probably an intention to check for and initialize unoRootElement to this placeholder if it existed, given the variable isn't initialized anywhere. I would imagine something like this first line was maybe intended and would fix the issue, but without knowing original intent, I don't know if this would potentially break something else that depends on the current behavior.

         var unoRootElement = document.getElementById('uno-body');// Suggested new line: check for and use optional placeholder uno-body if present
	if(unoRootElement !== null) {
		unoRootElement.innerHTML = html; // populate existing
	} else { // no existing uno-body, create a new one in document root
		var rootDiv = document.createElement(""div"");
		rootDiv.innerHTML = html;
		document.body.appendChild(rootDiv);
	}

Otherwise I just can't see how it'd ever fall into that first if with unoRootElement not ever being defined anywhere else:

Uno.Wasm.Bootstrap/src/Uno.Wasm.Bootstrap/ShellTask.cs

Line 2220 in 70179ed

if(typeof unoRootElement !== 'undefined') {