22808 teetee 2013-07-25 22:27:32 +0000 Throw if object is constructed without new 2016-11-03 21:15:08 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED FIXED https://bugzilla.mozilla.org/show_bug.cgi?id=916644 [v1] P2 normal --- 1 annevk cam adrianba allen brendan bzbarsky d erik.arvidsson jonas jsbell mike Ms2ger public-script-coord tobie.langel tonyaestill travil public-webapps-bugzilla oldest_to_newest 91290 0 annevk 2013-07-25 22:27:32 +0000 That way we can use [[Call]] for subclassing. It's the ES6 way. We can hopefully still do this as Chrome/WebKit throw, whereas Gecko/Trident do not. 91355 1 bzbarsky 2013-07-28 18:11:26 +0000 Hmm. We can try this; I'm a bit worried about compat impact. :( 91361 2 jonas 2013-07-28 22:47:34 +0000 Same here. I'd add telemetry to Gecko before actually switching behavior. 92840 3 Ms2ger 2013-09-03 07:25:49 +0000 Seems pretty pointless to break something that works. 92888 4 erik.arvidsson 2013-09-03 16:53:15 +0000 (In reply to comment #3) > Seems pretty pointless to break something that works. It doesn't work everywhere and it is future hostile. 93255 5 annevk 2013-09-11 16:30:16 +0000 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. 93408 6 annevk 2013-09-16 06:40:50 +0000 Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=916644 Travis, Adrian, is this on your radar? 93431 7 travil 2013-09-16 17:15:54 +0000 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. 93432 8 erik.arvidsson 2013-09-16 17:20:23 +0000 (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. 93433 9 bzbarsky 2013-09-16 17:32:44 +0000 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. 116374 10 annevk 2014-12-16 12:56:12 +0000 https://bugzilla.mozilla.org/show_bug.cgi?id=916644 was fixed. Let's change IDL. 117059 11 bzbarsky 2015-01-13 03:42:16 +0000 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. 117767 12 erik.arvidsson 2015-02-09 17:04:25 +0000 (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, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-function-objects-call-thisargument-argumentslist we have 2. If F’s [[FunctionKind]] internal slot is "classConstructor", throw a TypeError exception. 117769 13 bzbarsky 2015-02-09 17:10:07 +0000 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. 117770 14 d 2015-02-09 17:12:26 +0000 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. 117771 15 allen 2015-02-09 17:20:26 +0000 (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. 117772 16 bzbarsky 2015-02-09 17:49:58 +0000 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 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist (and modifying http://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". 117773 17 allen 2015-02-09 18:34:54 +0000 (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: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-map-iterable 117774 18 bzbarsky 2015-02-09 18:38:01 +0000 Ah, yes, that would work quite nicely. 125840 19 Ms2ger 2016-04-13 16:06:31 +0000 Talked to bz on IRC; I believe he agrees that checking NewTarget is the best approach. This depends on <https://github.com/heycam/webidl/issues/106>. 127921 20 d 2016-10-22 16:05:40 +0000 https://github.com/heycam/webidl/issues/62 128042 21 tobie.langel 2016-11-03 21:14:46 +0000 Fixed in https://github.com/heycam/webidl/commit/001ba520eb80c23133e65bc721f1f9910732316c