KIWIX DOWNLOADABLE CONTEST ZIM FILES CODE

It's also, currently, a lot of minified code that is hard to It strikes me that one possibility for leveraging our existing Service Worker is to use the self.importScripts('sw.js') method within our SW (see ). The only solution I can think of to support these ZIM types would be to incorporate the logic that reads assets from the replay system into our app, which would not be a generic solution. An error is thrown, and the whole app becomes unresponsive (even loading other ZIMs no longer works until the app is restarted). Therefore, when sw.js attempts to load it is not intercepted and never gets extracted from the ZIM. Unfortunately, this means that our own Service Worker, while still installed and running, no longer intercepts Fetch events for that scope.

Through some trickery, I can get the sw.js Service Worker to load, but because it loads with the scope (e.g.) it then takes over Fetch intercepts for that scope. I've been investigating this a little more, since more and more people are using Zimit ZIMs, despite poor support amongst Kiwix clients. But in this new system, the service worker is coming from the ZIM and takes over the loading/rendering and needs to be able to access other files in the ZIM directly. This could work, I haven't tried it before.Īgain, there is sort of a conflict because in kiwix-js, you're assuming that the reader has the service worker and loads static paths from ZIM. it'll need to send a message to the kiwix-js page to get a ZIM record, and wait for it to be returned. It either needs to have the ZIM loading there in the service worker, or load it some other way - it might be doable with a MessageChannel, where messages are sent from the service worker to the outer frame page which has already loaded the ZIM - eg. When running in kiwix serve, that will translate to For some of the other tools, it would translate to zim:///A/ (though they don't work for other reasons)īut in kiwix-js, there is no upstream server, so an upstream fetch() won't work. To put it another way, the way this is designed to work is that the service worker will make a fetch request to upstream:įetch('./A/') and for headers fetch('./h/'). In Service Worker mode, Kiwix JS does set the iframe URL correctly so that assets can be referred to with pure relative links and no further processing of URLs, however in SW mode we are getting the bad HTTP response code, even though I can confirm that sw.js is in fact appearing in our Service Worker's cache. Instead, the reader relies on identifying a ZIM URL by its namespace.

A/replay/ui.js.ĮDIT: I think your script is probably calculating the location correctly, but some readers do not set the location of the iframe to match the subdirectory that an asset is in, which is the case for Kiwix JS in jQuery (DOM-parsing) mode. At the very least, the URL should probably be: since the namespace of the current article is A, and ui.js has ZIM URL. js file from the non-conforming location, and these are the error messages logged after attaching and running ui.js:Īs you can see here ui.js is not calculating the ZIM URL for sw.js correctly.

Kiwix downloadable contest zim files