[Bug 22808] Throw if object is constructed without new

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Anne annevk@annevk.nl changed:

       What    |Removed                     |Added

        Summary|Throw if you object is      |Throw if object is
               |constructed without new     |constructed without new
Contact us to advertise here
# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #1 from Boris Zbarsky bzbarsky@mit.edu ---

Hmm. We can try this; I'm a bit worried about compat impact. :(

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Jonas Sicking jonas@sicking.cc changed:

       What    |Removed                     |Added

             CC|                            |jonas@sicking.cc

--- Comment #2 from Jonas Sicking jonas@sicking.cc ---

Same here. I'd add telemetry to Gecko before actually switching behavior.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Cameron McCormack cam@mcc.id.au changed:

       What    |Removed                     |Added

     Whiteboard|                            |[v1]
# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Ms2ger Ms2ger@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |Ms2ger@gmail.com

--- Comment #3 from Ms2ger Ms2ger@gmail.com ---

Seems pretty pointless to break something that works.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #4 from Erik Arvidsson arv@chromium.org --- (In reply to comment #3)

Seems pretty pointless to break something that works.

It doesn't work everywhere and it is future hostile.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #5 from Anne annevk@annevk.nl ---

Also, at least for new objects we should no longer do this. So if we need this I suggest we call it out. E.g. by requiring LegacyConstructor or some such for those objects.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Anne annevk@annevk.nl changed:

       What    |Removed                     |Added

             CC|                            |adrianba@microsoft.com,
               |                            |travil@microsoft.com

--- Comment #6 from Anne annevk@annevk.nl ---

Gecko: bugzilla.mozilla.org/show_bug.cgi?id=916644

Travis, Adrian, is this on your radar?

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #7 from Travis Leithead [MSFT] travil@microsoft.com ---

I'm pretty hesitant to make this change without a web-compat analysis. I can very easily imagine lots and lots of sites that just blindly do:

var x = XMLHttpRequest(); x....

In the past, IE has run a lot of custom code on the web intended just for it. With IE11, we're starting to run much more of the Firefox/Chrome code, but in this case, not throwing is more compatible. Switching to a throwing behavior has generally made compat worse.

If you want to take on the burden of proof, that'd be great. I'm just saying that I don't think I'd want to be the one to guinea-pig this change.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #8 from Erik Arvidsson arv@chromium.org --- (In reply to Travis Leithead [MSFT] from comment #7)

I'm pretty hesitant to make this change without a web-compat analysis. I can very easily imagine lots and lots of sites that just blindly do:

var x = XMLHttpRequest(); x....

Remember that that throws in Safari and Chrome so it is unlikely that code on the open web would do that.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #9 from Boris Zbarsky bzbarsky@mit.edu ---

Once I get Gecko to the point where our own code is not triggering this situation, I'll put in some telemetry to see how often this is hit in practice on the web for us....

so it is unlikely that code on the open web would do that.

Methinks you underestimate the amount of UA-sniffing that happens "on the open web".... I think it very likely that code would do that; the only question is how common it is for users to run across that code in practice.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Anne annevk@annevk.nl changed:

       What    |Removed                     |Added

       See Also|                            |[https://bugzilla.mozilla.or](https://bugzilla.mozilla.or)
               |                            |g/show_bug.cgi?id=916644

--- Comment #10 from Anne annevk@annevk.nl --- bugzilla.mozilla.org/show_bug.cgi?id=916644 was fixed. Let's change IDL.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #11 from Boris Zbarsky bzbarsky@mit.edu ---

I just looked at ES6 again, and I'd like to see the edits Allen is making to the whole [[Call]]/[[Construct]]/@@create setup right now land before we change things in IDL here. Because we're going to need to override [[Construct]] to not invoke [[Call]] and whatnot, but the exact interaction will depend on exactly what ES looks like.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #12 from Erik Arvidsson arv@google.com --- (In reply to Boris Zbarsky from comment #11)

I just looked at ES6 again, and I'd like to see the edits Allen is making to the whole [[Call]]/[[Construct]]/@@create setup right now land before we change things in IDL here. Because we're going to need to override [[Construct]] to not invoke [[Call]] and whatnot, but the exact interaction will depend on exactly what ES looks like.

In ES6, constructor functions created using the class syntax gets marked with "classConstructor" and in the [[Call]] behavior,

people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-function-objects-call-thisargument-argumentslist

we have

  1. If F’s [[FunctionKind]] internal slot is "classConstructor", throw a TypeError exception.
# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #13 from Boris Zbarsky bzbarsky@mit.edu ---

OK. So it sounds like for Web IDL constructors we should make the following changes:

1) [[Construct]] does what [[Call] does right now in the Web IDL spec. 2) [[Call]] just throws a typeerror.

Or we could use the default [[Call]] and set the [[FunctionKind]] thing, but it seems simpler to just do the above, I think.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

             CC|                            |d@domenic.me

--- Comment #14 from Domenic Denicola d@domenic.me ---

I'd rather do the default [[Call]] and set functionKind. functionKind might be used for other things (maybe it already is?) and in general uniformity with ES6 seems better.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Allen Wirfs-Brock allen@wirfs-brock.com changed:

       What    |Removed                     |Added

             CC|                            |allen@wirfs-brock.com

--- Comment #15 from Allen Wirfs-Brock allen@wirfs-brock.com --- (In reply to Domenic Denicola from comment #14)

I'd rather do the default [[Call]] and set functionKind. functionKind might be used for other things (maybe it already is?) and in general uniformity with ES6 seems better.

the "default call" and the [[FunctionKind]] slots are specific to "ECMASCript Language functions". In other words, functions whose body are implemented using ECMAScript code.

You want to enable WebIDL methods to be implemented as ECMAScript functions but you don't want to require it.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #16 from Boris Zbarsky bzbarsky@mit.edu ---

So I just looked through the ES6 spec. The only other use of [[FunctionKind]] is to prevent subclassing a generator function. This use assumes that anything without a [[FunctionKind]] slot is not a generator, so works fine with Web IDL.

What we could consider is giving a [[FunctionKind]] slot to what the spec calls "Built-in Function objects" and checking it in people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist (and modifying people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-construct-argumentslist-newtarget to not check it, I guess). That's assuming we don't want the existence of a [[FunctionKind]] slot to imply the function is an "ECMASCript Language function".

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #17 from Allen Wirfs-Brock allen@wirfs-brock.com --- (In reply to Boris Zbarsky from comment #16)

The problem is that many of the ECMAScript library constructors, which are allspecified to be "Built-In Function objects", do support being "called as a function". So if we added [[FunctionKind]] to Built-in Function I would also have to specify it's setting for each ES built-in. I might consider doing that if I wasn't within about a week of having to freeze the final ES6 draft.

As an alternative approach consider treating this similarly to what you do for parameter type checking. You can determine whether you are called by as function rather than via [[Construct]] by checking the value of NewTarget. It has the value undefined if the function is being invoked via [[Call]].

So, in your WebIDL parameter checking also check NewTarget (for constructors).

This is essentially what the ES6 spec. does, individually for each built-in constructor that is not callable. For example see: people.mozilla.org/~jorendorff/es6-draft.html#sec-map-iterable

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #18 from Boris Zbarsky bzbarsky@mit.edu ---

Ah, yes, that would work quite nicely.

# bugzilla at jessica.w3.org (2 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

teetee tonyaestill@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |tonyaestill@gmail.com
          Alias|                            |teetee
# bugzilla at jessica.w3.org (a year ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

--- Comment #19 from Ms2ger Ms2ger@gmail.com ---

Talked to bz on IRC; I believe he agrees that checking NewTarget is the best approach. This depends

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

         Status|NEW                         |RESOLVED
     Resolution|---                         |MOVED

--- Comment #20 from Domenic Denicola d@domenic.me --- heycam/webidl#62

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Tobie Langel tobie.langel@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |tobie.langel@gmail.com

--- Comment #21 from Tobie Langel tobie.langel@gmail.com ---

Fixed in heycam/webidl/commit/001ba520eb80c23133e65bc721f1f9910732316c

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22808

Tobie Langel tobie.langel@gmail.com changed:

       What    |Removed                     |Added

     Resolution|MOVED                       |FIXED

Want more features?

Request early access to our private beta of readable email premium.