nb stamped its AUMID + another thread's session purpose onto the user's Edge window (grouped it under the nb taskbar icon)

Overview Files Skills Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 1mo ago ·closed by John Lauer

Symptom

nb stamped taskbar identity onto a window it does not own: the user's Edge work window ended up grouped under the nb taskbar icon, carrying another thread's session text.

Read back from the live window (hwnd 1313174, Chrome_WidgetWin_1, title john/galliaApril - Editor and 2 more pages - Personal - Microsoft Edge):

appId                : Adom.NativeBrowser
relaunchDisplayName  : Adom · pup-bridge · pup-bridge #109 proof of concept: drive a pup-OWNED Chrome p
relaunchCommand      : "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --profile-directory=Default
relaunchIconResource : C:\Users\john\AppData\Local\Microsoft\Edge\User Data\Default\Edge Profile.ico,0

The relaunchCommand and icon are Edge's own. The appId and relaunchDisplayName are nb's, and that display name is the verbatim purpose string from a nbrowser_open_window call made by a DIFFERENT thread (pup-bridge), targeting Chrome, not Edge.

What triggered it

Environment: AdomLapper, native-browser 0.16.14, Adom Bridge relay, 2026-09-12 ~17:20-18:10 CT.

A sequence of nbrowser_open_window calls with explicit profile values:

{"sessionId":"nb109","thread":"pup-bridge","purpose":"...","profile":"chrome:[email protected]","url":"..."}
{"sessionId":"nbp2", "thread":"pup-bridge","purpose":"...","profile":"chrome:[email protected]","url":"..."}
{"sessionId":"extd", "thread":"pup-bridge","purpose":"pup-bridge #109 proof of concept: drive a pup-OWNED Chrome profile ...","profile":"chrome:p_ovsht64p","url":"https://www.arrow.com/"}

Every one asked for a chrome: profile. None asked for Edge. The stamp that landed on the Edge window carries the extd purpose text.

The Edge window was at z:0 (topmost) at the time, which is the likely mechanism: the window the stamp was meant for could not be resolved (the chrome:p_ovsht64p profile was a transient Chrome for Testing instance), and the stamp fell through to the topmost Chrome_WidgetWin_1 window on the desktop. Edge shares that window class with Chrome, so a class-wide "topmost match" will pick Edge.

Expected

Never write PKEY_AppUserModel_ID onto a window nb did not open. If the target window cannot be resolved, fail the stamp and say so rather than stamping the topmost window of the class.
Match on the owning process / profile (and nb's own window tag), not just the Chrome_WidgetWin_1 class, since Edge, Chrome and Chrome for Testing all share it.
A stamp should carry the identity of the window's real app, never another thread's session purpose.

Impact

The user's main AI work environment silently regrouped under the nb icon on the taskbar, and its jump list header showed an unrelated thread's purpose text. This is disruptive to someone who navigates by taskbar grouping.

Workaround applied

desktop_set_window_identity {hwnd, appId:""} cleared the appId and the window returned to Edge's own taskbar group. The relaunchDisplayName could NOT be overwritten (passing "" and passing a replacement string both left the original in place, verified by re-reading desktop_get_window_identity) — worth a look on the ab side too. That text clears when the window is restarted.

1 Reply

John Lauer · 1mo ago

Fixed in nb-bridge 0.16.18 (insiders, landed on AdomLapper, ConfRoomROG and winvm). Your mechanism guess was right, with one more piece: the bridge's window lists threw away every 'Google Chrome for Testing' window, so for pup's CfT profile (chrome:p_ovsht64p) the window the extension had just created was never a candidate at all; the diff found nothing, the title fallback found nothing, and the bounds fallback (any Chrome_WidgetWin_1 window within 24 px of the new window's corner) landed on your maximized Edge window, which was then stamped with the extd purpose. What changed: (1) candidates are only windows of the TARGET browser, told apart by the title suffix (- Microsoft Edge / - Google Chrome / - Google Chrome for Testing) and the owning image (msedge.exe / chrome.exe), so an Edge window is never a candidate for a chrome: profile and vice versa; Chrome for Testing windows are now candidates for chrome: profiles instead of being discarded; the pre-open snapshot, the post-open diff, the spawn correlation and the Layer-1 path all use the same scope. (2) A bounds match must be UNIQUE; two candidates at the same corner is a guess and a guess is never stamped. (3) An unresolved window is left alone: the reply carries hwnd:null and a hint, and nothing is stamped or badged (nb never writes PKEY_AppUserModel_ID onto a window it did not open). (4) The stamp carries the window's own identity only: relaunchDisplayName is now 'Adom Native Browser · Chrome · adom.inc' (app, browser, profile), never a session purpose and never a thread name; who is driving stays in the Activity Log and the taskbar badge. Verified on AdomLapper today: your Edge work window (hwnd 105448786) reads appId MSEdge, relaunchDisplayName Microsoft Edge, before and after nb opens; a chrome:[email protected] open resolved its own window (hwnd 24254030) and reads appId Adom.NativeBrowser, relaunchDisplayName 'Adom Native Browser · Chrome · adom.inc'. The exact CfT repro could not be re-run because pup's window was closed at the time (its profile is not connected), so that branch is proven by its inputs. The ab-side part you noted (relaunchDisplayName cannot be overwritten or cleared through desktop_set_window_identity) is filed on adom/adom-bridge. Closing.

John Lauer closed this · 1mo ago