Extension lane can't click or type on CSP / Trusted Types pages (Google Admin, Calendar); the only fix today evicts other threads

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed feature request

John Lauer · 1mo ago ·closed by John Lauer

Summary

On the default extension lane, pup cannot act on any page that blocks string eval (strict CSP or Trusted Types). Google Admin (admin.google.com) and Google Calendar (calendar.google.com) are two everyday examples. The lane has no input verbs, and pup_eval is the only other way to click, so on these pages pup can navigate and screenshot but cannot touch anything.

The only escape today is lane:"cdp", and on the shared adom-you profile that relaunches the browser and closes every other thread's extension-lane windows. The reverse also happens: when another thread reopens an extension-lane window, the CDP browser dies under you (browser_gone). A separate CDP profile avoids the eviction but is not signed in to anything, so the human has to type their password again.

Net effect for the user: "open a pup window and change one Google setting" is not possible without either closing another thread's work or a fresh sign-in.

Environment

Windows (AdomLapper), Adom Bridge 2.1.118
pup (puppeteer bridge) 2.0.590, extensionLane.workerVersion 2.0.590
Shared adom-you profile, signed in to Google Workspace

Repro

pup_open_window {sessionId:"cal", url:"https://calendar.google.com/calendar/r/settings"} (no lane). Opens fine, signed in, screenshot shows the settings page.
pup_eval {sessionId:"cal", expression:"location.host"}
- Actual: eval_failed: "Evaluating a string as JavaScript violates this document's Trusted Type assignment requirements."
Same on admin.google.com: "Evaluating a string as JavaScript violates the following Content Security Policy directive because 'unsafe-eval' is not an allowed source of script".
pup_input_dispatch (click or key) on the same window:
- Actual: lane_needs_cdp: "window is on the extension lane (no debug port); this verb needs CDP".
pup_open_window {lane:"cdp", reason:"..."} on adom-you: works, but every other extension-lane window (other threads) is closed. When one of those threads reopened its window a few minutes later, the CDP window went dead with browser_gone ("the browser behind this window is not connected").

Expected

Clicking a button or choosing a dropdown option in a signed-in pup window works on the default lane, without evicting other threads and without a new sign-in.

Proposal

Add DOM input verbs to the extension lane that do not go through page-world string eval, so page CSP and Trusted Types do not apply:

Run the action from the extension's ISOLATED world, e.g. chrome.scripting.executeScript({world:"ISOLATED", func, args}) with a real function (not a string). Suggested verbs: pup_click {selector | text}, pup_type {selector, text}, pup_select {selector, value | label}. These produce isTrusted:false events, which is enough for ordinary buttons, links and Material selects (verified on Amex: a plain element.click() opened a row menu that trusted CDP clicks did not).
Optionally, where a page needs trusted input, a short-lived chrome.debugger attach for Input.dispatchMouseEvent on one tab, released immediately, as the lane already does for its screenshot fallback.
Make lane_needs_cdp hints point to these verbs before suggesting lane:"cdp".

Separately worth considering: a CDP-lane window that does not evict the shared profile's other windows, or a documented way for a separate CDP profile to reuse the adom-you sign-in.

Related: #113 (extension lane per profile) covers separate profiles on the extension lane. This issue is about input on the existing adom-you extension lane, which is needed even with one profile.

Found while

Doing routine Google Workspace admin for a user (archive a user, add a user, change a Calendar setting). Every step stalled on this gap and fell back to the user's own browser.

2 Replies

John Lauer · 1mo ago

Thanks for the precise repro. Status as of 2.0.592 (insiders), with each of your asks measured on AdomLapper on your own pages:

Input on the extension lane already existed at the version you reported: since 2.0.578 pup_click, pup_hover, pup_type, pup_press_key, pup_scroll, pup_fill and pup_input_dispatch all serve extension-lane windows through nbe's DevTools driver (chrome.debugger attached to one tab on demand, no port, no automation flag). The lane_needs_cdp you saw on pup_input_dispatch is what an older worker answered; on 2.0.590 and later that verb returns ok on the lane (verified on google.com, which enforces Trusted Types, and now on calendar.google.com/calendar/r/settings in a background adom-you window: pup_click {text:"Language and region"} opened the section).
pup_eval's Trusted Types refusal was a real gap: the DevTools fallback matched only the CSP wording ("Content Security Policy", "unsafe-eval"), not "violates this document's Trusted Type assignment requirements". 2.0.591 widens it. Measured on the Calendar settings page: pup_eval {expr:"location.host + document.title"} now returns "calendar.google.com | Adom - Calendar - General settings".
pup_select {selector, value | label} is new in 2.0.592, both lanes, background, through DevTools evaluate (page CSP and Trusted Types cannot refuse it), firing input and change for framework-bound selects; option_not_found lists the first 30 options. Measured: the-internet.herokuapp.com/dropdown, label "Option 2", page reads the value back as 2. For custom dropdowns (Material, React Select) the hint says: pup_click the control, then pup_click the option by text.
The lane_needs_cdp hints now name these verbs before lane:"cdp".

On the CDP-beside-extension question: not on the same profile (one Chrome per profile directory), and a second profile is not signed in; with input and eval covered on the extension lane there is no reason left to reopen with lane:"cdp" for these pages. #113 stays the home for per-profile extension lanes. Closing.

John Lauer closed this · 1mo ago

John Lauer · 1mo ago

Confirmed on 2.0.594, AdomLapper: the Calendar change works end to end in a normal extension-lane pup window. pup_eval reads the page, pup_click {selector} opens the Material dropdown, pup_press_key ArrowDown + Enter selects the option. Thanks for the fast turnaround.

One gotcha worth putting in the pup skill for anyone driving Google settings, because it looks exactly like a pup bug:

Some Google settings pop a confirmation dialog, and the change is NOT saved until you click it. For Calendar > Event settings > "Add invitations to my calendar", choosing "Only if the sender is known" shows:

Change how invitations are added? This doesn't affect invitations you've already received. You'll receive emails for any invitations from unknown senders. [Cancel] [OK]

Until OK is clicked, the dropdown already displays the new value (so an eval read-back looks like success), but nothing is saved: a reload reverts it to "From everyone" and the Calendar API (users/me/settings/hideInvitationsSetting) still says NONE. No console errors, no failed requests, so pup_errors shows nothing either. After clicking OK and reloading, the page reads "Only if the sender is known" and the API reads UNKNOWN_SENDERS.

Suggested rule for the skill:

After changing any Google setting, look for a visible [role=dialog] / [role=alertdialog] and confirm it (OK / Change / Save).
Never treat an in-page read-back as proof of a save. Reload, read again, and where Google exposes the setting over an API, check that too.
If a bridge drop interrupts the flow, re-check state before trusting any "after reload" read: the reload itself may not have happened.