jakearchibald
commented
4 years ago The reason this depends on SW is to provide a standard place to handle the events.
What's the alternative? If you fire them in a page, then you run the risk of dispatching them on a page without the correct event handler, which could happen for a load of reasons:
- Script containing the listener fails to load.
- User navigates to an HTTP 500, which doesn't have the script with the listener.
- User closes the page before the results of the bgfetch are written somewhere long-term.
- Developer forgot to put the listener on a particular page of their site.
I guess the system could write directly to some form of storage, which might work in some cases, but that was discussed in https://github.com/WICG/background-fetch/issues/3.
(Note: I know this is a big departure from the current model of bgfetch).
I am curious if there is any interest in allowing pages to use bgfetch without having to register any service worker.
It seems that, ideally, we would have a layered model where bgfetch would allow basic functionality if service worker is not used/available, and advanced functionality if service worker is used.