-
-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try to use the webRequest API (as a fallback if ServiceWorker is unavailable) to inject the content in pages #193
Comments
The API has been implemented by Mozilla, and will be available with Firefox 57 |
The filterResponseData function of WebRequest API has been implemented in Firefox >=57 : https://bugzilla.mozilla.org/show_bug.cgi?id=1255894 The WebRequest API itself is cross-browser BUT, for now, the filterResponseData function (which should allow us to create the response) is not supported by Chrome/Edge/Opera. See https://developer.mozilla.org/Add-ons/WebExtensions/API/webRequest and https://developer.chrome.com/extensions/webRequest But maybe Chrome might eventually implement this function. It does not seem to be planned, but has been asked by many extension developers : In any case, this API is only available for browser extensions |
And try to use it (not working at all, yet) See #193
Do you have a sense of what the advantages of using the WebRequest API would be, if Chrome (and Edge) eventually support filterResponseData? Cleaner code or a performance advantage? Would we need fewer transformations on the intercepted data than we currently do? We currently directly intercept and transform the data coming from the decompression engine, some of it before the HTML is injected into the DOM, and some afterwards using jQuery DOM manipulation. |
In jQuery mode, we need to transform the DOM. And there are many caveats to do that. For example, we inject the images by looking for tags. It works most of the time, but it will miss many other ways to display images : background images, CSS styles, javascript etc. It's the same thing for hyperlinks (that could be triggered by some javascript, image maps etc) The ServiceWorker or WebRequest modes should not have these issues. Because the browser traps all the HTTP requests, we can not miss any of them. And the optimization should be handled by the browser itself (which knows how to do this very well) : fetching the visible elements first for example. I say "should" because those 2 modes are not fully working (it works mostly for ServiceWorker, but not yet for WebRequest), and it's not supported in all environments :
In short, with one of those 2 modes, we should need no transformation of the DOM, and it should be faster (it's already noticeable in the already-almost-working ServiceWorker mode, even if its code can be optimized). |
OK, thanks for the helpful and interesting explanation. So it sounds like we're looking for ways to implement something like a mini web server that the decompression engine can sit behind. I wonder if Web Workers might also be used in a similar way. |
Yes, ServiceWorkers act a bit like a transparent proxy server between the DOM and the Internet. And apparently the WebRequest API can do similar things. |
And try to use it (not working at all, yet) See #193
I'm afraid it will not be possible to use the webRequest API for now. |
That's a shame, @mossroy , but thanks for trying.
|
Yes, that's bad news. Regarding your proposals : We had other ideas to improve the speed of jQuery mode : prioritizing the image loading (by backporting your code), caching the DirEntry (by backporting @sharun-s code) Regarding emscripten, #219 might also help, and what you describe is #116 . It would certainly improve performance and compatibility, but relies on the WebAssembly API, that is now supported on most latest browsers, but not older ones. See http://caniuse.com/#feat=wasm . In any case, I really think we will need to implement #116 because maintaining the low-level backend code that reads ZIM files will probably become more and more complicated. |
OK, thanks @mossroy . #116 looks interesting -- is it for sure dependent on Web Assembly? Maybe I should ask on that thread. What confuses me about the file access issues there is that we already have an Emscripten-compiled binary that works on very large files and that doesn't use Web Assembly, so clearly some kind of large file access is working with Emscripten compilation. Problem with Web Assembly from my perspective is that it looks like it will never be ported to Windows Mobile. Edge will get it, but not Mobile at least in its current form (MS may be merging Mobile fully into Windows 10, but that will only be for future, currently "mythical" mobile devices). |
I close this issue, as it is not possible to use this API (https://bugzilla.mozilla.org/show_bug.cgi?id=1427747 closed as WONTFIX). |
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest
When I discovered in #187 that ServiceWorkers were not supported in WebExtensions in Firefox, I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1344561 to ask for it.
I was given a workaround with the webRequest API, which would need to be extended a bit : https://bugzilla.mozilla.org/show_bug.cgi?id=1255894
If this last feature is implemented in Firefox, it might replace the ServiceWorker. Maybe it's a third option after jQuery and ServiceWorker modes?
The text was updated successfully, but these errors were encountered: