-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Inline JS of zimit ZIMs is not working properly #1281
Comments
OK, if this is a blocker to get Zimit video working, I guess this is the new TOP priority issue. |
It looks like it is a very distinct issue |
@benoit74 OK, so far we have done our best to remove all inline JS because this is not supported in Kiwix JS (and there is - looks like - no way to fix this). @Jaifroid could confirm. We had an effort specifically about that 2 years ago. This is actually still a constraint applying on all our custom scrapers if we want to continue to have things working on Kiwix JS. This is very important. This is the reason why this limitation of Kiwix Desktop has not been considered properly. But if this impacts ZIMit, where we have less control about the page content, then we will have to find a fix here with high priority. |
The specific inline JS of the test website is working fine inside Kiwix PWA ... no idea why. |
Morning all. The restriction on inline JS (and eval, and a few other things) only affects the Chrome and Firefox Browser Extensions when they are running in Restricted mode (or in ServiceWorkerLocal mode in the case of Chrome). There is no workaround to run JS in the ZIM in those contexts. Chrome (and Chromium derivatives) happen to be the most popular platform on which Kiwix JS runs. There is a workaround for browsers which fully support ServiceWorker mode from a secure origin. This is effectively to "abandon" the extension, and redirect users to a secure offline-first PWA (https://browser-extension.kiwix.org). I introduced this workaround a couple of years ago so that we could support dynamic ZIMs such as Zimit-based ZIMs. PWAs are not restricted (except by a custom CSP controlled by the developer), and can run inline JS and even eval, because the origin is secure. But of course, redirecting to a PWA requires at least limited access to the Internet the first time the user does this. We just have to accept that in Browser Extension context. While the userbase who would use the Browser Extension entirely in local modes is diminishing, we have historically made a big effort, as @kelson42 says, to remove unnecessary inline JS from standard ZIMs that can be read in Restricted mode. It needlessly places an obstacle in front of users with old PCs and old browsers, who just want offline Wikipedia (the most common use case). Hence the reason for my hyper-vigilance about finding any inline JS creeping in to baseline ZIMs such as Wikimedia projects. |
@benoit74 It's perfectly fine to use the PWA (pwa.kiwix.org or browser-extension.kiwis.org, either is fine) to run those tests, as they are tests of Zimit, which by definition requires a lot of inline JS which is fully supported by PWAs. So no problem there on my side. |
Thanks for all the details @Jaifroid ! |
While opening in
Now going to debug why the URL scheme "zim://" isn't available to the Fetch API. |
See also #917 |
Looks like the only fix to this issue is to use Qt 6.6 or newer - see https://stackoverflow.com/questions/64892161/qtwebengine-fetch-api-fails-with-custom-scheme |
Would you be able to implement the fix based on qt6+? FYI, once 2.4 release, the first thing I would like to do would be to move to QT6 as default (only?) version and library for our binaries. |
AFAIK the Fetch API requires a secure context (HTTPS) when used with modern browsers, with a few specific exceptions (requests to localhost and 127.0.0.1, file:// URLs, dev environments on port 80). Fetch is closely tied to the Service Worker spec, and secure environment prevents man-in-the-middle attacks, etc. To support Fetch fully, you might need to switch to having an internal server. This is very similar to what I had to do with the Electron KJS app, as there is no way to get some zimit-based content working when using from chrome:// and moz-extension:// URL schemata. For me there were only two solutions:
|
@kelson42 Note that switching to qt6 is not enough. For example, on Ubuntu 22.04 jammy (our next likely default build platform after Ubuntu 20.04 focal's standard security maintenance five year period ends) the version of Qt 6 is 6.2.4 (the needed fix first appears in Qt 6.6). |
I understand that we won't have a 100% fix even by fixing right now, but (1) we have to move to Qt6 to allow to fix the bug (2) This is important bug which has to be fixed in prio (3) We have to live with what we can't change - at least we are ready. I have moved this topic to |
#1276 has revealed that on both Windows and Linux, all tests linked to inline JS are not working properly.
These are tests 01* of "Javascript" page of the ZIM available at https://dev.library.kiwix.org/#lang=eng&q=zimit+test+website
Do not mind about tests 08* and 09*, they are known to not be reliable yet due to other issues not yet solved in zimit/warc2zim.
These tests are known to work ok on all readers (kiwix-desktop is probably the last one not yet tested), at least I'm 100% sure they do work on kiwix-android, kiwix-apple, kiwix-serve, kiwix-js
These tests are very specific to zimit/warc2zim. They rely on proper operation of wombat, the JS library used by zimit/warc2zim ZIMs to replace dynamically / on-the-fly URLs loaded by JS code. It is hence "normal" that the URL inside JS code is "online", it will be rewritten by wombat to the proper in-ZIM URL.
The text was updated successfully, but these errors were encountered: