370098 - Some constructors raise a "XXX is not a function" exception when called (DOMParser, XMLSerializer, XMLHttpRequest, XPathEvaluator, XSLTProcessor)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Nickolay_Ponomarev]

Attachment: testcase

> typeof DOMParser 
function
> DOMParser()
TypeError on line 1: DOMParser is not a function

At least the following constructors are affected: DOMParser, XMLSerializer, XMLHttpRequest, XPathEvaluator, XSLTProcessor. Might be worth checking constructors registered via "JavaScript global constructor" category.

Calling these constructors definitely shouldn't say they are not functions, since they are. shaver says they should either throw or just create an object as when called as constructors (this is what some of native JS objects do).

Comment 1

[Peter Van der Beken [:peterv]]

Attachment: v1

This makes calling them as functions work. Note that all DOM prototype objects are of type function, even when they're not callable/constructable. We could easily change that, but not sure what the side-effects will be or whether we care.

Comment 2

[Peter Van der Beken [:peterv]]

Attachment: v1.1

This one makes only constructable DOM classes return "Function" for typeof, others return "Object".

Comment 3

[Peter Van der Beken [:peterv]]

Brendan or Blake: any idea what |typeof Element| should return if you can't really call |Element()| or |new Element()|?

Comment 4

[Brendan Eich [:brendan]]

(In reply to comment #3)
> Brendan or Blake: any idea what |typeof Element| should return if you can't
> really call |Element()| or |new Element()|?

"object"

If you can call Element(), then ECMA-262 says "function", but real-world browsers do not agree. We should err on the side of reality here and go with "object" unless IE and another browser or two say "function".

/be

Comment 5

[Peter Van der Beken [:peterv]]

Attachment: v1.1

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 264044 [details] [diff] [review]
v1.1

 private:
+  nsresult GetNameStruct(const nsGlobalNameStruct **aNameStruct)

Looks like this, and the other method with the same signature, always return either NS_OK an a non-null aNameStruct, or NS_ERROR_UNEXPECTED on failure. Any reason not to make this method return a const nsGlobalNameStruct* and make the callers throw when necessary?

r+sr=jst with that considered.

Comment 7

[Peter Van der Beken [:peterv]]

Attachment: Patch that was checked in

(In reply to comment #6)
> Looks like this, and the other method with the same signature, always return
> either NS_OK an a non-null aNameStruct, or NS_ERROR_UNEXPECTED on failure. Any
> reason not to make this method return a const nsGlobalNameStruct* and make the
> callers throw when necessary?

Did that for the first, but not the second function, because that one sometimes returns NS_OK for a null aNameStruct (looking up the name worked but didn't return anything, so shouldn't throw).

Comment 8

[Peter Van der Beken [:peterv]]

Attachment: Mochitest

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 264235 [details] [diff] [review]
Mochitest

r+sr=jst

Comment 10

[Nickolay_Ponomarev]

The mochitest was checked in on 2007-05-25 09:06 and is passing here and on the tinderbox.

Comment 11

[Ed Lee :Mardak]

Could this have caused bug 400366? I can't seem to find any relevant bugs in the regression window.

javascript:typeof Prototype

.. results in "object"

Comment 12

[Peter Van der Beken [:peterv]]

Yes, probably.