12635 2011-05-08 23:56:11 +0000 calling Functions corresponding to IDL operations/attributes on unexpected objects should throw 2011-06-28 04:59:46 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED FIXED P2 normal --- 12320 1 cam cam bzbarsky hsteen ian mike public-script-coord public-webapps-bugzilla oldest_to_newest 48338 0 cam 2011-05-08 23:56:11 +0000 Bug 11857 comment 6 brings up the cases like `window.alert.call(document, 'Do you see this alert?')`. We should make this throw a TypeError. Another case is getters/setters for IDL attributes, like `Object.getOwnPropertyDescriptor(document, "nodeType").get.call(window)`. 48340 1 hsteen 2011-05-09 00:29:15 +0000 (Was the summary supposed to say "*un*expected objects" - or is it just me not understanding WebIDL terminology yet? :-)) 48341 2 cam 2011-05-09 00:34:11 +0000 I do try to keep the terminology as confusing as possible. :) 48342 3 hsteen 2011-05-09 00:43:29 +0000 Another way to hit the same problem is of course to do document.alert=window.alert; document.alert('If a document pops up an alert and nobody sees it, does it still pop up?'); 48344 4 bzbarsky 2011-05-09 01:12:41 +0000 The other case where this come up is this: function f() { } f.prototype = document; var d = new f(); d.write("What happens here?"); Some UAs throw in this situation; some actually invoke the native write function on the document. I would prefer throwing, as the represetative of one of the UAs which currently does NOT throw here but would like to change that behavior. 48345 5 cam 2011-05-09 03:06:59 +0000 I've added back the check (which I am sure used to be in there) for calling Functions that correspond to IDL operations so that it throws a TypeError if the 'this' object is not an object that implements the relevant interface. (This check was already present for most of the other Function cases, like getter/setter Functions.) Whether an object "implements" a given interface is still kinda hand-wavey, but the intention is to throw for cases like comment 4. I'll try to come up with a rigorous definition of "implements" as part of bug 12320. 48465 6 hsteen 2011-05-11 05:19:05 +0000 Noticed apf.setZeroTimeout=(apf.isIE&&apf.isIE<9)||apf.isO3||apf.isAIR?setTimeout:(function(){ . . in cloud9ide's source. Now, this might simply be breaking browsers they don't bother testing in..but if this is actually tested code, it seems having a pointer to setTimeout on another object will work in some browsers. 50384 7 cam 2011-06-28 03:40:11 +0000 (In reply to comment #6) > Noticed > > apf.setZeroTimeout=(apf.isIE&&apf.isIE<9)||apf.isO3||apf.isAIR?setTimeout:(function(){ > . . > > in cloud9ide's source. Now, this might simply be breaking browsers they don't > bother testing in..but if this is actually tested code, it seems having a > pointer to setTimeout on another object will work in some browsers. That doesn't appear to work today: http://people.mozilla.org/~cmccormack/tests/settimeout-this.html 50387 8 hsteen 2011-06-28 04:59:46 +0000 I've reached the same conclusion - site is probably simply broken..