10.0.301: HTML launch (direct=1) fails with Error #204 on cold start, 10.0.286 works

Ui.Vision Bug Reports
1

Summary
Since the Web Store started serving 10.0.301 (first seen 2026-10-03 ~21:50 UTC), launching a macro by opening its exported HTML file with ?direct=1 fails on a cold browser start. The page shows “Error #204: It seems UI.Vision RPA is not installed yet - or you need to turn on Allow access to file URLs”. No macro runs and no log is saved. Allow access to file URLs is on (newAllowFileAccess: true). The same profile and HTML file on 10.0.286 work.

Environment

  • Chromium 152.0.7977.82 (Ubuntu snap, arm64) and Chromium 154.0.8037.57 (Ubuntu snap, x86_64), both affected.
  • Launch: chromium --profile-directory=… “file:///…/macro.html?direct=1&closeBrowser=1&closeKantu=1&savelog=…”
  • 10.0.301 CRX sha256 ef6699aaef8c24aeaa26440649a50d628264a9f21371362961aa69693abbe407

Reproduction

  1. Take a profile with ui.vision 10.0.301 installed and file URL access on.
  2. Start the browser cold with a macro HTML file and ?direct=1.
  3. The HTML page polls for data-kantu on , never sees it, and shows Error #204 after its retries.

Same machine and macro on 10.0.286: the macro plays (2 of 2 cold launches). On 10.0.301: Error #204 (4 of 4).

What we observed

  • Chromium’s stderr on the failing launches shows DidStartWorkerFail gcbalfbdmfieckjlnblleoemohcganoc: 5.
  • Toggling the extension off and on in chrome://extensions makes launches work in that browser session only. The next cold start fails again.
  • Making the HTML page retry for 30 s instead of ~2 s does not help.

Likely cause (read from the code, not confirmed in a console)

  • In 10.0.286, content_script.js sets data-kantu on document.documentElement as soon as it runs, and only afterwards reads config.
  • In 10.0.301, data-kantu is set only inside jt().then(…), i.e. after get(“config”) resolves (around switch(Rt(“file:”===window.location.protocol?!!t.allowRunFromFileSchema:…).
  • If the background service worker has not started (see the stderr line), that promise never resolves, so the page is never marked and the launcher reports #204.

Request
Could you restore the 10.0.286 behaviour of setting data-kantu immediately (or not make it depend on the service worker), and let us know which version carries the fix? We run unattended command-line launches, so an automatic update that breaks the launch path stops every job at once. Is there a supported way to pin the extension version?

Thanks. The 10.0.281 issue was fixed very quickly last time and we appreciate it.

2

Thanks for the report, we are looking into it asap.

3
4

10.0.301 launches fine with the HTML launcher a current UI.Vision export generates. Our failing macros were exported by an older version, and their launcher block loses a timing race against 10.0.301.

Same profiles on 10.0.301, same browser session:

  • A macro carrying the newer launcher block (setTimeout(main, 500) before the first check, parseInt on the reload counter, noImport: false in the kantuSaveAndRunMacro detail) runs normally.
  • A macro carrying the older block (main() called immediately, no parseInt) shows Error #204 every time.
  • Swapping the newer block into the failing macro file, with the macro table untouched, makes it run.

Two observations that may be useful to you:

  1. In the older launcher, var count = 1 + (url.searchParams.get(‘reload’) || 0) concatenates strings. After the first reload count becomes “11”, which is greater than MAX_TRY, so it gives up after one reload, about one second, instead of three.
  2. 10.0.301 seems to set data-kantu later than 10.0.286 did. In 10.0.286 it was set as soon as the content script ran; in 10.0.301 it’s set after get(“config”) resolves. The older launcher’s one-second window is enough for 286 but not for 301.

Since many users have macros exported by older versions, setting data-kantu immediately again, as 10.0.286 did, would keep old exports working. Failing that, a release note saying to re-export, or replace the launcher block, would help.

Sorry for the false lead in the first post, and thanks again.

5

Thanks for the additional info!

Correct! We are looking into this.