diff options
| author | Tianren Dong <tianrendong.dtr@gmail.com> | 2026-05-13 01:58:25 -0400 |
|---|---|---|
| committer | Tianren Dong <tianrendong.dtr@gmail.com> | 2026-05-13 01:58:25 -0400 |
| commit | 40c14a84dac7b6d56920eefda2c4b659630e1a18 (patch) | |
| tree | 47e8518a771c0ed082f708dee74aa60d9c85abae /README.md | |
| parent | c53af2f813347f8e36f3ff44ab97a3cdbbb15387 (diff) | |
pi-chrome 0.11.4: drop 'yellow' from banner copy; quote exact banner text
Banner is themed by the user's Chrome (dark mode → dark grey for many
users), not always yellow. Use 'banner' alone or quote the actual
banner text 'Pi Chrome Connector started debugging this browser'.
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -69,7 +69,7 @@ pi-chrome v<version> By default, `chrome_*` clicks and keystrokes are **synthetic** DOM events (`event.isTrusted === false`). They drive React/Vue/Angular state correctly but **do not** satisfy Chrome's user-activation gates: clipboard write, fullscreen, file picker, and autoplay all need a real user gesture. -pi-chrome can optionally route input through `chrome.debugger` (CDP `Input.dispatchMouseEvent` / `Input.dispatchKeyEvent`) so each event arrives as `isTrusted=true`, satisfies user-activation, and bypasses site bot-detection that filters synthetic events. The tradeoff: Chrome pins a yellow *"Pi Chrome Connector started debugging this browser"* banner to the top of any debugged tab. +pi-chrome can optionally route input through `chrome.debugger` (CDP `Input.dispatchMouseEvent` / `Input.dispatchKeyEvent`) so each event arrives as `isTrusted=true`, satisfies user-activation, and bypasses site bot-detection that filters synthetic events. The tradeoff: Chrome pins a *"Pi Chrome Connector started debugging this browser"* banner to the top of any debugged tab. Usage: |