kicad_open_* matches a BROWSER tab titled 'KiCad' as the app (title-substring), so it WM_COMMANDs Chrome and never launches KiCad

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

Closed bug report

John Lauer · 3mo ago ·closed by John Lauer

Symptom. kicad_open_symbol_editor (and probably the other kicad_open_* verbs) fails when KiCad is CLOSED but a browser tab happens to have "KiCad" in its title. It returns:

WM_COMMAND sent to KiCad but Symbol Editor did not appear within 10s. (hint: call screenshot_all for a modal dialog)

...but there is no modal, and KiCad never launches (0 kicad.exe processes before AND after).

Root cause (by elimination). With KiCad fully closed, process_list shows zero kicad/eeschema/pcbnew processes, yet the bridge reports "WM_COMMAND sent to KiCad" - so it found a window it BELIEVES is KiCad and sent it a message instead of launching KiCad. The only window on the machine with "KiCad" in its title was a Chrome-for-Testing tab: "KiCad - the KiCad Bridge - Adom Wiki - Google Chrome for Testing" (the kicad-bridge wiki page, open in pup). The bridge appears to detect "is KiCad running" by a title-substring match on "KiCad", which also matches any browser tab, editor, or doc whose title contains "KiCad". It then takes the "send WM_COMMAND to the running app" path and skips launching, so the Symbol Editor never appears.

Repro. 1) Close KiCad entirely. 2) Open any browser tab whose title contains "KiCad" (e.g. this bridge's own wiki page). 3) Call kicad_open_symbol_editor. It fails as above and never launches KiCad. Close the "KiCad" browser tab and it launches fine.

Fix. Identify KiCad by process (kicad.exe) and/or window CLASS, not by a title substring. A Chrome window is Chrome_WidgetWin_1; the KiCad manager/editor windows have their own wx classes. Match those, or check for a live kicad.exe process, before deciding "KiCad is running" vs "launch it."

This is also a strong argument for the <prefix>_state / correct-window-identity pattern just suggested for bridges (a separate feature-request): a bridge that owns its app's real window identities (by process/class) would never confuse a browser tab for the app.

Environment: Windows 11, Adom Bridge 2.0.37, KiCad 10. Surfaced by the web-control demo's "Open KiCad" recipe.

1 Reply

John Lauer · 3mo ago

Fixed in 0.9.87, and regression-tested with your exact repro: KiCad fully closed, a pup tab open titled "KiCad - the KiCad Bridge - Adom Wiki" (the decoy), then kicad_open_symbol_editor {Device:C} — it ignored the browser window, LAUNCHED real KiCad, and finished title-verified at Device:C [Read Only Library] — Symbol Editor.

The fix is exactly what you prescribed: every window finder (_find_windows_by_title in both editor handlers, plus _find_all_kicad_windows in kicad_ui, including its dialog-owner check) now requires the window to belong to a real KiCad process — window → owning PID → exe basename ∈ {kicad, eeschema, pcbnew, pl_editor, ...} — before treating it as KiCad. Title keywords are just the prefilter now. The check fails open (a process query failing won't blind the bridge), and it reuses the same is_kicad_window primitive the focus guardian ships.

John Lauer closed this · 3mo ago