I don't like waiting on the completion of a task that should be run in the background. For example, when I bookmark a page using a Delicious bookmarklet it presents a modal dialog box that has me wait for the bookmark to be made on Delicious' servers. The saving might only take a short time but the length of this short time varies greatly. The unknown wait is a serious obstacle to maintaining flow.
The task is run by the browser when it has the chance. There are no guarantee of timeliness; just a promise of best effort. For simplicity, all the tasks in the list are run in the order added by the adding webapp. That is, if pages A and B both add 5 tasks to the background list then the tasks will be run in the order A1, B1, A2, B2, A3, B3, A4, B4, A5, B5. All tasks "succeed" in that any errors that occur must be conveyed to the originating webapp and its existing enqueued tasks. For example, a status of the task is kept in a cookie and the webapp & its tasks look at this cookie to determine the right course of action. The only indication to the user of tasks status will be a message in the task history. The user must not be expected to "respond" to the status message. The webapp is allowed to enumerate its tasks and to cancel them.