[httpsphl]

Why

The bot's browser was slow, froze, and its clicks (the bot's and the owner's) did nothing or landed in the wrong place. I measured it with the real Edge (a throwaway probe, not committed) instead of guessing. Four causes.

What was wrong, and what changed

1. Lost clicks on a scaled screen. The app sends the screen's scale (Windows at 125%, 150%, 200%) in browser.resize; the daemon drew the page sharper (deviceScaleFactor) and took a Page.captureScreenshot per frame. The browser then read click coordinates divided by the factor: the click on a button at (350, 220) landed at (280, 176), (233, 146) or (175, 110). Only 4 of 12 size and scale combinations landed, for the bot and for the owner. Holding a lock between pictures and input events did not fix it (11 of 12, then worse). The page is now always drawn in its own pixels and the panel scales the frame: 16 of 16 land. browser.resize still accepts scale and ignores it. Cost: the live view is slightly softer on a scaled screen.
2. 3 s per action on pages that never go quiet. After each action the daemon waited up to 3 s for the network to go quiet; any page with analytics, ads or chat never does (3.2 s a click, against 0.17 s on a quiet page). A page that was already busy before the action now waits 0.6 s.
3. Half a second more per action while the owner watches, and clicks at a stale point. The tool waited 560 ms for the cursor to glide, and had aimed before that wait, so a page that changed meanwhile (image, banner) took the click at the wrong point. The wait is now 300 ms (glide 260 ms in motion.css) and the element is found again after it.
4. A button under a fixed header was clicked on the header. Now other scroll alignments and other points of the element are tried; if nothing is free, the page's own click is used and the bot is told.

Measured, before and after

	Before	After
Click on a page with constant traffic	3.18 s	0.78 s
Click with the panel open	735 ms	468 ms
Click with panel open and constant traffic	3.75 s	1.08 s
Clicks that land at 125%, 150%, 200%	4 of 12	16 of 16
Button under a fixed header	clicked the header	clicks the button

Tests

cargo test --workspace (550), clippy -D warnings, cargo fmt --check, pnpm check (446). New tests, each failing on the old code: clicks of the bot and of the owner at 100/125/150/200% (browser_panel.rs, replacing the test that asserted the old sharper page), a never-quiet page (browser.rs), a covered button (browser.rs). Spec 21.3, 21.4, 21.7 and 19 updated with the measurements.

Not covered

Only my own pages were tested with the real Edge; heavy real sites may still be slow for reasons of their own. If something still hangs, the site and a measurement will say where.