be more explicit that jobs always run asynchronously

[wanderview]

Previously @mattto stated that Chrome always run jobs asynchronously. The spec is a bit fuzzy on this saying things like:

If job’s job type is register, invoke Register with job and continue running these steps in parallel.

This suggests that perhaps Register gets to keep running sync and then the current steps are completed potentially in parallel.

I think it would be better for Run Job to explicitly queue a task to invoke the algorithm for the job.

This matters for things like:

registration.unregister().then(function() {
  var p =navigator.serviceWorker.register(urlThat404s, scope: registration.scope)

  // Removing last controlled client would allow registration with uninstalling flag to
  // be purged.
  controlledFrame.remove();

  return p;
}).then(function() {
  // if register can run its initial steps sync, then it can clear the uninstalling
  // flag before the controlled client is removed.  This results in the original
  //  service worker script remaining active.

  // If register always runs async, then the controlled client is always removed
  // before the uninstalling flag could be cleared.  This results in no registration
  // being present since the new script 404s.
});

[wanderview]

Also, I am currently switching gecko to always run jobs async since it provides more consistent behavior.

[jakearchibald]

F2F: Make sure all jobs are scheduled async

[wanderview]

No gecko bug as we have already implemented this.

[wanderview]

I'm sorry, but I'm not sure I agree with the change in spec language. I think scheduling the job should be immediate, but actually executing the job should be asynchronous. I think the "queue a task" language belongs in the "Run Job" algorithm.

This also ensures an async step between consecutive jobs in the queue which is important for flushing event runnables and whatnot.

[jungkees]

I think scheduling the job should be immediate, but actually executing the job should be asynchronous.

Yes, that makes sense. Please see if e68be6e satisfies your expectation.

Also, I think this note should still be there, right?

For a register job and an update job, the user agent delays queuing a task for running the job until after the document initiated the job has been dispatched DOMContentLoaded event.

Or is it guaranteed the task queued in Run Job is always queued after the task for dispatching the DOMContentLoaded event?