[browser] Add withDownloadResourceProgress to DotnetHostBuilder - #134498
Merged
Merged
Conversation
onDownloadResourceProgress was declared on DotnetModuleConfig, but the only way to supply it was withModuleConfig, which is internal and not part of the public DotnetHostBuilder surface. That left no supported way for apps to observe resource loading during startup. Add withDownloadResourceProgress(callback) to the public builder in both the CoreCLR and Mono loaders, and switch the WasmBasicTestApp startup progress scenario over to it. The test asset is shared by the Mono and CoreCLR Wasm.Build.Tests lanes, so both loaders need the method. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
maraf
added
arch-wasm
Contributor
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Member
Contributor
|
Would this fix #93941? |
maraf
changed the title
maraf
marked this pull request as ready for review
September 24, 2026 14:48
maraf
requested review from
ilonatommy,
lewing and
pavelsavara
as code owners
September 24, 2026 14:48
Contributor
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
No unresolved blocking issues were identified.
Review effort: Lite
Findings: None
What changed in this PR
Adds withDownloadResourceProgress to the public DotnetHostBuilder API for both CoreCLR and Mono WebAssembly loaders.
Changes:
- Adds runtime implementations and TypeScript declarations.
- Updates the shared test asset to use the public API.
- Preserves existing callback behavior and Mono error handling.
| File | Description |
|---|---|
src/native/libs/Common/JavaScript/types/public-api.ts |
CoreCLR public API declaration |
src/native/libs/Common/JavaScript/loader/host-builder.ts |
CoreCLR implementation |
src/native/libs/Common/JavaScript/loader/dotnet.d.ts |
CoreCLR declaration |
src/mono/wasm/testassets/WasmBasicTestApp/App/wwwroot/main.js |
Uses the new public API |
src/mono/browser/runtime/types/index.ts |
Mono public API declaration |
src/mono/browser/runtime/loader/run.ts |
Mono implementation |
src/mono/browser/runtime/dotnet.d.ts |
Mono declaration |
pavelsavara
approved these changes
Sep 24, 2026
maraf
enabled auto-merge (squash)
September 24, 2026 16:19
Contributor
|
Is it worth documenting that |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #93941
Why
onDownloadResourceProgressis honored by the loader, but the only way to supply it iswithModuleConfig, which is internal and not part of the publicDotnetHostBuilder. Apps have no supported way to observe resource loading during startup.What
Adds
withDownloadResourceProgress(callback?)to the publicDotnetHostBuilder, wired to the existing callback. Behavior is unchanged; this only exposes an already-working mechanism.Added to both loaders, since
WasmBasicTestAppis shared by the Mono and CoreCLRWasm.Build.Testslanes and the progress tests carry no runtime filter. On Mono it routes throughdeep_merge_modulewith the samemono_exithandling as sibling builder methods. The test asset now calls the public method instead ofwithModuleConfig.Notes for reviewers
Not on
LoaderConfig, which came up in review. Neither config type has any callback field today; callbacks live onDotnetModuleConfigor go through a builder method, aswithResourceLoaderdoes. Mono also serializes config to worker threads, andJSON.stringifydrops functions silently.Follow-up, not done here: CoreCLR still assigns to
Module, the internal surface this works around. A tidier version would mirrorwithResourceLoaderwith a module-level callback inassets.ts. Left out to keep this small; happy to fold in.Note
This PR description was generated with the assistance of GitHub Copilot.