W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] Active workers when user leaves the page

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 08 Aug 2008 12:01:54 -0700
Message-ID: <489C9822.2010001@sicking.cc>
This is something that have been in the back of my brain for a few days: 
How do we deal with the user navigating a way from a page if there's a 
Worker in the middle of some very long running script?

First off, please notice that this discussion is 100% orthogonal to the 
communications API discussion that is ongoing in another thread. I don't 
want to get the two mixed up.

We don't really want to always allow a worker to finish working, even if 
the user leaves the only page that is currently using the worker. I.e. 
if someone has an infinite loop (by accident or intentionally), I don't 
think we want to leave that running until the user shuts down the 
browser. In fact, the user could very well be leaving the page because 
he/she feels that it is sucking up too much CPU power.

One possible solution is to simply set the .closing flag inside the 
worker and hope that the worker will honor that flag and break out ASAP. 
The UA could even at that point give the worker some set amount of time 
before forcefully killing the worker. We have a concept of a 'slow 
script' dialog in firefox that we use if scripts on the main thread take 
too long to run. The dialog asks the user if he/she wants to continue 
running the current script, or forcefully break it.

This will not usually be used for workers (the whole point is that they 
take a long time to finish), but we could engage it once the user tries 
to leave the page.

I do want to be agressive with killing workers when the user leaves a 
page since that makes for better user experience. However I'm also 
worried about stopping scripts halfway through breaking things and 
leaving the site with half-finished operations that are stored in 
databases or localStorage.

Also note that the the presence, or lack of, fastback cache doesn't 
really make a difference. Pages are eventually going to get purged from 
the fastback cache, so it just pushes the problem to a point a little 
later in time.


How has gears dealt with this problem so far? What are your experiences 
with it?

/ Jonas
Received on Friday, 8 August 2008 12:01:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:04 UTC