select.remove() with no arguments removes first option instead of itself from the DOM

[duonglaiquang]

Problem in brief

The HTML spec defines two remove behaviors for HTMLSelectElement:

• remove() — inherited from ChildNode, removes the element from the DOM
• remove(long index) — removes the option at the given index

Currently, HtmlUnit always dispatches remove() to remove(int) with index = 0, removing the first option instead of the element itself.

Reproducing

var select = document.getElementById('mySelect');
// select has 3 options and is inside a <form>

console.log(select.options.length);   // 3
console.log(select.parentNode);       // [object HTMLFormElement]

select.remove();

// Expected:
console.log(select.options.length);   // 3
console.log(select.parentNode);       // null

// Actual (HtmlUnit):
console.log(select.options.length);   // 2 (first option removed!)
console.log(select.parentNode);       // [object HTMLFormElement]

Root cause

The @JsxFunction HTMLSelectElement.remove(int index) shadows the inherited Element.remove().
When Rhino dispatches select.remove() with no arguments, it calls remove(int) and coerces the missing argument to 0.

Suggested fix

Change the parameter type to Object and check for Undefined to detect the no-argument case:

 @JsxFunction
- public void remove(final int index) {
+ public void remove(final Object index) {
+     if (JavaScriptEngine.isUndefined(index)) {
+         super.remove();
+         return;
+     }
+
+     final int i = (int) JavaScriptEngine.toNumber(index);
-     if (index < 0 && getBrowserVersion().hasFeature(JS_SELECT_REMOVE_IGNORE_IF_INDEX_OUTSIDE)) {
+     if (i < 0 && getBrowserVersion().hasFeature(JS_SELECT_REMOVE_IGNORE_IF_INDEX_OUTSIDE)) {
          return;
      }
      // ...
  }

Note: This fix has a minor edge case — select.remove(undefined) should remove the option at index 0
(undefined coerced to 0), but with this fix it behaves the same as select.remove() (removes from DOM).
This is because Rhino currently cannot distinguish no-argument calls from explicit undefined arguments — see the notes section below.

Notes on Rhino's handling of missing arguments vs explicit undefined

FunctionObject pads missing arguments with Undefined.instance before calling convertArg:

Object arg = (i < argsLength) ? args[i] : Undefined.instance;

This means both select.remove() (no args) and select.remove(undefined) (explicit undefined) arrive
at the Java method as Undefined.instance, making them indistinguishable when the parameter type is Object.

Changing the parameter type to Scriptable does not help either — convertArg for JAVA_SCRIPTABLE_TYPE
calls ScriptRuntime.toObjectOrNull(), which coerces both null and undefined to null.

It would make more sense for undefined to be coerced to Undefined.SCRIPTABLE_UNDEFINED rather than null.
This way, Java code could distinguish a missing argument from an explicit undefined argument.

A complete fix would require addressing this issue in htmlunit-core-js.

[rbri]

Hi @duonglaiquang, will have a look...

[rbri]

@duonglaiquang please have a look at my fix, maybe you have more test cases in mind...

[duonglaiquang]

Oh cool. I did tried the same static signature but it thrown org.htmlunit.ScriptException: Method "remove" must be static with the signature "(Context cx, Scriptable thisObj, Object[] args, Function funObj)" to define a variable arguments function exception so i thought it's not possible and settled with the Object type.
Something must have been changed since the version i'm using (4.17).
Thanks a lot 😄