This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/comms.html Multipage: https://html.spec.whatwg.org/multipage/#the-websocket-interface Complete: https://html.spec.whatwg.org/#the-websocket-interface Referrer: https://html.spec.whatwg.org/multipage/ Comment: Determine which cookies to include before returning. See <http://www.w3.org/mid/551440C6.2020904@mit.edu> Step 7 says [[ Return a new WebSocket object, but continue these steps in parallel. ]] Step 9 [[ Establish a WebSocket connection ]] Now consider: document.cookie = cookie_string; var ws = new WebSocket(websocket_url); document.cookie = remove_cookie_string; It is racy whether the cookie is included in the request. Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.50 Safari/537.36 OPR/29.0.1795.26 (Edition beta)
This is currently racy for all fetches everywhere though.
I guess I should claim the storage mutex or something, but in reality, all the browsers ignore that, so it's a lost cause as Anne says.
(Specifically, even if we "fix" this as suggested, imagine the code in comment 0 running in parallel in two different tabs.)
Doing the storage mutex thing might be a good fix until we decide to remove that completely from all specifications.
Hmm yeah I hadn't considered multiple tabs. I'm OK with WONTFIX here.