Skip to content

[Bug]: Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js) #531

Open
Open
[Bug]: Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)#531
Labels
bugSomething isn't working

Description

@kN6jq
kN6jq
opened on Oct 30, 2026

Prerequisites

  • I have searched existing open and closed issues to ensure this is not a duplicate.
  • I have verified that all sensitive data (passwords, tokens, API keys, private URLs, personal info) have been redacted from logs and snippets.

BrowserSkill Version or Commit

0.4.0

Operating System

Windows 10

OS Details and Architecture

Windows 10 Enterprise 22H2, build 19045

Installation Method

Official installer script (AGENT_INSTALL.md)

Browser and Browser Extension Version

Microsoft Edge 156.0.4314.50 extension 0.4.0

Exact Command or API Call

[Bug]: Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)

Minimal Reproduction Steps

Issue draft — Tencent/BrowserSkill

Title

Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)

Body

### Summary

On plain-HTTP (non-secure-context) pages such as an internal tool served over the LAN,
the extension's cooperation content script throws before it registers its message
listener, so every stateful action fails with
`Interaction collection is unavailable in frame 0 (no reply)`.

Navigation, `get-html`, `observe`, `console` and `network` still work — only anything
that needs a cooperation sync (click / fill / press / navigate-with-context) is blocked.
The same flow works fine on `https://` pages and on `http://127.0.0.1`.

This looks identical to the regression described in #528, which is merged into `main`
on 2026-10-30 but is **not contained in any released extension build**. The newest
release, Extension 0.4.0, was tagged 2026-10-29, so users on the store build still hit it.
Filed so the regression is tracked against a shipped version, and to ask when a release
carrying #528 will be available.

### Environment

| Item | Value |
| --- | --- |
| Extension | BrowserSkill 0.4.0 (`emacgiaaaiojkkpkddmmdfhmokgmnikg`), installed from Edge Add-ons, auto-updated to 0.4.0 today |
| Browser | Microsoft Edge 156.0.4314.50 |
| OS | Windows 10 Enterprise 22H2, build 19045 |
| CLI | bsk 0.4.0 (bundled skill 0.4.0, up to date per `bsk update --check`) |
| Daemon | protocol 1.7 (app 0.4.0), `bsk doctor` reports no `fail` rows, `extension connected` ok |
| Target page | `http://192.168.1.116:10088/...` — a Vue + Vite dev server on another host on the LAN |

### Steps to reproduce

1. Serve any page over plain HTTP on a non-loopback host (e.g. `http://192.168.1.116:10088/`),
   with a form on it. No TLS, no special headers.
2. `bsk session start --no-focus --json`, then
   `bsk navigate --session <id> --context <ctx> "http://192.168.1.116:10088/login"`.
3. `bsk cooperate sync --session <id> --json`.

### Expected

`cooperate sync` returns a baseline observation, and `fill` / `click` work.

### Actual

{
"code": "permission_denied",
"message": "Interaction collection is unavailable in frame 0 (no reply)",
"data": { "effect_state": "none", "reason": "cooperation_sync_required" }
}


`bsk cooperate wait` then `cooperate sync` returns `"mode": "unavailable"` and the same
error. `bsk reload` fails the same way, so the page cannot be recovered from inside the
session. A passive `observe --session <id>` on the same tab works and returns the DOM,
which is why this looked like a page problem at first.

### Console evidence

`bsk console --session <id> --json` on the affected tab:

{
"kind": "exception",
"level": "error",
"text": "TypeError: crypto.randomUUID is not a function",
"url": "chrome-extension://emacgiaaaiojkkpkddmmdfhmokgmnikg/content-scripts/cooperation.js",
"line": 1,
"column": 872
}


`crypto.randomUUID()` is gated to secure contexts. On `http://<lan-ip>:<port>` the
property is `undefined`; on `http://127.0.0.1:<port>` and on `https://` it exists.
Remotely hosting the same app on `https` or reaching it through an SSH tunnel to
`http://127.0.0.1:10088` makes everything work with no other change, which pins the
cause to the insecure origin rather than to the page itself.

### Local inspection of the shipped 0.4.0 build

Grepping the installed extension directory
(`...\User Data\Default\Extensions\emacgiaaaiojkkpkddmmdfhmokgmnikg\0.4.0_0`):

content-scripts/cooperation.js -> crypto.randomUUID : 1 hit (unguarded call)
content-scripts/record-frame.js -> createRandomUuid / getRandomValues : 1 hit (guarded helper)


So the fallback helper already ships in 0.4.0, it just is not used by the cooperation
collector — consistent with the description in #528 ("the interaction collector called
`crypto.randomUUID()` before registering its message listener ... reuse the existing
`createRandomUuid()` helper").

### Relationship to existing work

- #163 (merged 2026-09-03) added UUID generation on insecure origins.
- #528 (merged 2026-10-30) restores interaction capture on HTTP pages by reusing
  `createRandomUuid()`.
- Extension 0.4.0 (tagged 2026-10-29) predates #528, so the store build still has the bug.

### What I am asking for

1. Confirmation that #528 will ship in the next extension release.
2. If the next release is far off, a patch release (and a store update) for this one,
   since it makes the extension unusable on internal HTTP tools — a very common case.
3. Optionally, a guard so a failure in a content script is surfaced as a distinct error
   instead of a generic "frame 0 (no reply)", which reads like a page or network problem.

### Workarounds (for other users hitting this)

- Reach the page through loopback: `ssh -N -L 127.0.0.1:10088:<host>:10088 <user>@<host>`
  and use `http://127.0.0.1:10088/...`.
- Or add the origin to `edge://flags/#unsafely-treat-insecure-origin-as-secure` and restart
  the browser (changes a browser security setting, applies to that origin only).
- Or put TLS in front of the dev server, which removes the secure-context restriction
  entirely.

Notes before you submit

  • Attach nothing sensitive: the body above contains only an internal RFC1918 address and
    a dev-server path, no credentials, no tokens.
  • If you prefer to file it as a comment on fix(extension): restore interaction capture on HTTP pages #528 instead of a new issue (they may treat it
    as duplicate), use just the Environment, Console evidence, Local inspection
    and What I am asking for sections and prefix it with "Still reproducible on
    released 0.4.0 — could we get a patch release?".

Expected Behavior

Issue draft — Tencent/BrowserSkill

Title

Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)

Body

### Summary

On plain-HTTP (non-secure-context) pages such as an internal tool served over the LAN,
the extension's cooperation content script throws before it registers its message
listener, so every stateful action fails with
`Interaction collection is unavailable in frame 0 (no reply)`.

Navigation, `get-html`, `observe`, `console` and `network` still work — only anything
that needs a cooperation sync (click / fill / press / navigate-with-context) is blocked.
The same flow works fine on `https://` pages and on `http://127.0.0.1`.

This looks identical to the regression described in #528, which is merged into `main`
on 2026-10-30 but is **not contained in any released extension build**. The newest
release, Extension 0.4.0, was tagged 2026-10-29, so users on the store build still hit it.
Filed so the regression is tracked against a shipped version, and to ask when a release
carrying #528 will be available.

### Environment

| Item | Value |
| --- | --- |
| Extension | BrowserSkill 0.4.0 (`emacgiaaaiojkkpkddmmdfhmokgmnikg`), installed from Edge Add-ons, auto-updated to 0.4.0 today |
| Browser | Microsoft Edge 156.0.4314.50 |
| OS | Windows 10 Enterprise 22H2, build 19045 |
| CLI | bsk 0.4.0 (bundled skill 0.4.0, up to date per `bsk update --check`) |
| Daemon | protocol 1.7 (app 0.4.0), `bsk doctor` reports no `fail` rows, `extension connected` ok |
| Target page | `http://192.168.1.116:10088/...` — a Vue + Vite dev server on another host on the LAN |

### Steps to reproduce

1. Serve any page over plain HTTP on a non-loopback host (e.g. `http://192.168.1.116:10088/`),
   with a form on it. No TLS, no special headers.
2. `bsk session start --no-focus --json`, then
   `bsk navigate --session <id> --context <ctx> "http://192.168.1.116:10088/login"`.
3. `bsk cooperate sync --session <id> --json`.

### Expected

`cooperate sync` returns a baseline observation, and `fill` / `click` work.

### Actual

{
"code": "permission_denied",
"message": "Interaction collection is unavailable in frame 0 (no reply)",
"data": { "effect_state": "none", "reason": "cooperation_sync_required" }
}


`bsk cooperate wait` then `cooperate sync` returns `"mode": "unavailable"` and the same
error. `bsk reload` fails the same way, so the page cannot be recovered from inside the
session. A passive `observe --session <id>` on the same tab works and returns the DOM,
which is why this looked like a page problem at first.

### Console evidence

`bsk console --session <id> --json` on the affected tab:

{
"kind": "exception",
"level": "error",
"text": "TypeError: crypto.randomUUID is not a function",
"url": "chrome-extension://emacgiaaaiojkkpkddmmdfhmokgmnikg/content-scripts/cooperation.js",
"line": 1,
"column": 872
}


`crypto.randomUUID()` is gated to secure contexts. On `http://<lan-ip>:<port>` the
property is `undefined`; on `http://127.0.0.1:<port>` and on `https://` it exists.
Remotely hosting the same app on `https` or reaching it through an SSH tunnel to
`http://127.0.0.1:10088` makes everything work with no other change, which pins the
cause to the insecure origin rather than to the page itself.

### Local inspection of the shipped 0.4.0 build

Grepping the installed extension directory
(`...\User Data\Default\Extensions\emacgiaaaiojkkpkddmmdfhmokgmnikg\0.4.0_0`):

content-scripts/cooperation.js -> crypto.randomUUID : 1 hit (unguarded call)
content-scripts/record-frame.js -> createRandomUuid / getRandomValues : 1 hit (guarded helper)


So the fallback helper already ships in 0.4.0, it just is not used by the cooperation
collector — consistent with the description in #528 ("the interaction collector called
`crypto.randomUUID()` before registering its message listener ... reuse the existing
`createRandomUuid()` helper").

### Relationship to existing work

- #163 (merged 2026-09-03) added UUID generation on insecure origins.
- #528 (merged 2026-10-30) restores interaction capture on HTTP pages by reusing
  `createRandomUuid()`.
- Extension 0.4.0 (tagged 2026-10-29) predates #528, so the store build still has the bug.

### What I am asking for

1. Confirmation that #528 will ship in the next extension release.
2. If the next release is far off, a patch release (and a store update) for this one,
   since it makes the extension unusable on internal HTTP tools — a very common case.
3. Optionally, a guard so a failure in a content script is surfaced as a distinct error
   instead of a generic "frame 0 (no reply)", which reads like a page or network problem.

### Workarounds (for other users hitting this)

- Reach the page through loopback: `ssh -N -L 127.0.0.1:10088:<host>:10088 <user>@<host>`
  and use `http://127.0.0.1:10088/...`.
- Or add the origin to `edge://flags/#unsafely-treat-insecure-origin-as-secure` and restart
  the browser (changes a browser security setting, applies to that origin only).
- Or put TLS in front of the dev server, which removes the secure-context restriction
  entirely.

Notes before you submit

  • Attach nothing sensitive: the body above contains only an internal RFC1918 address and
    a dev-server path, no credentials, no tokens.
  • If you prefer to file it as a comment on fix(extension): restore interaction capture on HTTP pages #528 instead of a new issue (they may treat it
    as duplicate), use just the Environment, Console evidence, Local inspection
    and What I am asking for sections and prefix it with "Still reproducible on
    released 0.4.0 — could we get a patch release?".

Actual Behavior

Issue draft — Tencent/BrowserSkill

Title

Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)

Body

### Summary

On plain-HTTP (non-secure-context) pages such as an internal tool served over the LAN,
the extension's cooperation content script throws before it registers its message
listener, so every stateful action fails with
`Interaction collection is unavailable in frame 0 (no reply)`.

Navigation, `get-html`, `observe`, `console` and `network` still work — only anything
that needs a cooperation sync (click / fill / press / navigate-with-context) is blocked.
The same flow works fine on `https://` pages and on `http://127.0.0.1`.

This looks identical to the regression described in #528, which is merged into `main`
on 2026-10-30 but is **not contained in any released extension build**. The newest
release, Extension 0.4.0, was tagged 2026-10-29, so users on the store build still hit it.
Filed so the regression is tracked against a shipped version, and to ask when a release
carrying #528 will be available.

### Environment

| Item | Value |
| --- | --- |
| Extension | BrowserSkill 0.4.0 (`emacgiaaaiojkkpkddmmdfhmokgmnikg`), installed from Edge Add-ons, auto-updated to 0.4.0 today |
| Browser | Microsoft Edge 156.0.4314.50 |
| OS | Windows 10 Enterprise 22H2, build 19045 |
| CLI | bsk 0.4.0 (bundled skill 0.4.0, up to date per `bsk update --check`) |
| Daemon | protocol 1.7 (app 0.4.0), `bsk doctor` reports no `fail` rows, `extension connected` ok |
| Target page | `http://192.168.1.116:10088/...` — a Vue + Vite dev server on another host on the LAN |

### Steps to reproduce

1. Serve any page over plain HTTP on a non-loopback host (e.g. `http://192.168.1.116:10088/`),
   with a form on it. No TLS, no special headers.
2. `bsk session start --no-focus --json`, then
   `bsk navigate --session <id> --context <ctx> "http://192.168.1.116:10088/login"`.
3. `bsk cooperate sync --session <id> --json`.

### Expected

`cooperate sync` returns a baseline observation, and `fill` / `click` work.

### Actual

{
"code": "permission_denied",
"message": "Interaction collection is unavailable in frame 0 (no reply)",
"data": { "effect_state": "none", "reason": "cooperation_sync_required" }
}


`bsk cooperate wait` then `cooperate sync` returns `"mode": "unavailable"` and the same
error. `bsk reload` fails the same way, so the page cannot be recovered from inside the
session. A passive `observe --session <id>` on the same tab works and returns the DOM,
which is why this looked like a page problem at first.

### Console evidence

`bsk console --session <id> --json` on the affected tab:

{
"kind": "exception",
"level": "error",
"text": "TypeError: crypto.randomUUID is not a function",
"url": "chrome-extension://emacgiaaaiojkkpkddmmdfhmokgmnikg/content-scripts/cooperation.js",
"line": 1,
"column": 872
}


`crypto.randomUUID()` is gated to secure contexts. On `http://<lan-ip>:<port>` the
property is `undefined`; on `http://127.0.0.1:<port>` and on `https://` it exists.
Remotely hosting the same app on `https` or reaching it through an SSH tunnel to
`http://127.0.0.1:10088` makes everything work with no other change, which pins the
cause to the insecure origin rather than to the page itself.

### Local inspection of the shipped 0.4.0 build

Grepping the installed extension directory
(`...\User Data\Default\Extensions\emacgiaaaiojkkpkddmmdfhmokgmnikg\0.4.0_0`):

content-scripts/cooperation.js -> crypto.randomUUID : 1 hit (unguarded call)
content-scripts/record-frame.js -> createRandomUuid / getRandomValues : 1 hit (guarded helper)


So the fallback helper already ships in 0.4.0, it just is not used by the cooperation
collector — consistent with the description in #528 ("the interaction collector called
`crypto.randomUUID()` before registering its message listener ... reuse the existing
`createRandomUuid()` helper").

### Relationship to existing work

- #163 (merged 2026-09-03) added UUID generation on insecure origins.
- #528 (merged 2026-10-30) restores interaction capture on HTTP pages by reusing
  `createRandomUuid()`.
- Extension 0.4.0 (tagged 2026-10-29) predates #528, so the store build still has the bug.

### What I am asking for

1. Confirmation that #528 will ship in the next extension release.
2. If the next release is far off, a patch release (and a store update) for this one,
   since it makes the extension unusable on internal HTTP tools — a very common case.
3. Optionally, a guard so a failure in a content script is surfaced as a distinct error
   instead of a generic "frame 0 (no reply)", which reads like a page or network problem.

### Workarounds (for other users hitting this)

- Reach the page through loopback: `ssh -N -L 127.0.0.1:10088:<host>:10088 <user>@<host>`
  and use `http://127.0.0.1:10088/...`.
- Or add the origin to `edge://flags/#unsafely-treat-insecure-origin-as-secure` and restart
  the browser (changes a browser security setting, applies to that origin only).
- Or put TLS in front of the dev server, which removes the secure-context restriction
  entirely.

Notes before you submit

  • Attach nothing sensitive: the body above contains only an internal RFC1918 address and
    a dev-server path, no credentials, no tokens.
  • If you prefer to file it as a comment on fix(extension): restore interaction capture on HTTP pages #528 instead of a new issue (they may treat it
    as duplicate), use just the Environment, Console evidence, Local inspection
    and What I am asking for sections and prefix it with "Still reproducible on
    released 0.4.0 — could we get a patch release?".

Relevant Logs / Diagnostics Output

# Issue draft — Tencent/BrowserSkill

## Title


Extension 0.4.0: interaction capture is dead on plain-HTTP intranet pages (crypto.randomUUID in cooperation.js)


## Body


### Summary

On plain-HTTP (non-secure-context) pages such as an internal tool served over the LAN,
the extension's cooperation content script throws before it registers its message
listener, so every stateful action fails with
`Interaction collection is unavailable in frame 0 (no reply)`.

Navigation, `get-html`, `observe`, `console` and `network` still work — only anything
that needs a cooperation sync (click / fill / press / navigate-with-context) is blocked.
The same flow works fine on `https://` pages and on `http://127.0.0.1`.

This looks identical to the regression described in #528, which is merged into `main`
on 2026-10-30 but is **not contained in any released extension build**. The newest
release, Extension 0.4.0, was tagged 2026-10-29, so users on the store build still hit it.
Filed so the regression is tracked against a shipped version, and to ask when a release
carrying #528 will be available.

### Environment

| Item | Value |
| --- | --- |
| Extension | BrowserSkill 0.4.0 (`emacgiaaaiojkkpkddmmdfhmokgmnikg`), installed from Edge Add-ons, auto-updated to 0.4.0 today |
| Browser | Microsoft Edge 156.0.4314.50 |
| OS | Windows 10 Enterprise 22H2, build 19045 |
| CLI | bsk 0.4.0 (bundled skill 0.4.0, up to date per `bsk update --check`) |
| Daemon | protocol 1.7 (app 0.4.0), `bsk doctor` reports no `fail` rows, `extension connected` ok |
| Target page | `http://192.168.1.116:10088/...` — a Vue + Vite dev server on another host on the LAN |

### Steps to reproduce

1. Serve any page over plain HTTP on a non-loopback host (e.g. `http://192.168.1.116:10088/`),
   with a form on it. No TLS, no special headers.
2. `bsk session start --no-focus --json`, then
   `bsk navigate --session <id> --context <ctx> "http://192.168.1.116:10088/login"`.
3. `bsk cooperate sync --session <id> --json`.

### Expected

`cooperate sync` returns a baseline observation, and `fill` / `click` work.

### Actual


{
  "code": "permission_denied",
  "message": "Interaction collection is unavailable in frame 0 (no reply)",
  "data": { "effect_state": "none", "reason": "cooperation_sync_required" }
}


`bsk cooperate wait` then `cooperate sync` returns `"mode": "unavailable"` and the same
error. `bsk reload` fails the same way, so the page cannot be recovered from inside the
session. A passive `observe --session <id>` on the same tab works and returns the DOM,
which is why this looked like a page problem at first.

### Console evidence

`bsk console --session <id> --json` on the affected tab:


{
  "kind": "exception",
  "level": "error",
  "text": "TypeError: crypto.randomUUID is not a function",
  "url": "chrome-extension://emacgiaaaiojkkpkddmmdfhmokgmnikg/content-scripts/cooperation.js",
  "line": 1,
  "column": 872
}


`crypto.randomUUID()` is gated to secure contexts. On `http://<lan-ip>:<port>` the
property is `undefined`; on `http://127.0.0.1:<port>` and on `https://` it exists.
Remotely hosting the same app on `https` or reaching it through an SSH tunnel to
`http://127.0.0.1:10088` makes everything work with no other change, which pins the
cause to the insecure origin rather than to the page itself.

### Local inspection of the shipped 0.4.0 build

Grepping the installed extension directory
(`...\User Data\Default\Extensions\emacgiaaaiojkkpkddmmdfhmokgmnikg\0.4.0_0`):


content-scripts/cooperation.js   ->  crypto.randomUUID          : 1 hit   (unguarded call)
content-scripts/record-frame.js  ->  createRandomUuid / getRandomValues : 1 hit (guarded helper)


So the fallback helper already ships in 0.4.0, it just is not used by the cooperation
collector — consistent with the description in #528 ("the interaction collector called
`crypto.randomUUID()` before registering its message listener ... reuse the existing
`createRandomUuid()` helper").

### Relationship to existing work

- #163 (merged 2026-09-03) added UUID generation on insecure origins.
- #528 (merged 2026-10-30) restores interaction capture on HTTP pages by reusing
  `createRandomUuid()`.
- Extension 0.4.0 (tagged 2026-10-29) predates #528, so the store build still has the bug.

### What I am asking for

1. Confirmation that #528 will ship in the next extension release.
2. If the next release is far off, a patch release (and a store update) for this one,
   since it makes the extension unusable on internal HTTP tools — a very common case.
3. Optionally, a guard so a failure in a content script is surfaced as a distinct error
   instead of a generic "frame 0 (no reply)", which reads like a page or network problem.

### Workarounds (for other users hitting this)

- Reach the page through loopback: `ssh -N -L 127.0.0.1:10088:<host>:10088 <user>@<host>`
  and use `http://127.0.0.1:10088/...`.
- Or add the origin to `edge://flags/#unsafely-treat-insecure-origin-as-secure` and restart
  the browser (changes a browser security setting, applies to that origin only).
- Or put TLS in front of the dev server, which removes the secure-context restriction
  entirely.


## Notes before you submit

- Attach nothing sensitive: the body above contains only an internal RFC1918 address and
  a dev-server path, no credentials, no tokens.
- If you prefer to file it as a comment on #528 instead of a new issue (they may treat it
  as duplicate), use just the **Environment**, **Console evidence**, **Local inspection**
  and **What I am asking for** sections and prefix it with "Still reproducible on
  released 0.4.0 — could we get a patch release?".

Is this a regression?

No / Not sure

Last Known Working Version (if regression)

No response

Additional Context

No response

Activity

  1. kN6jq
    added
    bugSomething isn't working
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions