If this is about having someone maintain kjs: I am happy to do this again. I just wanted to pick this up anyway as I have a big set of patches waiting from a fork of mine.

I didn't know about the KRename usage and cannot say anything about it.

I recall the (little) JS support in Okular. The API to-be-implemented is LARGE. Anyone willing to do it without another JS engine? Unlikely I guess. Are there any particular features that the Okular developer and users want to see implemented? Or is this just about removing dependencies to unmaintained code?

The sub-tasks are just about moving away from unmaintained code, in order to pave the way for dropping in KJS in KF6. However, that is all based on the assumption that KJS stays in its current unmaintained state (last actual feature change seems to be from 2014, last actual bugfix from 2016). Should that change I think all this can be reconsidered.

I applied the first fixes/additions (https://cgit.kde.org/kjs.git) and tests (https://websvn.kde.org/trunk/tests/khtmltests/regression/tests/js/).

A bit of clean-up was done to bugs for konqueror/kjs. As usual most of them belong into other components as they are not due to plain JS issues.

My personal goal is to achieve a close compatibility to current ECMAScript 2018. Whatever work would be needed for ensuring that Okular and KRename still works would be trivial. But if the respective maintainers have extension wishes please let me know.

*If* kjs remains (my wish) the tests (see above svn URL) should maybe be merged into the kjs.git repository?

Yes, moving the tests into the kjs.git repository would make a ton of sense.

Hi, do we really want to revive kjs? We did a lot of work to actually port over many things first to QtScript and then to QJSEngine to avoid that we have 2-3 different scripting engines in use in our stuff.
Could the enhancements you plan for kjs not benefit QJSEngine, too, or are there fundamental different goals for both engines?

If we don't keep KJS we're probably end up copying it inside Okular since it's the only Qt JS engine that supports the "please break after N seconds", since we need to make sure people don't put an infinite loop JS in PDF files

Perhaps copying it there might be better than creating the impression that people should really use it for other stuff, if Okular is the only "big" last user of this.

ref aacid, I see that people port a bit blindly (qjsengine has a lot of non-obvious differences both with qtscript and kjs).

e. g. qtcreator couldn't use qjsengine for a long time because of this (qjsengine not having kjs' timeoutchecker). I see that they've added a QJSengine::setInterrupted() (earlier they suggested injecting something throwing a js exception that couldn't be catched), but I think that needs to be manually called from a qtimer living in a separate thread.