Remove mediawiki.page.ready.js from recent mediawiki archives because it breaks the iframe

[Jaifroid]

This is the PWA-specific version of openzim/mwoffliner#1803, for providing a quick-and-dirty patch for removing this archive. It is currently known to affect Wiktionary archives since 2023-02, but could well start cropping up in other mwOffliner archives.

[Jaifroid]

@danielzgtg I have implemented a fix for this in the test version of the PWA:

https://kiwix.github.io/kiwix-js-windows/www/index.html

Perhaps you could verify? Please note that if you have used the test PWA before, you will need to let it update to v2.3.8. It will notify you about 10 seconds after launch (in Configuration) if it needs a restart to do so. If it is already showing v2.3.8 when you first launch it, you should be good to go. Please test without Tampermonkey script enabled.

The patch, and other modifications to CSS and JS in this reader are gated behind the option circled in screenshot below. Leave this on to test. Also, it needs to be tested in ServiceWorker mode.

To test without this patch and some other modifications to Wikimedia archives, you can turn this option off, but in that case the latest Wiktionary archive will break out of the iframe.

Once thoroughly tested here, I'll backport just the part that prevents Wiktionary from being read to Kiwix JS if it looks like fixing this at source (in mwOffliner) is complicated or likely to be delayed.

[danielzgtg]

I have verified that your fix works! The main Wiktionary page remained normal for longer than a few seconds, and I was able to search for and open the article named "wiki".

The option was left on initially, and displayed fine right away. When I turn off the option, I reproduced the zim breaking out, and when I turned the option back on, the zim behaved normally again.

The website had 2.3.8 and ServiceWorker shown right away after I loaded it. I never added this domain to my userscripts, but I disabled the entire Tampermonkey extension for the duration of these tests just in case.

EDIT: Also tested in Chrome in addition to Firefox. The test had the same results, except I had to rename the zim file on disk to regain control after disabling the option before being able to reenable it.

[Jaifroid]

Thank you very much for testing this so carefully.

[Jaifroid]

This fix is now included in v2.4.0. There are two mechanisms of protection: one removes the offending JS (a Wiktionary-specific fix until openzim/mwoffliner#1803 is fixed at source), and the other is the implementation of the sandbox attribute on the iframe.

Many thanks to @danielzgtg for helping to identify the issue and suggesting the sandbox solution, which makes the app more robust even if it would not ultimately stop a determined malicious actor.

Closing, but the fix should be backported to Kiwix JS for the next release.