← Commit history

v2.0.585 (insiders): z-order: ab's desktop_clear_window_attention raises the window to z1 (adom-bridge#199), undoing every park at open and after navigation; pup re-bottoms after any attention clear unless the window is the user's foreground. Plus 2.0.584: input beats the birth grace, extension windows park at birth, inset frame.

John Lauer ·fca91336c9 ·1mo ago ·parent e7d54d6
3 files changed +27−2
dev-skills/pup-user-foreground/SKILL.md+23
@@ -115,6 +115,29 @@ loaded gun pointed at the user's click.    HIDE one. A hidden pup window is therefore always pup's own mess, and re-showing it can only    ever give the user back something pup took. +## The birth grace may override FLAGS, never INPUT (2.0.584, John 2026-09-15)++R6's birth grace (8 s, no granted raise) skipped BOTH user signals inside the shared primitive, on the+reasoning that "the taskbar button did not exist yet". It exists the instant the window is shown, and+John's exact objection was "within like 200 ms a human might click the windows taskbar icon to see the+window": that click was undone by the +2.5 s re-assert for the rest of the grace. The 2.0.26 insight+already told us how to tell them apart: a programmatic self-raise happens with IDLE HANDS. So inside the+grace the primitive now still honors "keyboard or mouse input in the last 5 s" as a person (hands off,+10 min memory, logged `[park] ... a person raised it, hands off`), and only the lagging session flags+are ignored. Chrome's PDF pop and first-paint raise still get caught: they happen with idle hands.+The extension lane parks to z-bottom ONCE at birth and schedules no re-assert at all: Chrome never+self-activates a window created with focused:false (measured 2026-09-15: the user's Gmail stayed z0), so+on that lane a re-assert could only ever undo a human. Before 2.0.584 the extension open never parked+at all and every new window sat at z1, right under the user's active window, above all their other work.++**And the park was being undone by ab (adom-bridge#199, 2.0.585).** `desktop_clear_window_attention` raises+the window to z1 on every call (measured on AdomLapper: bottom -> z16, clear -> z1; progress and flash leave+z-order alone). pup calls that clear right after the birth park and after every navigation, so "parked at+z-bottom: true" in the log was true for a few milliseconds. Workaround in `activity::clear_attention`: after+a real clear (the helper already returns early when the window is the user's foreground) send the window+back to the bottom. When you see a window at z1 that the log says was parked, suspect whatever ran AFTER+the park, and measure each step alone: that is how this one was found.+ ## The history that hardened each rule (do not re-learn these live)  | Era | Lesson |
src/extension/manifest.json+1−1
@@ -1,7 +1,7 @@ {   "manifest_version": 3,   "name": "Adom Pup",-  "version": "0.4.1",+  "version": "0.4.2",   "description": "Toolbar for Adom Pup browser windows: annotate, snip, view toggle, dashboard, owner info. Thin trigger surface - the pup bridge is the engine.",   "action": {     "default_popup": "popup.html",
src/extension/worker.js+3−1
@@ -416,7 +416,9 @@ async function pupExtPollOnce() {         for (const w of wins) {           if (w.type !== 'normal') continue;           try {-            await chrome.windows.update(w.id, { state: 'normal', left: wa.left, top: wa.top, width: wa.width, height: wa.height });+            // 2.0.584: the standard inset frame (pup-bridge-dev: work area inset 10 px on every side), so a parked+            // window reads as deliberately placed, never as a maximize that lost. z-order untouched.+            await chrome.windows.update(w.id, { state: 'normal', left: wa.left + 10, top: wa.top + 10, width: Math.max(320, wa.width - 20), height: Math.max(240, wa.height - 20) });             fitted++;           } catch (e) {}         }