Workday's website rows remember every URL, and LinkedIn's token is lost on navigation

reference/ats/workday.md

@@ -11,7 +11,7 @@
   - Inputs: real `computer type` on some tenants; on others it swallows ASCII → native setter.
   - ⛔ **Textareas: the setter lies, and `value.length` does not catch it.** Measured 27 Sept (Warner Bros. Discovery tenant): four role-description textareas were filled with the native setter, every one read back the correct `value.length` immediately **and again after a re-read**, the step saved without error, and the **Review page showed "Role Description ~ No Response" for all four**. The DOM value was real; it never reached Workday's state. Real `computer type` into a focused textarea worked first time. So: type textareas for real, and **treat the Review step as the only proof** — `value.length` proves nothing on this ATS. Worth a `(t.match(/No Response/g)||[]).length` scan of the Review page before submitting.
   - The same setter DOES work on plain text inputs (job title, company, location, names, address) on the same tenant, which is why the failure is easy to miss.
-  - Setter does NOT work on date and prompt fields.
+  - Setter does NOT work on date and prompt fields, nor on the Websites `--url` inputs: measured 23 Oct 2026, a URL set with the setter read back correctly and the Review page showed "Websites: No Response". Add each site with the section's Add button, focus the new `--url` input and type it for real; five sites added that way all reached Review. **Never go Back to the step to add more sites afterwards.** Measured the same day: every URL typed in that session stays in Workday's state even after its row is deleted and the step is saved, so re-adding any of them, or adding new rows next to them, fails with "You can't add duplicate website URLs" on every row and the step will not save. Enter the full list once, in one pass.
   - Clear: `End` + `BackSpace` ×40 (written out), re-focus, type. Quote characters are rejected.
 - **Dropdowns / questionnaire — pure JS clicks (no coordinates):**
   ```js

reference/sources/linkedin.md

@@ -80,7 +80,7 @@ Then set `linkedin.mode` back to `email` in `profile/settings.json`, say so at t
 
 ## Mode `read`: methods
 
-Requests run in the page context of an open `linkedin.com` tab. `window.CSRF = document.cookie.match(/JSESSIONID="?([^";]+)"?/)[1]`. Every fetch is followed by `await new Promise(r=>setTimeout(r, (min+Math.random()*(max-min))*1000))`, with `min` and `max` from `read_limits`. At the default range, run at most four requests per JS call so the slowest draw still fits inside the 45 s budget.
+Requests run in the page context of an open `linkedin.com` tab. `window.CSRF = document.cookie.match(/JSESSIONID="?([^";]+)"?/)[1]`. **Set it again after every navigation**, including the one to the notification feed: `window.*` does not survive a page load, and a detail request sent with an undefined token returns 403. Measured 24 Oct 2026: five details in a row came back 403 after the feed was opened, and the endpoint worked at once with the token re-read. A 403 on the first request after a navigation is this, not a stop signal; re-read the token and try one request before treating it as one. Every fetch is followed by `await new Promise(r=>setTimeout(r, (min+Math.random()*(max-min))*1000))`, with `min` and `max` from `read_limits`. At the default range, run at most four requests per JS call so the slowest draw still fits inside the 45 s budget.
 
 **A loop left running in a background tab crawls.** Chrome throttles timers in hidden tabs, so a `setTimeout` gap in the LinkedIn tab stretches to about a minute once another tab is in front. Measured 14 Oct 2026: a 60-detail loop started in the background did 15 details in roughly ten minutes. Driving it from outside fixed it: one detail per JS call, with the 4-9 s gap done as a `computer wait` step between calls in a `browser_batch`, finished the remaining 45 in about six minutes. Keep the gap random by varying the wait values. **A visible tab is not enough either.** Measured 22 Oct 2026: a detail loop started with `fire-and-forget` in the front LinkedIn tab (`document.visibilityState` `visible`, `hasFocus()` true) did 3 details in about three minutes, while the same function awaited inside the JS call ran at the intended pace. Await the loop in the call that starts it, three or four details per call so the slowest gaps still fit the 45 s budget, and never leave it running between calls.