htmlunit-core-js differences

[rbri]

The HtmlUnit project uses a slightly modified fork of Rhino (https://github.com/HtmlUnit/htmlunit-rhino-fork / https://github.com/HtmlUnit/htmlunit-core-js).
As discussed in the last developer meeting, I'd like to document the changes here.

General

• At the moment HtmlUnit only uses the interpreter (some of the patches are only implemented for the interpreter)
• The visibility of some methods is enhanced to make these methods available to HtmlUnit

Serialization
HtmlUnit offers serialization support for the page JavaScript and therefore serialization has to be supported by more classes/interfaces.

• AccessorSlot / Getter / MemberBoxGetter / FunctionGetter / Setter / MemberBoxSetter / FunctionSetter

Activation/caller

• Like real browsers, HtmlUnit has to support the caller property of functions. Therefore the activation is always enabled.

Array sorting

• FF browsers support a special feature for comparator functions: instead of only supporting -1/0/1 as return values, boolean values are also accepted. To support this, a new context feature FEATURE_HTMLUNIT_ARRAY_SORT_COMPERATOR_ACCEPTS_BOOL (yes, with the typo :-D) was added and used by ArrayLikeAbstractOperations.

const
There are several longstanding issues with the const support in Rhino (not fixed due to breaking backward compatibility). core-js has some patches to let more js code run:

• Interpreter-DoSetConstVar skips a check to allow the usage of const in for loops; a similar hack is done in ScriptableObject#putConstImpl()
• the Parser is patched to morph 'const' variable declarations into 'let'. This is not correct but lets run a ton of js that would otherwise fail.

function.toString()

• MemberBox.toString() is patched to create a more browser-like representation

Array ctor methods
A bunch of methods are available on the Rhino ctor for historical reasons but they are no longer there in the browsers. The definition of these methods is commented out.

indirect eval() calls

• ScriptRuntime has some patches to support this

Optimization

• SlotMapOwner.createSlotMap() skips the calls to Context.getCurrentContext() and the check for FEATURE_THREAD_SAFE_OBJECTS, because the feature is not set and this hopefully makes the monster a bit faster
• during the build all checks for the language version (and most of the feature checks) are replaced by booleans at the code level to let the compiler remove the unused code.

[aardvark179]

In general these make absolute sense. We've had "make as many feature checks compile time rather than runtime" on our internal TODO list for a while, but it's never to the top of the pile.