Ignored argument doesn't map to null

VERIFIED INVALID

Status

()

Core
DOM
P3
normal
VERIFIED INVALID
19 years ago
17 years ago

People

(Reporter: Erik Arvidsson, Assigned: vidur (gone))

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
In JS, when a function that needs 1 argument is called with no arguments the
argument gets the value null. This is not the case with the DOM method
insertBefore that is a method of the Node.

When called like below it works
   node1.insertBefore(node2, null)
...but when it is called like this
   node1.insertBefore(node2)
it doesn't work

Updated

19 years ago
QA Contact: 4015 → 4078
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M7
(Assignee)

Comment 1

19 years ago
Hmm...I believe ECMA says that unspecified arguments should default to
undefined. It turns out that we're not failing silently - we generate an error
in the console window. The JS->XPCOM glue code used by the DOM currently
enforces that the correct number of arguments be passed to a DOM method. Passing
null in place of unspecified arguments wouldn't be techinically correct either.

Brendan, any thoughts?

Comment 2

19 years ago
Couple of generic JS points:

1.  Omitted trailing arguments in a call expression result in undefined, not
null, values being passed for the corresponding formal parameters.

2.  In ECMAv2 and our JS implementation, you may use the global predefined
property 'undefined' to denote the undefined value.

3.  Native methods are free to throw an exception or error if not given the
desired number of actual arguments.

All that said, I wonder whether we shouldn't allow trailing arguments to be
omitted where sensible defaults can be imputed.  Vidur, did the DOM working
group consider this issue in language bindings?  What do you think can be done
for methods such as insertBefore?

/be
(Assignee)

Comment 3

19 years ago
The DOM WG was silent on this matter, of course. It may be possible for us to
allow for omitted trailing arguments, but it probably wouldn't be compatible
with other implementations (specifically, IE). If we were to allow them, I'm not
sure how we'd represent optional (or defaulted) arguments in IDL. We could just
pass along null to the native methods for unspecified trailing object arguments
- that would address this specific case, but not the general issue.

Comment 4

19 years ago
Adding some JS and XPIDL guys.

If we ever subsume DOM IDL by XPIDL, we'll need to handle optional trailing args
(document.write, where the number of args is unbounded; document.open, where the
second arg is optional).  Comments on how to express this in IDL solicited.

In JS, you can check how many actuals, or you can check for non-null (and/or not
undefined) trailing args, but be careful with non-null checks: in JS, null ==
undefined while null !== undefined, while when using the JS API, JSVAL_IS_NULL
is true only for null, and JSVAL_IS_VOID is true only for the undefined value.

/be
(Assignee)

Updated

19 years ago
Target Milestone: M7 → M10
(Assignee)

Comment 5

19 years ago
Well...since this is an ongoing discussion and there isn't any urgency in
dealing with the bug, I'm going to move this bug forward.
(Assignee)

Updated

19 years ago
Target Milestone: M10 → M12
(Assignee)

Comment 6

19 years ago
I'm still not inclined to address this one immediately (especially considering
my current bug count). XPConnect guys, care to comment?

Comment 7

19 years ago
I would cite brendan's points and final comment in his first comment. In general
xpconnect is not going 'fix up' missing arguments. There is some discussion on
this issue here:
news://news.mozilla.org/37B577AC.F5905666%40modelworks.com

I argue there and elsewhere that in the cases where optional params or method
overloading needs to be supported in the JavaScript reflection of an object that
some custom nsIXPCScriptable coding will be required. This would be on a per
class basis and a doubt that very many instances will arise.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
I'm marking this INVALID because it's working as designed and desired, and we
want to get stuff like this off vidur's bug-radar.

Comment 9

18 years ago
Mass update of qa contact
QA Contact: phillip → janc

Comment 10

18 years ago
verified
2000-09-15-08-M18
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.