fix(windows): load XmlDocument WinRT type before use - #16
Open
mark-nhk wants to merge 1 commit into
Open
Conversation
Thanks for the extension — the sound alerts already solved most of my 'did Claude finish?' problem. This PR fixes the banner half on Windows. ## Problem On Windows, sound notifications work but the system banner never appears. The extension's own diagnostics pinpoint the failure: FAIL 1/2 System banner: Command failed: powershell -NoProfile -Command [...] New-Object : Cannot find type [Windows.Data.Xml.Dom.XmlDocument]: verify that the assembly containing this type is loaded. OK 2/2 Sound: Command ran without error <details> <summary>Full diagnostics output</summary> (dán nguyên log diagnostic của anh vào đây) </details> ## Cause In Windows PowerShell 5.1, each WinRT type must be loaded with the `[Type, Assembly, ContentType=WindowsRuntime]` syntax before first use. The toast command in `lib/system-notification.js` only loads `ToastNotificationManager`, so `New-Object Windows.Data.Xml.Dom.XmlDocument` fails, which cascades into the two follow-up errors (`LoadXml` on null, missing `ToastNotification` constructor). This affects all Windows users of the extension, not a specific machine configuration. ## Fix Add the missing type-load statement for `Windows.Data.Xml.Dom.XmlDocument` before it is instantiated. One line, no behavior change on macOS/Linux. ## Verified Windows 11, Windows PowerShell 5.1: - Reproduced the failure by running the original command manually — same three errors as the diagnostics. - Ran the command with the added type-load line — the banner appears. - (Side note: the snippet only works in Windows PowerShell 5.1; PowerShell 7 cannot load WinRT types this way at all. The extension correctly invokes `powershell`, so this is fine — just worth knowing for future changes.)
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.
Thanks for the extension — the sound alerts already solved most of my 'did Claude finish?' problem. This PR fixes the banner half on Windows.
Problem
On Windows, sound notifications work but the system banner never appears. The extension's own diagnostics pinpoint the failure:
FAIL 1/2 System banner: Command failed: powershell -NoProfile -Command [...] New-Object : Cannot find type [Windows.Data.Xml.Dom.XmlDocument]: verify that the assembly containing this type is loaded.
OK 2/2 Sound: Command ran without error
Cause
In Windows PowerShell 5.1, each WinRT type must be loaded with the
[Type, Assembly, ContentType=WindowsRuntime]syntax before first use. The toast command inlib/system-notification.jsonly loadsToastNotificationManager, soNew-Object Windows.Data.Xml.Dom.XmlDocumentfails, which cascades into the two follow-up errors (LoadXmlon null, missingToastNotificationconstructor).This affects all Windows users of the extension, not a specific machine configuration.
Fix
Add the missing type-load statement for
Windows.Data.Xml.Dom.XmlDocumentbefore it is instantiated. One line, no behavior change on macOS/Linux.Verified
Windows 11, Windows PowerShell 5.1:
powershell, so this is fine — just worth knowing for future changes.)