Console scripts on SharePoint hang because the ODSP service worker stalls every fetch
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
- Hard reload the tab (
Shift+F5/Ctrl+Shift+R). A hard reload bypasses the service worker for that page load, sonavigator.serviceWorker.controllerbecomesnull. - 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.