My automation read another site's page: the active tab belongs to the browser, not to your session

A scheduled job was working on LinkedIn when it accidentally read another website's page instead of its own. The job called into the page and received a document, title, and HTML that parsed fine, but it was reading someone else's page. The reporter runs several scheduled jobs that each have their own named client session and drive one real Chrome over the DevTools Protocol.

They initially looked for stray navigation in their own code or a second tab, but neither was the issue. The resolution lies in the fact that the read doesn't resolve to the tab created by that session; it resolves to the active tab in the browser. The active tab belongs to the browser, not the client session, and the last job to navigate anything becomes active for everyone.

The reporter found that re-asserting the tab immediately before every read worked and was cheap, but it had to be done for every command forever. An alternative is to serialize access, giving one job control of the browser at a time. The reporter uses this method, combined with a per-read switch, because the failures are independent.

If a client holds a page or target handle for the life of the session and addresses commands to that handle, the described issue likely does not apply. This behavior requires a driver that resolves the page from browser state at command time. The reporter has not measured other clients to determine their internal workings, but it is worth checking if your stack has similar behavior.