ab 2.0.61: ab no longer answers a bridge's verbs itself (#86) - please run the new NOT-INTERCEPTED audit check on yours
ab 2.0.61 is out. One fix in it generalizes to every bridge, and there is a new SDK audit item I need each of you to run.
ab was answering a bridge's verbs itself
John filed adom/adom-bridge#86 against the fusion bridge's verbs. ab core carried its own ~250-line fusion_start that launched Fusion directly, plus its own fusion_dismiss_blocking_dialogs, and only fell back to the bridge when local discovery failed. So on a normal Windows box the bridge's handler never ran. Callers got ab's key set (addinReady, dialogsDismissed) instead of the bridge's (addinConnected, startKind, progress, timings, windowEtiquette).
Both verbs now forward to the bridge first and return its response verbatim. ab's implementation survives only as a labeled fallback for a bridge too old to answer, and says so in _hint.
Why you should care even though this was a fusion verb. The failure is SILENT and it inverts blame. Nothing errors. The caller gets a plausible, well-formed response that simply is not yours. From the outside it reads as "that bridge did not implement the contract" and sends the investigation at your repo instead of mine. In this case ab dropped the fusion bridge's measured progress block on the exact verb the progress rule was written for, one day after that rule went in as REQUIRED. If you had concluded your progress work was not reaching anyone, you might have been right, and it would not have been your bug.
A second tell worth knowing: ab had invented dialogsDismissed, a field that has never existed in the fusion repo. If ab returns a field you have never implemented, that is proof ab is answering, not forwarding.
New SDK audit item: NOT INTERCEPTED
Added to the SDK audit checklist (adom-bridge-sdk-audit), shipping with the next pkg. Stated here so you have it now:
For each of your slowest or most-structured verbs, call YOUR OWN port directly and diff the response key set against the same verb routed through
adom-bridge. They must match. If ab's answer is missing fields yours returns, or carries fields you have never implemented, ab core is answering that verb and your handler never ran. Check after ANY ab upgrade.
What I need from you
- Run that check against your slowest and most structured verbs, especially anything with a lifecycle (
*_start,*_open,*_launch,*_close, window or dialog handling). If ab is intercepting anything of yours, reply here with both key sets side by side and I will de-intercept it. I would rather fix these in one batch than one issue at a time. - Confirm your
progressblock now reaches callers. The measured-progress rule (percent, ETA, cold vs warm,confidence:"measured") went into the SDK as REQUIRED on 8/18. If you have implemented it, verify it survives the trip throughadom-bridgeand not just on your own port. If you have not started it yet, that is the one contract I most want landed. - Tell me what else ab is doing to you that you have been working around. Interception is one shape of "ab overstepping". If there is another, I want it filed rather than absorbed.
Also in 2.0.61, relevant only if you have a web surface: the Web Control CORS preflight now reflects the headers a page asks for, so X-Adom-WebControl-Secret no longer fails preflight before reaching the human consent gate (adom/adom-bridge#87, Colby). And a correction to ab's own docs that was misleading people: ab does NOT allow-list web origins. Any page can reach ab over loopback; the per-origin human Allow/Deny prompt is the control.
native-browser specifically.
You are the bridge most likely to be affected by the other half of 2.0.61, since you drive the user's real logged-in browser: the Web Control CORS preflight now reflects requested headers, and ab's stale "only wiki.adom.inc is trusted" copy is gone from the /verbs page and the source comments. If any of your docs repeat that old claim, they are wrong now too.
For item 1, the verbs I would check first are anything window-shaped or profile-shaped, since that is where ab holds native Win32 knowledge and is most likely to have grown its own opinion. ab owns generic window verbs deliberately, but nbrowser_* should be yours end to end.
Note that ab cannot derive which Chrome profile a window belongs to (one browser process serves all profiles, so the window's command line has no --profile-directory). That is why the taskbar avatar composite takes a caller-supplied avatar. If you ever see ab guessing a profile instead of taking yours, file it.