Chromium extension for offline usage

[guest271314]

https://github.com/jimmywarting/StreamSaver.js/issues/221 Tested offline on Chromium 93.0.4569.0

[jimmywarting]

I don't want a extension.

service worker are suppose to make the site work offline. the streamsaver worker is only lazy installed when it's needed.

a better optoin is to self host a own service worker and communicate directly with it instead of some mitm.html that isn't serverd from the cache with respondWith.

it's not necessary to have a extension to use this only to make it work offline

I recommend to try out the https://github.com/jimmywarting/native-file-system-adapter that has a own service worker that can/should be installed right away

[guest271314]

I don't want a extension.

That is your choice. I created a PR for the specific purpose of using your code offline for the use case OP of the issue described - without having to go online first.

I used an MV3 extension becuase the background script is a ServiceWorker. AFAIK a ServiceWorker cannot be initially registered offline. MV3 background ServiceWorker is an exception. The extension can be used offline without need to go online first.

a better optoin is to self host a own service worker and communicate directly with it instead of some mitm.html that isn't serverd from the cache with respondWith.

I used the JavaScript in the existing mitm.html file in this repository.

it's not necessary to have a extension to use this only to make it work offline

How can a ServiceWorker be initially registered offline - without running a local HTTPS server?

I recommend to try out the https://github.com/jimmywarting/native-file-system-adapter that has a own service worker that can/should be installed right away

How does the ServiceWorker get registered initially offline?

[jimmywarting]

on the first visit you have to do navigator.serviceWorker.register(...) then u can use the service worker and everything else when the site has taken offline

[guest271314]

I am trying to help OP achieve their use case, which is usage of your existing code without Internet. AFAIK there is no way to register a ServiceWorker on a non-HTTPS protocol without Internet - except for using an MV3 extension ServiceWorker which does not require registration. If you have working File System Access API code which achieves the same result as you ServiceWorker based code perhaps direct OP of the issue to that code. The issue is still open, thus I used your code in the ServiceWorker and tested offline - without going online first - the result is ServiceWorker without Internet or HTTPS. I see no reason why OP of the issue could not use the approach, other than you do not want an extension, for whatever your reasons are.

[guest271314]

Technically this PR will also solve https://github.com/jimmywarting/StreamSaver.js/issues/203 and https://github.com/jimmywarting/StreamSaver.js/issues/231. The files listed in "web_accessible_resources" in manifest.json can be loaded on any origin listed in "matches" of the same object.

[jimmywarting]

I do not want a extension cuz that would require every user to install a extension - which is not recommended. This is a no go for me.

what should be done instead is enabling https (or using localhost) so a service worker can be installed and start working offline - you will need to take extra steps into enabling offline use with cache and evt.respondWith

The service worker should be installed before you even start downloading something when you made the site work offline

if this dose not cut it then you pretty much have to resort back to assembly a Blob somehow and use <a href="blob:url..." download="name.txt">, FileSaver or https://github.com/jimmywarting/native-file-system-adapter where a service worker is a optional choice

[guest271314]

I do not want a extension cuz that would require every user to install a extension

No, the approach is only applicable for the use case of completely offline (no Internet) and for self-hosting your mitm.html and the JavaScript that file loads.

The extension is not for Chrome Web Store. The user can navigate to chrome://extensions, set "Developer mode" to on, and load the unpacked extension. All of the files necessary will be on their own machine, instead of making external network requests, e.g., https://jimmywarting.github.io/StreamSaver.js/mitm.html?version=2.0.0.

The service worker should be installed before you even start downloading something when you made the site work offline

Chromium/Chrome MV3 extensions use ServiceWorker in the background, without the need to use HTTPS or be online. That is the point of the PR.

I am not sure why you object to using an extension for the use cases. It is at least the same amount of work to create a local HTTPS server - which the user still has to turn on and off some way.

[guest271314]

Perhaps take the time to review the files in the PR. There is not much new code. All of the code already exists in this repository. The extension just arranges the code to be used locally - without the need for any external network requests. The background ServiceWorker https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#service-workers

Service workers # Manifest V3 replaces background pages with service workers.

Like their web page counterparts, extension service workers listen for and respond to events in order to enhance the end user's experience. For web service workers this typically means managing cache, preloading resources, and enabling offline web pages. While extension service workers can still do all of this, the extension package already contains a bundle of resources that can be accessed offline. As such, extension service workers tend to focus on reacting to relevant browser events exposed by Chrome's extensions APIs.

is the same ServiceWorker code that you already use. "web_accessible_resources" object allows the user to set which origins the local resources, in this case the mitm code, can be requested on. That alleviates the need to source mitm code from external network requests.

While File System Access API does provide a means to write files locally, as you know, write() currently creates a temporary .crswap file first, which ultimately results in the file being written at least twice; and if the user is not careful, data can be lost, even when keepExistsingData is used.

[guest271314]

I'll keep the PR in the fork open if you change your mind.