Skip to content

[Bug] After a cdp_extension_access_denied failure and re-navigate, evaluate runs in a different tab of the same browser with no error #420

Open

Description

@code-yeongyu

Summary

After a background session's tab hit a cdp_failed / cdp_extension_access_denied error and the agent re-navigated it, a later evaluate in the same session ran against a different page: an unrelated web app in another tab of the same browser, not the page the session had navigated to. Nothing in the result showed that the target had changed, so a script written for one page ran in another. For agents that run in-page scripts, including ones that fill forms or read values, this is a safety hazard.

Environment

  • BrowserSkill CLI bsk driving an Aside/Chromium browser on macOS through the extension.
  • A background session (session start --no-focus), with the user active in other tabs at the same time.

Sequence (sanitized)

  1. bsk session start --json --no-focus gave session S.
  2. bsk navigate https://<sign-in page>/ --session S, then observe: the expected form, with refs for an email textbox and a submit button.
  3. bsk fill @eN <email> --session S and bsk click @eM --session S: both returned ok.
  4. The next observe and screenshot on S failed with cdp_failed: "Could not establish background execution for tab : Cannot access a chrome-extension:// URL of different extension" (reason cdp_extension_access_denied). This is most likely a password manager's autofill frame injected over the email field (cf. observe/snapshot/navigate fail with "Cannot access a chrome-extension:// URL of different extension" when Agent Window tab is born on an extension options page #129).
  5. bsk navigate https://<sign-in page>/ --session S returned ok, and observe showed the sign-in form again.
  6. bsk evaluate "<script reading document.querySelectorAll('input')>" --session S returned the inputs of a different app: a chat app's search box, plus a range input and a file input. The sign-in page's email input was absent.

So between steps 5 and 6, evaluate ran in a different document from the one observe had just reported, with no error and no tab id in the result telling the caller.

Expected

  • evaluate, click and fill in a session always target the session's own tab, the one its last navigate or observe reported. If that tab is gone or unreachable, the command fails with an explicit error and never falls through to another tab.
  • Every result carries the tab_id and URL it actually ran against, so a caller can check the target cheaply.

Actual

evaluate silently ran in a different, user-owned tab.

Workaround we use meanwhile

Before every scripted evaluate or click, re-read the tab's URL and title and stop on any mismatch.

Related

Activity

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions