How much longer for HtmlUnit?

[basil]

HtmlUnit is based on the venerable Rhino JavaScript engine, which does not support the optional chaining (?.) operator, spread (...) syntax, or rest parameter syntax (among other newer ECMAScript language features). The Web platform is evolving at a fast pace, and Rhino is increasingly falling behind mainstream browsers. It takes an exceptionally committed group of developers to keep up (cf. LibJS).

The status quo is that we simply avoid using these newer ECMAScript language features in Jenkins core in order to support JTH/HtmlUnit/Rhino in core and plugin integration tests (as opposed to ATH/Selenium). Plugins that use e.g. Bootstrap 5 (which uses the newer rest parameter syntax) cannot be tested with JTH/HtmlUnit/Rhino and must instead be tested with ATH/Selenium. This seems unsustainable.

The last version of ECMAScript that is fully supported by Rhino is 5.1. We could transpile our code to ECMAScript 5.1 to avoid any problems with JTH/HtmlUnit/Rhino, but this seems like an undesirable short-term measure that would negatively impact performance in the production use case for mainstream browsers.

Another solution would be to teach Can I use/Browserslist/Babel which features are (or are not) supported by HtmlUnit/Rhino. Then we could transpile our code to something that would run in JTH/HtmlUnit/Rhino with minimal modifications. This would be a modest amount of effort and would require upstream changes, but it seems relatively achievable in the medium term.

Yet another solution would be to rewrite usages of JTH/HtmlUnit/Rhino in core and plugin integration tests in favor of a mainstream browser using ATH/Selenium (keeping them in their existing repositories or moving them to jenkinsci/acceptance-test-harness being a related but somewhat orthogonal question). Recent versions of Selenium can automatically download the Selenium drivers needed for various browsers, and our Docker images used for CI jobs already have e.g. Chrome installed. For local builds, developers could be instructed to install a browser, or we could skip those tests when a browser is not available (relying on the CI builds instead).

The most challenging aspect of the above is that there are hundreds (if not thousands) of existing core and plugin integration tests, and porting them all from JTH/HtmlUnit/Rhino to ATH/Selenium seems prohibitively impractical. Perhaps the existing JenkinsRule.WebClient interface in JTH could be rewritten in terms of Selenium rather than in terms of HtmlUnit/Rhino? This might break binary (but not source?) compatibility with JTH, making the migration easier (though still not trivial). The interface could then be deprecated in favor of native ATH equivalents, with usages in core and plugin integration tests being gradually migrated to ATH over time.

What I described in the last paragraph seems fairly challenging at first glance. I have no idea whether this is feasible or not, but I think it is worth exploring. Let me know if you are interested in contributing code to this effort.

[basil]

(Developer list thread)