[browser] Fix Debug-only startup failures: stack-first assert, incoming Module API, preRun function form

[pavelsavara]

Three unrelated-looking failures that all only reproduce in Debug browser builds, plus one follow-on cleanup.

1. Mono MT asserts on the stack bounds at startup

* Assertion at src/mono/mono/utils/mono-threads-wasm.c:201, condition `*staddr != NULL' not met
  at mono_threads_platform_get_stack_bounds
  at mono_thread_info_get_stack_bounds
  at register_thread
  at mono_wasm_register_ui_thread

At -O0 emscripten links with --stack-first, which puts the stack at the start of linear memory, so __stack_low == 0. pthread_getattr_np reports stack = emscripten_stack_get_base() and stack_size = base - end, and pthread_attr_getstack returns stack - stack_size, i.e. emscripten_stack_get_end() — legitimately NULL under this layout. Emscripten also comments out musl's if (!a->_a_stackaddr) return EINVAL, so the call succeeds and the assert is what fires.

Mono already accounts for this everywhere else: register_thread has an explicit #ifndef TARGET_WASM around g_assert (staddr) with the comment "for wasm, the stack can be placed at the start of the linear memory", and the non-pthreads branch of mono_threads_platform_get_stack_bounds has no NULL assert at all — which is why Debug single-threaded works. Only the __EMSCRIPTEN_PTHREADS__ branch was missed.

The *stsize != (size_t)-1 assert stays, so a genuinely uninitialized main pthread (stack = 0, stack_size = 0) is still caught by g_assert (stsize) in register_thread.

2. Module.wasmMemory was supplied but wasmMemory not included in INCOMING_MODULE_JS_API

With assertions on, emscripten aborts when a Module property is supplied that isn't declared. Mono's MT worker sets Module.wasmMemory when it receives the mono config, and wasmMemory is not in emscripten's default list — so Debug + MT + Mono aborts during startup.

Both flavors now declare INCOMING_MODULE_JS_API explicitly: emscripten's full default set, plus wasmMemory for Mono when threads are enabled. Nothing that works today changes, and an undeclared property still fails loudly at link instead of silently.

An earlier revision of this PR listed only the properties the loaders themselves set, which rejected 16 properties emscripten accepts by default. That turned out to be reachable from user code — Blazor's prepareRuntimeConfig does ...(window['Module'] || {}) into the module config, so an app author can put any emscripten property on window.Module and it would have aborted a debug build. Hence the full default set.

Adding wasmMemory is behaviourally neutral: initMemory() returns early on a pthread before reaching the Module['wasmMemory'] branch, and the main thread never sets it.

corerun is deliberately left on the default list — its JS injects no Module properties, and corerun.html assigns monitorRunDependencies.

One source of the list per flavor

The list is not hand-copied per link step. CoreCLR defines it once in GenerateEmccExports (eng/native.wasm.targets), which is packaged into the WebAssembly SDK, so both the in-tree browserhost link and the workload relink consume the same target — the earlier fallback copy in BrowserWasmApp.CoreCLR.targets is removed. Mono defines it once in browser.proj, emits it into wasm-props.json, and the app relink reads it back through ReadWasmProps — the same way EXPORTED_FUNCTIONS/EXPORTED_RUNTIME_METHODS already flow.

The -s INCOMING_MODULE_JS_API flag is emitted only for Debug: the allowlist only does anything with emscripten assertions on, so Release keeps emscripten's default list (for CoreCLR the flag moved into the browserhost CMakeLists.txt if(DEBUG) block, next to ASSERTIONS=1). The MSBuild item is named _EmccIncomingModuleJSAPI (each entry is one API) and the joined property _EmccIncomingModuleJSAPIs, both underscore-internal so app authors don't set them.

3. TypeError: (Module.preRun || []) is not iterable

Emscripten lets preInit/preRun/postRun be an array or a single callback, and normalizes them itself. The browser host prepends its own hooks by spreading the user value, so a single function throws. Mono already normalizes this in configureEmscriptenStartup.

WasmBasicTestApp passes preRun as a function, which is how Wasm.Build.Tests hit it after moving to the standard workload. EmscriptenModuleInternal declared these as arrays only, which is what allowed the assumption — widened to match Mono's EmscriptenModule. postRun needs no normalization because the host never prepends to it.

The normalization helper lives inside dotnetInitializeModule: emscripten serializes that function with Function.toString(), so a bundle-scope helper would be dropped and its minified name (t) left dangling — the ReferenceError: t is not defined startup failure. Keeping it in the serialized scope avoids that.

Verification

• Mono -subset mono -c Debug /p:WasmEnableThreads=true builds; in the regenerated dotnet.native.js, checkIncomingModuleAPI rejects exactly what stock emscripten rejects minus wasmMemory.
• CoreCLR -subset clr+libs+host -c Debug builds; the browserhost dotnet.native.js checkIncomingModuleAPI accepts the 26 emscripten defaults and rejects wasmMemory/wasmBinary, unchanged across the dedup and rename.
• npm run rollup:debug and npm run lint are clean under src/native.

Still not runtime-tested (no Wasm.Build.Tests or xharness run). The BrowserWasmApp.CoreCLR.targets evaluation-order hazard from an earlier revision is gone: the list now comes from the GenerateEmccExports dependency instead of an ItemGroup that had to precede the PropertyGroup.

Resolves #132555

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot review overview

🟡 Changes recommended

A Debug CoreCLR workload/native-relink test is needed before approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Add Debug CoreCLR native relink test covering browser startup · New

What changed in this PR

Fixes Debug-only WebAssembly browser startup failures across Mono, CoreCLR, and JavaScript interop.

Changes:

• Handles stack-first WASM stack bounds.
• Declares Emscripten incoming Module APIs.
• Supports function-form startup callbacks.
• Corrects CoreCLR MSBuild evaluation order.

File	Summary
src/​native/​libs/​System.Runtime.InteropServices.JavaScript.Native/​interop/​http.ts	Formatting cleanup.
src/​native/​libs/​System.Native.Browser/​native/​index.ts	Normalizes callback values.
src/​native/​libs/​Common/​JavaScript/​types/​internal.ts	Widens callback type definitions.
src/​native/​corehost/​browserhost/​CMakeLists.txt	Adds the explicit Module API allowlist.
src/​mono/​mono/​utils/​mono-threads-wasm.c	Allows a null stack base for stack-first builds.
src/​mono/​browser/​build/​BrowserWasmApp.targets	Adds Mono linker API configuration; duplicated allowlist remains a nit.
src/​mono/​browser/​build/​BrowserWasmApp.CoreCLR.targets	Adds CoreCLR relink API configuration; requires a Debug workload/native-relink test.
src/​mono/​browser/​browser.proj	Adds Mono browser API configuration.

[Copilot]

Copilot review overview

🟡 Changes recommended

Null stack-base range checks remain unsafe and must be guarded.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Guard stack range checks when stack base is NULL · New
• Add Debug CoreCLR native relink test covering browser startup