Are service workers ever removed automatically by the browser? - javascript

I've been trying to make PWAs that reliably work offline on and off for the past year, but every time I write a new service worker, it works as expected for a week or two and then just breaks (until reconnecting). I thought it was due to the site's data getting evicted, but the local storage is often intact when I reconnect to the internet so it can load. Recently I also had one of the service workers remain active, but its cache storage was deleted, as well as the other service workers (I've got multiple different sites on the same origin, some of which have service workers. It's my GitHub Pages).
According to the spec, it sounds like service workers should always remain registered unless the data for the whole origin is evicted. I also don't think my service workers are accidentally deleting their caches or unregistering themselves as the issue only happens after not using them for a while, in which case they aren't running. Clearing Chrome for Android's cache also doesn't break the PWAs when offline, so I don't think I'm manually doing anything that's breaking them. Clearing an individual PWA's storage and cache also doesn't break it.
The relevant sentence in the spec:
"A user agent must persistently keep a list of registered service worker registrations unless otherwise they are explicitly unregistered."
(the unregistered service workers also don't show up in chrome://serviceworker-internals/ )
Any ideas? Do you think this is a bug? I've mostly seen this in Chrome for Android, but I think I'll try some other browsers as well to check. Unfortunately I can't test any of this very well as it's quite unpredictable and takes weeks.
These are the 2 main sites to try, as I use the same template for a few, although I don't think it'll be that helpful:
https://hedgehog125.github.io/Bagel-PWA/
https://hedgehog125.github.io/Bagel-V2/ see https://github.com/hedgehog125/SvelteKit-Plugin-Versioned-Worker/blob/main/src/worker.js for the proper service worker template
Thanks for any input
Edit: I thought it would be worth a try to see if that first site still works in Firefox while offline. It does, despite not visiting it in Firefox for maybe 6 months. I guess this is a Chrome bug/feature then?
Edit: Updated the title

Related

Can an offline JavaScript app using service workers work after browser restart?

Application cache as a means of creating offline browser apps has been deprecated. The current way to make an offline web app is to use service workers.
Service workers allow you to bootstrap all network requests and provide content for them. Since service worker can run even when user closes the tab, it can provide cached content when internet temporarily doesn't work.
However when I got interested in offline web applications, it was because I hoped to use even when I have permanently no access to internet. I created simple offline app, but it does not work when I close and open the browser — I get message that page cannot be loaded.
Is there a way to make service worker offline app work even after browser is closed and re-opened? If not, are there any planned standards for this? It would be very valuable to mobile users.
Can an offline JavaScript app using service workers work after browser restart?
Yes, it can, provided it's cached all of its resource previously. This example goes through the steps of ensuring that.
The reason it can is that when you navigate to the URL that the service worker is registered for, the cached copy of the service worker is activated and it's given the opportunity to satisfy network requests for the app. So if you've cached everything, and you satisfy all of the requests by handling the fetch event, your app can be entirely offline.
There is a great deal of development in the area of service workers. Chrome is taking the lead, but Firefox follows closely. IE support is negligible however.
You can see the W3C working draft. For browser support, check e.g. here.
I also suggest taking a look at Nolan Lawson's pokedex.org application, it is an offline-capable web app based on service workers.

Is IndexedDb dependent on cookie?

I am working on a prototype where we need to support offline data modification of web application, the application is expected to sync back the data when an internet connection is restored. I have taken a look at various HTML5 in-browser storage option and indexeddb looked like the one I wanted. But I am not sure if the data will be persisted between browser close. Is that possible? One more question if I delete the cookie of the browser, will data in indexedDb will be wiped out? My initial tests shows data gets deleted on cookie clear of browser.
If indexeddb is not a viable option, are there any other alternatives to it which can persist data when internet connection is not available?
As per specification database created with indexedDB should be persistent acrross navigation and browser session.
But current implementation is like persistent cookies. So removal of cookies might remove your database too.
As per google chrome indexedDB is a type of temporary storage.
Chrome: https://developer.chrome.com/apps/offline_storage
For microsoft & firefox it is persitent :
Microsoft: https://msdn.microsoft.com/en-in/hh563494.aspx
Firefox: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
Check supported browsers before use.
http://caniuse.com/#search=indexeddb
It isn't dependent on a cookie, though if you need to know who the user is (likely) you'll probably end up using a cookie of some variety...
As for offline sychronization... I thought about this a lot previously and created a project... The documentation for it is detailed and explains why and how... It may help, or at least give you things to think about. It has very recently been updated to support IndexedDB!
http://forbesmyester.github.io/SyncIt/index.html
In this space there is also RemoteStorage ( they were/are looking at using SyncIt + other bits in the project going forward ), Hood.ie and the commercial FireBase in this field.

Configuring maximum number of simultaneous open WebSockets (in IE)

I've got this JS application. All client side JS communicating with a third party stream server via web sockets. I have about 18 different web sockets open for one page. Firefox and Chrome handle this many open web sockets at once just fine. IE11 seems to have a limitation of 4 open web sockets at once. Once I open that 5th web socket, regardless of socket call to the third-party server, I get an error thrown by IE, which closes the socket and gives the general error "SecurityError" and expanding the proto section it gives me . Seems to be pretty generic errors from my searches. At first I thought there may be a trusted zone type issue with IE, but I've added the client site to my trusted zone as well as the server providing the data.
This post provides info on max number of websockets for Firefox & Chrome, but I don't see anything specific about IE. Are there any known limitations to IE and web sockets? Answered, see edit below.
This MDN site talks about increasing the max value, but again, I can't find anything about IE. Is there some IE setting to up the amount of open connections? Answered: see below edit.
EDIT: This site shows the max connections settings for IE. It looks like it's a registry setting in Windows that controls the amount of web socket connections. Interestingly enough, I don't have that registry Key anywhere, but there is still a limit for this. The page speaks of IE10, and I'm working with IE11 specifically. Does anyone know if there are registry settings for this in regards to IE11? Has anyone just added these feature web socket registry keys and solved this issue?
The MSDN documentation you referenced is clear on the default being 6 concurrent connections (which means if not specified in the registry, that's what you'll get); and, if the documentation doesn't specify differently, it's probably safe to assume newer versions of Internet Explorer act in the same way as version 10.
Try setting through group policy. It worked for me.
https://jwebsocket.org/documentation/reference-guide/internet-explorer-tips

Persistent local storage for both Firefox and Chrome?

Looking for advice/options for having persistent local storage using both Firefox and Chrome allowing me to save 50MB+ data. I would be storing dynamic terrain data for a WebGL game, so it wouldn't be necessary for the server to send the whole data every time the player connects. I could just update the old parts.
I thought about using an IndexedDB however Chrome doesn't allow you to increase the quota (unlike Firefox) so I wouldn't be able to store any large data. Chrome allows you to use the FileSystem API which would solve my issue however Firefox does not support it.
So it seems either way it wouldn't work. Is my only option to use the FileSystem API for Chrome and the IndexedDB for Firefox? Does anyone have any better ideas?
This info is what I've read from Mozilla's Blog and Google's Dev Site but that may be outdated now, so please feel free to correct me. Thanks!
I agree with the other comments about caching and the Chrome/Firefox marketplaces, and they may ultimately be better solutions for you. However, to answer your original question...
IndexedDB in Chrome is definitely not limited to 5 MB. You can store far more than 50 MB in IndexedDB in both Firefox and Chrome, assuming the user has enough hard drive space. Higher amounts of IndexedDB storage are regularly reached in this game I wrote. On my computer, I currently have over 500 MB stored in IndexedDB in Chrome for that one domain.
You did correctly link to https://developers.google.com/chrome/whitepapers/storage and it is quite confusing, but as I understand it, basically the upper limit is 10% of the free space on the hard drive. Another caveat described on that page is that IndexedDB is technically "temporary" storage that the browser might delete if space is running low, but in practice this seems to rarely happen (YMMV).
localStorage is limited to 5 MB (I think this was on Chrome) and you can request more space for every new 5 MB through dialog boxes.
Both localStorage and IndexedDb are created for interactive data. Because it looks like the data is not modified on the client-side your options are
Using the application cache (as mentioned in the comment)
Serving the data with cache forever HTTP headers (like 10 years), have unique URLs for new resource versions and let the browser re-download the data when it goes out of the cache (recommended)
Deploy your HTML5 application as a web app, downloads available from Chrome Store and Firefox Marketplace

offline, cross-tab communication (javascript-only)

Is it possible to find foreign instances of certain website? Ofc theese are independently opened tabs (not by window.open). I need to prevent user from opening 2 tabs, and send message to previously opened tab to inform that it's impossible to open 2 tabs. 2 Intependent tabs may break page offline storage and webSQL structure, so that I can't allow people to use 2 tabs. It's also semi-offline app so it needs to be client-side solution.
You can communicate across tabs using localStorage. Every time you write a value, a "storage" event is fired on the window object on every tab (except the current one).
http://diveintohtml5.info/storage.html
Scroll down to "Tracking changes in the html5 storage area"
The event will include event.key, event.newValue, event.oldValue.
This only works in modern browsers.
In 2021, you can use service worker:
https://github.com/gyteng/service-worker-event
notice: service worker only works in https protocol
localStorage can be used to track windows. You should take into account a situation when window crashes - it will leave the garbage in localStorage.
Accessing a common resource from several windows simultaneously may be done by mutex based on localStorage.
I've recently published the interwindow communication library (all features are described in readme). It provides thread-safe data sharing, cross-window locks and event broadcasting. It also solves some IE issues.
Broadcast Channel is design for this
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API
but the native api only support modern browsers.
there is a npm package support all old browsers as well
https://www.npmjs.com/package/broadcast-channel
You don't have control over that. The user can do basically whatever he/she wants on the computer.

Categories

Resources