SharePointVault ~/gotchas/tooling ⌕ Search 404 pages, error messages, scripts…Ctrl K ★ Star
M↓ README.mdM↓ console-fetch-hangs-under-odsp-service-worker.md
sharepoint-vault›gotchas›tooling›console-fetch-hangs-under-odsp-service-worker.mdhistoryedit on GitHub
● GOTCHAtooling· 2 min read

Console scripts on SharePoint hang because the ODSP service worker stalls every fetch

applies to: SharePoint Online (modern pages and REST URLs in Chrome / Edge)reviewed: 2026-11-09#tooling#browser#service-worker#rest#devtools

If a script you paste into the browser console on *.sharepoint.com (or run through browser automation) never finishes, check whether only the network is stuck: timers fire, but no fetch resolves – not even one to another domain. SharePoint pages are controlled by its service worker (odspserviceworkerproxy.aspx), which intercepts every request of the page; when it hangs, so does your script. Shift+F5 reloads the page without the service worker and the script runs.

Když skript vložený do konzole na *.sharepoint.com nikdy nedoběhne, ověř, jestli stojí jen síť: časovače běží, ale žádný fetch se nedokončí – ani na jinou doménu. Stránky SharePointu řídí jeho service worker (odspserviceworkerproxy.aspx), který zachytává všechny požadavky stránky; když se zasekne, visí i tvůj skript. Shift+F5 načte stránku bez service workeru a skript projde.

Symptom

  • A REST script (await fetch('/_api/...')) pasted into DevTools or run by an automation tool times out.
  • It happens in a brand-new tab too, even on a bare REST URL such as /_api/web/title.
  • The same browser runs scripts fine on any non-SharePoint page.
  • CPU usage of the browser is flat – nothing is looping.

It is tempting to blame a frozen tab or a pending alert() dialog in another SharePoint tab. Before you go hunting for one, run the check below: if timers still fire and only the network is stuck, the cause is the service worker, not a blocked page.

Diagnose in ten seconds

window.__t = 'pending';
fetch('https://example.com/', { mode: 'no-cors', cache: 'no-store' })
  .then(() => window.__t = 'fetch ok', e => window.__t = 'fetch error ' + e);
setTimeout(() => window.__t2 = 'timer ok', 100);
const c = navigator.serviceWorker && navigator.serviceWorker.controller;
c ? 'controlled by ' + c.scriptURL.split('?')[0].split('/').pop() : 'no controller';

Read [window.__t, window.__t2] a moment later. timer ok together with pending on a page controlled by odspserviceworkerproxy.aspx = the service worker is the bottleneck.

Fix

  1. Hard reload the tab (Shift+F5 / Ctrl+Shift+R). A hard reload bypasses the service worker for that page load, so navigator.serviceWorker.controller becomes null.
  2. Run the script again – requests now go straight to the network.

The page stays uncontrolled until its next normal navigation, so run admin scripts right after the hard reload. A plain REST URL (/_api/web/title) is a good host page for console scripts: it loads fast and runs no page code of its own.

Notes

  • The worker intercepts cross-origin requests from the page as well, which is why even a call to your own CDN hangs.
  • In the case behind this article, closing or reloading other SharePoint tabs did not help; the hard reload of the tab running the script did.
Was this helpful?ask or add your experience on GitHub →
Saved you an hour? A star on GitHub helps other SharePoint people find the vault.★ Star on GitHub
last reviewed: 2026-11-09last updated: 2026-11-09historyedit on GitHubview source