Re: [heycam/webidl] Modernize invoking user code (#113)

> Hmm, I must be missing what the connection is between entry settings object and exception handling?

See https://github.com/whatwg/html/issues/958#issuecomment-218624203

> Maybe that was agreed upon in some earlier thread I forgot or was before my time.

Before your time.

> To match Chrome's behavior, I guess we would have event dispatch specifically report errors to the EventTarget object's relevant settings object.

I don't think we should match Chrome's behavior.  I think Chrome should align with what the spec at least used to say before people started messing with it and what everyone agreed we should do the last time this was discussed.  Specifically, in the simple case of a function callback the error is reporter to the global of that function.  The hard cases can then be figured out, as long as the simple case works correctly.

> One solution is to do here what I did below for "get a user object's attribute value": use value's callback context's settings object's realm execution context.

The "callback context" thing was added to propagate the incumbent, right?  I don't think it's the right thing.

> I guess it would give B in both cases?

No, as far as I can tell it would give D: the window that made the addEventListener call.

> Another solution is to acknowledge that all objects have a realm, not just functions, and then use O's realm. 

That's basically what Firefox does.

> new Function uses the currently active script-or-module to fill the created function's [[ScriptOrModule]]. The currently active script-or-module is your main-document <script> tag. 

Hrmm.  That seems ... weird.  I think people using `new someWindow.Function` would expect that to act just like a function declared in someWindow.  It claims to be instanceof that window's `Function`, for sure.  

But looking at the actual spec at http://www.ecma-international.org/ecma-262/6.0/#sec-function-constructor it gets the "active function object".  This is defined as:

> The value of the Realm component of the running execution context is also called the current Realm. The value of the Function component of the running execution context is also called the active function object.

and in this case it gets set up by http://www.ecma-international.org/ecma-262/6.0/#sec-built-in-function-objects-construct-argumentslist-newtarget which references http://www.ecma-international.org/ecma-262/6.0/#sec-built-in-function-objects-call-thisargument-argumentslist which sets the active function object to the built-in function being called/constructed.    Of course there is no script-or-module in any of that stuff...

> This is window A in both your examples. (But, if we modified them to declare the function in window B or C, it would be window B or C.)

I think this would confuse people a lot.  People expect functions created with `new someWindow.Function` to act like functions defined in that window, from everything I've seen.



---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/113#issuecomment-218626401