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

> The current spec seems oriented around filling those in, based on the "relevant script".

Ah.  The "relevant script" there is the one throwing the exception (but even then, that's not true; if an Error is created at one place but thrown at another, it's the creation point that gets reflected in the filename in browsers in practice).  It has absolutely nothing to do with incumbent, entry, where the exception is reported, etc.

> (We could change that to use the object in both cases, but that seems weird to me. I'm flexible though.)

Fwiw, Firefox uses the same entry settings for the Get and the call to the gotten thing.  Setting up this stuff is not that cheap, so I would rather not do it twice, honestly, unless there are strong reasons to do so.

> "Report the exception" gets modified to take an exception object, a global object, a filename/line number/column number tuple, and an optional script.

s/exception object/exception value/, right?

> We add a new optional flag to all of these four user-code-calling operations: "guarded", default unset.

It should probably be default set.  See the categorization of the various places in the platform that invoke this stuff as of a few years ago in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17713#c16 -- pretty much everything wants to report the exception.

> I'm not sure if we should immediately call out to "report the exception" before un-entryifying the appropriate global

I'm not sure it matters in practice, if we're explicitly passing in the global anyway.

> Timer functions, when supplied a string: their CSP checks will "report the exception" if CSP blocks string compilation.

I don't think that should be happening.  There should be CSP reporting, sure, but no firing of "error" events in this situation, right?  I haven't tested what UAs do in detail here, but Gecko at least will simply return 0 from the setTimeout call, not schedule anything, and report the CSP violation if the policy asked for reports.

> This will need a bit of care to capture the active script at the time setTimeout() et al. are called so it can be used for muted-errors checks later.

I don't think it's worth worrying about, honestly.  The muted error checks are really important for syntax errors.  For everything else they're mostly not that important.  Certainly I don't think UAs go out of their way to do anything complicated for the string setTimeout case here, and I don't think the spec should either.

The plan sounds good in general!  Thank you for thinking through this.

---
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-218659077