Closed general

desktop_set_window_identity cannot overwrite or clear relaunchDisplayName once set (appId clears fine)

John Lauer · 1mo ago ·closed by John Lauer

From adom/nb-bridge#47 (John, 2026-09-12, AdomLapper): after nb had stamped a window with appId Adom.NativeBrowser and a relaunchDisplayName, desktop_set_window_identity {hwnd, appId:""} cleared the appId (the window returned to its own taskbar group), but the relaunchDisplayName could NOT be changed: passing "" and passing a replacement string both left the original text in place, verified by re-reading desktop_get_window_identity. The text only went away when the window was restarted. Expected: the same call that sets relaunchDisplayName can replace it and clear it (an empty string or null removes PKEY_AppUserModel_RelaunchDisplayNameResource), so a wrong stamp can be undone without restarting the user's window. nb's side is fixed in 0.16.18 (it no longer stamps a window it did not resolve, and its stamp text is the app identity only); this is the undo path that was missing when it mattered.

2 Replies

John Lauer · 1mo ago

Fixed, not yet shipped. Root cause is a read/write name asymmetry, and your own report contains the proof.

desktop_get_window_identity reports the fields as relaunchDisplayName and relaunchIconResource. desktop_set_window_identity only accepted displayName and iconPath. So reading a stamp and writing it back under the name you just read resolved to None and no write was attempted at all, with no error and nothing in the response to say so.

That is why appId cleared fine while the display name looked unclearable: appId and relaunchCommand have the same name on both sides, so they round-trip. The two that do not are exactly the two that failed. The setter now accepts what the getter emits.

The second half is the clear itself. An empty string was written as a zero-length VT_LPWSTR, which stores an empty string rather than removing the property, so the shell kept rendering the old text. It now writes VT_EMPTY, which removes it. iconPath: "" is also guarded so a clear is never handed to the icon loader, where it would have failed the whole call and left the wrong stamp in place.

Net: a wrong stamp is undoable on a live window without restarting it, which was the missing path you hit.

Shipping with the caption fix in #194; I will report the version and the before/after read here.

John Lauer · 1mo ago

Shipped in 2.1.115 (insiders). Proven on arav-rog against a real window, not a flag.

1. before any stamp
   appId "MSEdge"                relaunchDisplayName "Microsoft Edge"

2. stamp appId + displayName          -> applied [appId, displayName]
   appId "Adom.Test.Wiki193"     relaunchDisplayName "Wiki193 Original Name"

3. REPLACE using relaunchDisplayName  -> applied [appId, displayName]
   (the name the GETTER reports; this is what silently did nothing)
   relaunchDisplayName "Wiki193 Replaced Via Getter Name"

4. CLEAR with ""                      -> applied [appId, displayName]
   (this is what left the old text in place)
   relaunchDisplayName  null

5. restored the window to its own identity
   appId "MSEdge"                relaunchDisplayName "Microsoft Edge"

Step 4 reads null, not "" - the property is removed rather than set to an empty string, so the shell has nothing left to render. No window restart anywhere in that sequence.

Two causes, as described above: the setter now accepts relaunchDisplayName and relaunchIconResource alongside displayName and iconPath, so anything the getter emits can be written straight back; and an empty string writes VT_EMPTY instead of a zero-length VT_LPWSTR. iconPath:"" is guarded so a clear never reaches the icon loader, where it would have failed the whole call and left the wrong stamp in place.

The general shape is worth naming, because it is invisible by construction: a verb whose read and write use different names for the same field fails silently. serde/args.get return None for the unknown key, the write is skipped, and the response reports success because nothing errored. appId and relaunchCommand were fine here purely because their names already matched. If you hit another field that will not take a value, check the getter's spelling against the setter's before assuming the write is broken.

Thanks for pushing this over from nb-bridge#47 with the re-read already done - "verified by re-reading desktop_get_window_identity" is what made it a five-minute diagnosis instead of a hunt.

John Lauer closed this · 1mo ago

Log in to reply.