Switch from applicationCache to service workers

[enketo-issue-mover]

From @MartijnR on February 3, 2016 21:59

applicationCache is being deprecated

https://html.spec.whatwg.org/multipage/browsers.html#offline

Too early at the moment. http://caniuse.com/#feat=serviceworkers

Copied from original issue: kobotoolbox/enketo-express#401

[enketo-issue-mover]

From @MartijnR on February 16, 2016 20:32

to fix afterwards:

• remove awkward method of passing submission parameter to offline view => Change how (submission) parameters are passed to offline view #1149

[enketo-issue-mover]

From @MartijnR on August 17, 2018 23:54

First thing to check is the 24 hour thing, as we need users to be able to stay disconnected for much longer.

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

[MartijnR]

This is becoming urgent.

enketo-webform-bundle.js:107875 [Deprecation] Application Cache API use is deprecated and will be removed in M82, around April 2020. See https://www.chromestatus.com/features/6192449487634432 for more details.

[chrismclarke]

In case it's of interest, google does have a rough tool aimed to help migrate from appcache to service workers: https://github.com/GoogleChromeLabs/sw-appcache-behavior

It claims to be work in progress (although fairly inactive and so for a complex setup may not work, but could be worth a try.

[MartijnR]

Thank you. I wasn't aware of that tool!

[MartijnR]

• implement - initially keeping similar to appCache with dynamically generated service worker script perhaps or list of resources-to-cache per language.
• 404 response to appCache manifest requests - confirm that clears the cache
• fix broken webfont paths in css for e.g. /preview/ view
• update mechanism
• fix font loading issue
• dynamically add non-en languages upon request
• fix: not showing non-english default UI language (though cached correctly)
• test with explicit basepath set
• check if getOnlineStatus still works
• remove appCache code
• dynamic non-en translations ?
• add offline-fallback (perhaps) - I don't see a need atm
• update manifest tests (if they exist)
• revisit if offline-resources-model.js and explicit resources can be removed entirely, see Switch from applicationCache to service workers #1204 - if removing, do in separate reversible commit and don't squash that one
• revisit handlers in enketo-webform.js, see TODO
• test application updates within session
• check authentication (for form, form resources)
• message in forum: https://groups.google.com/forum/#!topic/enketo-users/1AewNMkAIiU
• finish Remove IE11 build and therefore IE11 'support' #1153
• update enketo.org descriptions
• add redirect for old /_/#abcd URLs to /x/#abcd
• release as version 2.0.0

http://localhost:8005/x/#hhF7kngN

[MartijnR]

Languages

Would be useful to use the form definition to determine which languages to cache. This would enable proper UI language switching in the future.

Alternatively, we could dynamically add any additional languages the user switches to while online.

For now, planning to implement this initially:

• explicitly cache English only, so there is only one version of the service worker (and resource cache)
• cache other language dynamically whenever the page requests them (service workers seem wonderful for this) - until the future feature below is implemented, this will only be done for the browser locale or a specific ?lang=.. requested language.

Future:

• add a little initialization function in offline-capable views that looks at form language selector and loads (and therefore caches) the missing UI translations! => Sync Form language with UI language (if match found) #1202

Media labels

Currently stored in indexedDb. This was done to keep applicationCache as static as possible for all forms. Not sure if still the best approach, but I think so. If we dynamically add images to the cache, I think we cannot ensure these survive when a service worker updates. They will be re-added for the form load that triggers the update, but not for any other cached forms (until the user reloads them whilst online).

Alternatively, we could have a separate cache for media for each form ID, and a common cache for common resources.

To keep the scope of this initial work limited, we essentially mimic the existing ApplicationCache, and keep the form cache as is.

Service worker scope

If the service worker is installed from a script at /x/somepath.js, the scope is /x/. With the current appCache implementation, resource files come from root locations as well. We could either change the scope to root or support /x/paths for all application resources. In the former case, any online-only forms will also use the cache if that user has once opened an offline-capable form.

Since there will be no user-feedback ("restart page") in the online-only pages, it seems best to let /x/ be the scope.

Migration

1. A cached application receives a 404 response to a manifest request
2. A cache obsolete event is triggered, and the cache is removed
3. A reload is required to load and install the service worker

Would be nice if at 2, the user is prompted to reload

[MartijnR]

future:

• form cache for form itself + media/data resources + translations (and getting rid of #urls)

[MartijnR]

Note:

The explicit list of resources may not serve much of a purpose (vs. dynamically caching whatever is requested in the scope of the service worker (/x/path/to/resource). But we need to update the (byte value) of the service worker if any resource changes, so we'll have to go through all resources anyway.

However, it's worth considering just incrementing the service worker (version) whenever, Enketo is restarted or gets a new git tag or something. The only issue with that would be for Enketo developers (but developer tools has a setting to 'Update on reload', and it is currently also a bit of a pain due to the redis cache).

Update:

1. a configuration update would only be caught if we update the version at every reboot (or get a hash)
2. not all theme CSS files would be added, so we could add all theme files explicitly