{
  "id": 6068372,
  "title": "My automation read another site's page: the active tab belongs to the browser, not to your session",
  "url": "https://urgent.news/2026/09/07/my-automation-read-another-sites-page-the-active-tab-belongs-to-the",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-07T00:08:40.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/vinhnguyenthanhdn/my-automation-read-another-sites-page-the-active-tab-belongs-to-the-browser-not-to-your-session-1iem"
  },
  "original_language": "en",
  "account": "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.",
  "summary": "One of my scheduled jobs was working on LinkedIn. It called into the page and read back a Reddit thread. No exception, no timeout, no empty result — the call returned a document, a title, and HTML that parsed fine. It was just somebody else's page. I run several scheduled jobs that drive one real Chrome over the DevTools Protocol, each with its own named client session. When two of them overlap,…",
  "key_points": [
    "Active tab belongs to browser, not client session",
    "Reporter's job read another site's page by mistake",
    "Re-asserting tab before each read resolves issue"
  ],
  "editors_take": "The discovery that the active tab belongs to the browser, not the client session, means automation jobs must re-assert tab control before each read to avoid reading the wrong page.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}