Use service workers for managing cache and storage

[sansmoraxz]

What kind of feature request is this?

Feature improvements – suggestions for something that can make a current feature a bit better.

---

Is your feature request related to a problem? Please describe.

While I love the extension. It doesn't always play nice when you go offline, if you are using web assets. Like blanks when using custom url imgs for bookmarks backgrounds etc.

Also on metered connections, network only approaches can gets very expensive.

For the time being users can try limiting the number of web image or video urls to minimum

---

Describe the solution you'd like

Service workers scripts can be used to intercept fetch request, and interact with cache data. This may be used to implement background caches, or custom response if fetch fails.

_Here's a nice tutorial/ demo from MDN to implementing service workers._

There are also webpack plugins to generate service workers like workbox.

[sansmoraxz]

Service workers do run separately from main thread. But have no access to localStorage.

Although with storage permissions, they can access storage. https://github.com/zombieFox/nightTab/issues/93

Interactions between client and service worker can be done through message events.

Or directly with storage api as shown here.

[zombieFox]

While using service worker is a good idea, when testing in Chrome, opening the new tab page when offline the cached background image is used. Are you experiencing different?

[zombieFox]

On the note of storage permissions, this project is appealing (dare I say "popular") to its users because it does not ask for any permissions. So I would like to avoid adding permission requests at this time.

[metruzanca]

I think the simplest thing we could do for basic offline support would be to add window.navigator.onLine to display some message to the user and re-request the images when that turns to true.

But overall, offline support for a bookmark organizer seems kind of odd. But I guess for metered connections, it makes sense.

Though, most browsers do quite a bit of caching of their own and while they send out requests for images, often times its just to check if the content has changed. That being said, I have no clue what it does for mobile and would probably require some testing unless you can find some nice article written for mobile devices and their browsers. (if testing is done, you'd wanna look at what the response is, it might be a 304 (not modified) or a 200 with the image) This might be a case of pre-optimizing.

---

Theres probably some image caching that can be done without adding permissions, so without service workers. Not sure if app cache requires a permission. If it does, it would be down to localstorage again, possibly using another key just for caching. But again, browser network caching is probably going to cut down most.

[sansmoraxz]

While using service worker is a good idea, when testing in Chrome, opening the new tab page when offline the cached background image is used. Are you experiencing different?

That was the intended behaviors for it.

Cache data = no network fech. For cacheFirst policy. raceCacheNetwork or networkFirst policies would make still be making network calls.

But if you meant the default behavior From the one in webStore. Not always.

Like here's the present from screenshot 11. when offline, none of the images provided were loaded.

Service workers should mitigate this problem. Also the loading delay if the image size's quite large.

[sansmoraxz]

You can check the cache memory details in Application tab of web inspector.

More on caching policies in Offline Cookbook