WSL2: Custom icons break notification and cause it to say "SnoreToast // New Notification" without the real title or message content [specifically in linux filesystem, works fine in mounted volumes]

[jakedowns]

notice how the first, lower notification has obscured the info (it's the same payload as the second one, only it contains "-p"

in the second one, (top one) i force deleted options.p and the rest of the content made it through

for now my workaround is to alter module.exports.mapToWin8 like so:

if (options.icon) {
    if (/^file:\/+/.test(options.icon)) {
      // should parse file protocol URL to path
      options.p = new url.URL(options.icon).pathname
        .replace(/^\/(\w:\/)/, '$1')
        .replace(/\//g, '\\');
    } else {
      options.p = options.icon;
    }
    if(this.isWSL()){
      // without this; notifications just say "SnoreToast//New Notification" and nothing else
      delete options.p;
    }
    delete options.icon;
  }

ideally we could get images working when called from WSL2, but for now, i'm fine with just a SnoreToast icon, as long as i get the info

[mikaelbr]

Odd. Do you know why this happens? Or if this introduces some regressions? I'm preparing a new breaking change release now, but would love a PR of this before I proceed.

[jakedowns]

after testing with both 0.6.0 and the latest 0.7.0 version of SnoreToast, I think it's an issue SnoreToast needs to solve internally with how it handles file paths or something. unfortunately they don't have nice debug flag i can find for getting more info on what's going wrong. - I'll file an issue with the KDE bugtracker (sadly they don't have Issues enabled in their github repo) Filed Bug: https://bugs.kde.org/show_bug.cgi?id=429656

what i found is this:

if i'm in WSL2 env, and i cd into say, /mnt/c/chrome-downloads/ and run snoretoast.exe -p some-pic-in-same-dir.png -m hi -t hi it works, AND shows the icon

however, if i'm in a non-"mnt" folder, like just /root/ and run snoretoast.exe -p some-pic-in-same-dir.png -m hi -t hi it does the thing where if a picture is attached, it just shows "new notification". and shows the text if i drop the photo.

it's the same whether i use the bundled vendor -x64/-x86 exes, or if i download them fresh from snoretoast repo

perhaps it's enough of an edge case that you can ignore my fix for now, and hopefully, down the line, an updated snoretoast.exe or WSL update even will fix it behind the scenes.

if not, and someone else requests it, you have my patch as a starting point for a workaround. (altho, you'd have to extend the conditional, like... if(this.isWSL() && this.wslPathIsMnt()){ to give it some awareness if it's being executed inside a /mnt/ path before deleting the -p flag)

---

(fwiw, the reason my web projects live in the root wsl FS, rather than the /mnt/ drives in the first place, is a workaround in order to use things that rely on inotify events such as a webpack watcher, plus some modest speed gains for most disk io ops. see: https://github.com/microsoft/WSL/issues/4739#issuecomment-582196872)

[sarim]

I'm having the same problem. I guess the problem is with wsl path translation. Obviously a linux path won't work in a windows api. The correct way is to translate the path using wslpath -w LINUXPATH. But I'm guessing toast api doesn't support network path. I tried with both snoretoast and go-toast. Both failed using \\wsl$............. network path. snoretoast even says in its usage

[-p] <image URI>        | Display toast with an image, local files only.

local files only

So its best to delete icon argument.