You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(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.
The text was updated successfully, but these errors were encountered:
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 #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.
The text was updated successfully, but these errors were encountered: