As we're changing how controllees talk to the controller from always-via-browser model to direct model, we'll need to re-implement following SW timers at least:
- Idle timer: browser no longer knows if the SW is busy or not (unless we propagate the events from controllee to the browser process too)
- Event timers for Fetch (and Message): ditto, controllees will start to send them directly to the controller.
As we're changing how controllees talk to the controller from always-via-browser model to direct model, we'll need to re-implement following SW timers at least:
- Idle timer: browser no longer knows if the SW is busy or not (unless we propagate the events from controllee to the browser process too). This can probably be implemented by the service worker itself, as it can tell when it's idle and can stop itself.
- Event timers for Fetch (and Message): ditto, controllees will start to send them directly to the controller. This can probably be implemented in the controllee side.
We'll still need some of stuck-detection / last-resort timers in the browser process.
As we're changing how controllees talk to the controller from always-via-browser model to direct model, we'll need to re-implement following SW timers at least:
- Idle timer: browser no longer knows if the SW is busy or not (unless we propagate the events from controllee to the browser process too). This can probably be implemented by the service worker itself, as it can tell when it's idle and can stop itself.
- Event timers for Fetch (and Message): ditto, controllees will start to send them directly to the controller. This can probably be implemented in the controllee side.
We'll still need some of stuck-detection / last-resort timers in the browser process.
Design doc: https://docs.google.com/document/d/17Wrmzcy_gHeG5NSw5R92BrUD6JgdEgmBhr8W_DCqftI/edit#heading=h.dg831l8xtj2y
Comment 1 by kinuko@chromium.org
, Oct 13 2017