- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 07 May 2012 15:09:46 -0700
On 5/7/2012 12:39 PM, Glenn Maynard wrote: > On Mon, May 7, 2012 at 2:05 PM, Jonas Sicking<jonas at sicking.cc> wrote: > >> As far as resource usage goes, it doesn't seem like a bid deal to send >> off a request at some point when the network seems quiet. >> > I could see interop problems if people use this to send something when the > user navigates out, and then the page they navigate to tries to use the > results. It'll only work if the request happened more quickly than the new > page. That's probably going to happen most of the time (if they're going > to the same server), so I could see people inadvertently depending on it. > > This probably can't be prevented entirely (the only way to do that would be > to wait for the final request to complete before navigating, which is no > good), though browsers delaying the request if the network is busy would > exacerbate it. How about limiting it to shared workers? Shared workers are already in the background: we could fire off the end-game event right before shutting the shared worker down. Authors ought to be looking at a shared worker if they're sharing state across pages.
Received on Monday, 7 May 2012 15:09:46 UTC