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

>                  <li>
>                    Let <var>arg</var><sub>0..<var>n</var>−1</sub> be a list of
>                    ECMAScript values, where <var>arg</var><sub><var>i</var></sub> is the result
>                    of <a class="dfnref" href="#dfn-convert-idl-to-ecmascript-value">converting</a>
>                    <var>idlarg</var><sub><var>i</var></sub> to an ECMAScript value.
>                  </li>
> -                <li>Let <var>script</var> be the <a class="dfnref" href="#dfn-callback-context">callback context</a> associated with <var>V</var>.</li>
> -                <li>Push <var>script</var> on to the <a class="dfnref external" href="http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html">stack of incumbent scripts</a>. <a href="#ref-HTML">[HTML]</a></li>
> +                <li>Let <var>execution context</var> be <a class="external" href="https://tc39.github.io/ecma262/#sec-getfunctionrealm">GetFunctionRealm</a>(<var>X</var>)'s <a class="dfnref external" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-realm-settings-object">settings object</a>'s <a class="external" href="https://html.spec.whatwg.org/multipage/webappapis.html#realm-execution-context">realm execution context</a>.</li>

No, this doesn't work, I think.  The reason it doesn't work is that you're too late: you may already have thrown an exception from the `Get` above, and that needs to report the exception, and that needs the entry settings stuff, because that's where exceptions get reported, right?

I put together two interesting testcases: <http://web.mit.edu/bzbarsky/www/testcases/settings-objects/entry-settings-1.html> and <http://web.mit.edu/bzbarsky/www/testcases/settings-objects/entry-settings-2.html> -- on both you need to click the "click me" text .  The first one uses an element from window A, adds a listener that is an object created from window B, whose `handleEvent` property is a function from window C that throws.  The second one uses an element from window A, adds a listener that is an object created from window B, whose `handleEvent` property has a getter that is a function from window C that throws.

In Firefox, both cases use window B as the place to fire error events, and entry settings object. 

In Chrome, they both seem to use window A as the place to fire error events (because of where the listeners are attached, iirc how this works in Chrome); not sure whether that precisely corresponds to entry settings in Chrome.

In Safari, the behavior is the same as in Chrome (uses window A) for the first testcase and the second testcase doesn't fire any error listeners.  Again, not sure what the actual entry settings thing is.

In Edge, the first testcase doesn't fire error listeners afaict and the second one fires them in window B.   Again, not sure what the actual entry settings thing is.

This spec as written (with your changes) would fire listeners in window C on the first testcase and has undefined behavior on the second one, as far as I can tell.

---
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/files/2687a7f8dee42781c250ffc11c084f1ef84d1bf4#r62931654