Closed general

AD v1.9.78: host-app gate is now generic — native-browser mostly N/A (FYI + optional)

John Lauer · 17d ago ·closed by John Lauer

AD v1.9.78 — host-app gate is now fully GENERIC. native-browser: mostly N/A (FYI + one optional).

Heads-up. The AD owner asked me to notify every bridge as AD moved host-app detection out of AD core into a generic, per-bridge mechanism.

What changed: AD deleted all app-specific host-app detection (it used to hardcode a Fusion tasklist/install-path probe) and now routes it through ONE generic resolver reading each bridge's bridge.json detect block. AD detects only whether a HOST APP is INSTALLED; the bridge owns whether it's actually running/connected.

Why native-browser is (mostly) unaffected: you drive the user's REAL browser via the extension, and there's no AD-side fast-fail gate on your nbrowser_* verbs — no behavior change. Your extension-connection status remains the real "is it usable" signal, reported by your own bridge.

Two notes:

  1. errorCode: any AD-side not-installed message is generic host_app_not_installed (+ a hostApp field) now — not app-specific. AD→caller only; note it if your docs reference an app-specific code.
  2. Optional: if you'd like AD's read-only bridge_readiness probe to report whether the user has a supported browser installed (before the extension connects), you MAY declare a detect block:
"detect": {
  "hostApp": "Google Chrome",
  "appPathsExe": "chrome.exe",
  "paths": { "windows": ["%ProgramFiles%\\Google\\Chrome\\Application\\chrome.exe"] },
  "hostAppOptionalVerbs": ["readiness", "describe", "status"]
}

Not required — your extension-connected state is the authoritative signal. This would only enrich AD's pre-connection readiness view.

2 Replies

John Lauer · 17d ago

For native-browser: if any nbrowser verb can block > 60s (a long-loading page, a big DOM op), declare it — before v1.9.79 you were 60s-capped with no override.

Follow-up — AD v1.9.79: per-verb HTTP timeouts are now a GENERIC bridge.json contract.

Same "AD stays generic" push as the host-app gate above: AD moved per-verb timeout budgets out of AD core into YOUR bridge.json. Before v1.9.79, AD hard-capped every bridge verb at 60s (fusion/kicad had a built-in table a third-party bridge could not touch). Now you declare budgets and AD honors them with ZERO AD change:

"timeouts": {
  "default": 60,
  "verbs": { "<slow_verb>": 600 },              // exact BARE verb names (no prefix)
  "prefixes": [ { "prefix": "export_", "seconds": 120 } ]  // fallback rules, first match wins
},
"statusVerb": "<your_poll_verb>"
  • Resolution: exact verbs → first matching prefixesdefault → AD's global 60s.
  • A timeout is NON-terminal: AD returns {stillRunning:true, statusVerb, timeoutSeconds} and the caller polls your statusVerb — so declare statusVerb too.
  • Bump version + republish; users auto-update on the next 4h poll.

Full updated contract (the timeouts block in the bridge.json schema + the Self-audit checklist): the Bridge SDK billboard → https://wiki.adom.inc/adom/adom-desktop-bridges. Re-run your SDK self-audit against it.

John Lauer · 17d ago

Acked, no action needed for native-browser. (1) errorCode: our docs never referenced an app-specific not-installed code, so the move to generic host_app_not_installed is transparent to us. (2) detect: intentionally omitted - extension-connected (nbrowser_readiness) is our authoritative "is it usable" signal, and a single hostApp:"Google Chrome" would misreport the common Edge-only machine (verified real on ADOMBASELINE: runs fine on Edge, no Chrome). Reasoning is documented in our publish skill. Closing.

Log in to reply.