inline JS

We've previously agreed that inline JS should be banned from scrapers (see kiwix/kiwix-js#789, kiwix/kiwix-js#865, and sister issues).

In #52, I've proposed to remove inline JS from some recent Vue-based scrapers.

In openzim/mwoffliner#2483, we are worried about having inline JS and use of eval in mwoffliner ZIMs.

Current policy

We however clearly miss good understanding of why, when, how we should be worried about inline JS in ZIMs.

And there is no clear written policy.

And there is also a problem with the use of eval, and other things which might be blocked.

The core of the issue around inline JS and use of eval is that CSP of the "browser" used in Kiwix reader might block these.

It looks like these are however real edge cases, and simply forbidding inline JS is not the right policy.

Note that @Jaifroid proposed a more relaxed policy in #52 (comment)

Current status

But before all, can we list scenario where inline JS and eval are still causing a problem?

Both inline JS + eval are used in freecodecamp ZIMs, so I tried to open freecodecamp_en_all_2025-07.zim and this ZIM is working well under:

• kiwix-android 3.14.0 on Android 13
• kiwix-apple 3.11.0 (build 235) on Mac OS Sequoia 15.6
• kiwix-desktop 2.4.1 on Windows 10
• kiwix-serve 3.7.0-1 on Firefox 143 on Mac OS Sequoia 15.6
• kiwix-pwa 3.7.6 in "Trusted source" Service worker mode on Firefox 143 on Mac OS Sequoia 15.6
• kiwix-js 4.2.2 (from https://kiwix.github.io/kiwix-js/www/index.html) in "Trusted source" Service worker mode on Chrome 140 on Mac OS Sequoia 15.6

It is not working in:

• kiwix-pwa 3.7.6 in "Restricted" mode on Firefox 143 on Mac OS Sequoia 15.6
• kiwix-js 4.2.2 (from https://kiwix.github.io/kiwix-js/www/index.html) in "Restricted" mode on Chrome 140 on Mac OS Sequoia 15.6

These are obviously cutting-edge versions of our readers, and experience might vary with older versions (but this should probably be considered more like a bug than a limitation).

Do you have other experiences where inline JS or eval is causing a problem?

Overall problem

It is probably important to note that the fact that our ZIMs are requiring (mostly non-free) JS to run is even a big no-go for some people.

Proposition

From my PoV our policy should more focus on:

• always providing a no-JS fallback in all ZIMs
• when possible, the no-JS fallback should be very good (like in mwoffliner where many Mediawikis already focus on having a very good no-JS version)
• when not possible, the no-JS fallback should:
  • at least provide access to an explanation about the fact that the ZIM requires Javascript to run (e.g. freecodecamp)
  • ideally provide some way to access ZIM resources (e.g. Youtube and TED where a basic HTML-only listing of videos would probably satisfy most users experiencing issues with JS)