-
Notifications
You must be signed in to change notification settings - Fork 1.6k
webview2: Add version 144.0.3719.93 #17085
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
WalkthroughA new WebView2 Runtime manifest file is added to the bucket, defining a Scoop-like package with architecture-specific downloads for 32-bit, 64-bit, and arm64 platforms. The manifest includes version detection via PowerShell scraping and auto-update configuration with dynamic URL generation based on version and architecture tokens. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
All changes look good. Wait for review from human collaborators. webview2
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@bucket/webview2.json`:
- Line 9: The existing "notes" entry for WEBVIEW2_BROWSER_EXECUTABLE_FOLDER is
ambiguous about architecture compatibility; update the notes string (the "notes"
JSON value in webview2.json) to explicitly state that the environment variable
must point to the runtime that matches the application's architecture (e.g., a
32-bit app cannot use a 64-bit WebView2 runtime and vice versa), and add a brief
sentence warning that pointing to an installed runtime of a different
architecture will cause WebView2 initialization to fail; apply the same
clarification to the other similar note entries referenced (lines 27-29).
| "identifier": "Proprietary", | ||
| "url": "https://developer.microsoft.com/microsoft-edge/api/eula/webview2" | ||
| }, | ||
| "notes": "Overrides any natively installed Runtime through environment variable 'WEBVIEW2_BROWSER_EXECUTABLE_FOLDER'.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
git ls-files | grep -E "(webview|bucket)" | head -20Repository: ScoopInstaller/Extras
Length of output: 505
🏁 Script executed:
fd "webview2.json" --type fRepository: ScoopInstaller/Extras
Length of output: 85
🏁 Script executed:
cat -n bucket/webview2.jsonRepository: ScoopInstaller/Extras
Length of output: 4468
🌐 Web query:
WEBVIEW2_BROWSER_EXECUTABLE_FOLDER architecture specific 32-bit 64-bit
💡 Result:
WEBVIEW2_BROWSER_EXECUTABLE_FOLDER is not inherently “32-bit vs 64-bit”—it’s just a string path override that WebView2 reads when creating a new WebView2 Runtime browser process. If it’s set, it overrides the browserExecutableFolder you pass in code/SDK options. [1][2]
What is architecture-specific is what that path points to:
- Your app loads an architecture-specific WebView2 loader (
WebView2Loader.dll). You must ship/use the loader that matches your app’s architecture (x86 vs x64 vs arm64). [3] - If you’re pointing
WEBVIEW2_BROWSER_EXECUTABLE_FOLDERat a Fixed Version Runtime, the folder you point to must contain the matching-architecture fixed runtime binaries for the process that’s loading WebView2 (e.g., an x86 process must use an x86 fixed runtime folder). Practically, you should set different values per-architecture build (or set the env var per-process before creating WebView2). [2][3]
Sources:
[1] Microsoft Learn (WebView2) – setting WEBVIEW2_BROWSER_EXECUTABLE_FOLDER env var and behavior
[2] CoreWebView2Environment docs – env var overrides browserExecutableFolder / fixed-version folder usage
[3] Microsoft Learn (WebView2 deployment) – WebView2Loader.dll is native and architecture-specific
Clarify the architecture-specific behavior of the global environment override.
The WEBVIEW2_BROWSER_EXECUTABLE_FOLDER environment variable points to the installed architecture's runtime folder. If a 32-bit application attempts to use WebView2 when the 64-bit version is installed, it will fail because the environment variable points to an incompatible folder. Update the notes to clarify this:
✏️ Suggested note update
- "notes": "Overrides any natively installed Runtime through environment variable 'WEBVIEW2_BROWSER_EXECUTABLE_FOLDER'.",
+ "notes": "Overrides any natively installed Runtime through environment variable 'WEBVIEW2_BROWSER_EXECUTABLE_FOLDER'. This is architecture-specific; applications must match the runtime architecture. Install the 32-bit build (--arch 32bit) to support 32-bit applications.",Also applies to: 27-29
🤖 Prompt for AI Agents
In `@bucket/webview2.json` at line 9, The existing "notes" entry for
WEBVIEW2_BROWSER_EXECUTABLE_FOLDER is ambiguous about architecture
compatibility; update the notes string (the "notes" JSON value in webview2.json)
to explicitly state that the environment variable must point to the runtime that
matches the application's architecture (e.g., a 32-bit app cannot use a 64-bit
WebView2 runtime and vice versa), and add a brief sentence warning that pointing
to an installed runtime of a different architecture will cause WebView2
initialization to fail; apply the same clarification to the other similar note
entries referenced (lines 27-29).
Adds webview2 v144.0.3719.93 in a portable way
Closes: ScoopInstaller/Nonportable#389
Relates: #16985
Tested x86/x64/arm64 installation
Use conventional PR title:
<manifest-name[@version]|chore>: <general summary of the pull request>I have read the Contributing Guide
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.