Use this checklist whenever an image search engine integration regresses. The flow assumes you have Chrome MCP available for ad‑hoc testing, and the NooBox debug server + debug build wiring that streams HTML/results back to disk.
-
Smoke-test via Chrome MCP
- Launch a new page with the failing engine URL (e.g., Yandex
https://yandex.com/images/search?url=...). - Use the MCP tools (
navigate,take_snapshot, DOM inspectors) to capture the selectors, embedded state (data-state/data-bem), redirects (retpath), and any JSON blobs the page exposes. - Note keywords/tiles/site-lists you expect to scrape. Save example URLs and DOM snippets.
- Launch a new page with the failing engine URL (e.g., Yandex
-
Run the Extension in Debug Mode
npm run build:v3:debug(orbuild:v2:debugif working on MV2). Debug builds are unminified and auto-enabledebugMode.- Reload the extension in Chrome; alternatively, queue
{"type":"reload"}through the debug server once it is running (next step).
-
Start/Verify the Debug Server
npm --prefix debug-server start(port 3030 by default). Confirm/statusreturns an active heartbeat.- On each startup the server archives the previous
debug-server/logscontents intodebug-server/logs/history/<timestamp>/, so you always start with a clean slate. - The server writes inbound HTML to
debug-server/logs/html/*.htmland parsed payloads todebug-server/logs/results/*-parsed.json.
-
Trigger Remote Commands
- POST to
/commandwith{"type":"imageSearch","payload":{"url":"<test image>"}}(or includebase64OrUrlif you have a raw blob). The extension now runs the full tab-per-engine flow for you. - Wait for the extension heartbeat loop to pick it up; monitor
/resultsuntil the command lands. - Each result entry provides:
htmlPath→ raw HTML we fetched.parsedPath→ the adapter’s structured output.parsedSummary→ counts of keywords/results for quick sanity.
- When an engine re-posts with
override: true, the debug server replaces its previous row so/resultsalways reflects the freshest payload.
- POST to
-
Inspect Captured HTML/JSON
- Open the
htmlPathfile to analyze class names, embedded React state, redirect flows, etc. Beautify if necessary (npx js-beautify file.html). - Open the
parsedPathJSON to see what the adapter produced. Compare against expected keywords/results from MCP observations.
- Open the
-
Update the Adapter
- Modify
src/background/imageSearch/<engine>ImageSearch.tsto:- Follow intermediate shells (e.g.,
retpath) before scraping. - Prefer structured state (React/JSON) when available, falling back to DOM selectors.
- Normalize URLs via
absolutizeand unwrap redirectors. - Populate metadata (
imageInfo, keywords, descriptions) expected by the UI.
- Follow intermediate shells (e.g.,
- Rebuild the debug bundle and reload the extension (repeat steps 2–4).
- Modify
-
Iterate Until Parsed Output Looks Good
- Use
/results+ stored JSON to verify keyword/result counts. - When debugging Google/Bing, you can trigger the Chrome debugger auto-focus flows (enabled in debug builds). Watch for the pending-focus pill in
searchResult.htmlbefore the tab is focused. - If parsing still fails, loop back to MCP to reconfirm selectors/state and adjust the adapter again.
- For engines that block inline script injection (e.g., Bing), use the debug-server
engineEvalcommand ({"type":"engineEval","payload":{"engine":"bing","cursor":<cursor>,"code":"...expression..."}}) to run CDP-powered evaluations. These logs show up underdebug-server/logs/results/*-parsed.jsonso you can confirm selectors like.pigc .pritextemit the expected dimensions. - Useful snippet to capture Bing counts during testing:
(() => ({ images: document.querySelectorAll('a.richImgLnk').length, pages: document.querySelectorAll('.insights.rr .pginlv ul li .pigc .richImgLnk').length }))()
- Use
-
Finalize
- Once satisfied, run a production build (
npm run build:v3/build:v2) to ensure debug-only code is not bundled. - Document any new selectors/state fields the engine now depends on.
- Once satisfied, run a production build (
- Always run exploratory work in debug builds so the
chrome.debuggerfocus helpers are available. Watch the pending-focus pill insearchResult.html; it must appear before the backend focuses Google/Bing and disappear once control returns. - Bing (and other CSP-heavy engines) cannot accept inline injections, so rely on the debug server’s
engineEvalcommand:The response shows up undercurl -X POST -H 'Content-Type: application/json' \ -d '{"type":"engineEval","payload":{"engine":"bing","cursor":<cursor>,"code":"(() => ({images: document.querySelectorAll(\"a.richImgLnk\").length, pages: document.querySelectorAll(\".insights.rr .pginlv ul li .pigc .richImgLnk\").length}))()"}}' \ http://localhost:3030/commanddebug-server/logs/results/*-parsed.json, letting you confirm selectors like.pigc,.pritext, and.richImgLnkbefore you touch the adapter. - When Bing/Google runs stall, focus the engine tab via the debugger (triggered automatically by
pendingFocus) and scroll to the bottom to hydrate thumbnails, then use/resultsto confirmpages > 0and that metadata (dimensions, site text) matches DOM snippets such as.pirc .pritext. - For thorough repros, kick off searches with known assets (e.g.,
https://ainoob.com/api/getImage/4b2fc4bd-7782-4938-bec8-63b68a348a70) and monitordebug-server/logs/html/*.htmlfor the captured DOM.