Re: [whatwg/webidl] Add `{{StringContext}}` extended attribute (PR #1392)

@lukewarlow commented on this pull request.



> @@ -11056,6 +11091,21 @@ allowed.  The security check takes the following three inputs:
 
 Note: The HTML Standard defines how a security check is performed. [[!HTML]]
 
+Certain algorithms are defined to
+<dfn id="dfn-validate-the-string-in-context" export>validate the string in context</dfn> on a given
+value. This check is used to determine whether a given value
+is appropriate for its {{StringContext}}. This validation takes the following four inputs:
+
+1.  the [=platform object=] on
+    which the operation invocation or attribute access is being done,
+1.  the value to validate,
+1.  the {{StringContext}} [=identifier=], and
+1.  the [=identifier=] of the operation or attribute.
+
+The algorithm returns an ECMAScript value, or [=JavaScript/throws=] a <l spec=ecmascript>{{TypeError}}</l>.
+
+Note: The HTML Standard defines how the validation is performed. [[!HTML]]

> It's not clear it always ends up throwing a TypeError. Doesn't this involve userland for some bits?

Yeah you're correct this can throw any error type.

> It seems this algorithm might also end up reporting violations per step 6.1

Also correct it can report CSP violations.

> I don't think "validate" is a sufficiently clear term given the implications. "Validate" makes me expect a side-effect-free-boolean-returning operation, not something that can result in network traffic (and events?).

Maybe verify instead? I'm not sure what prior art there is for this sort of thing.

> Apart from the above, we'll need some test coverage to ensure that this is invoked at the correct time relative to other exceptions that can be thrown. This will be observable if this can throw non-TypeError exceptions, but even if this always throws a TypeError (and we ignore the message field) it's observable through network traffic.

Additional tests to ensure timing wrt to other errors makes sense here. cc @mbrodesser-Igalia 

As for the network traffic aspect, I'm not familiar with the details of how CSP violation reports work and whether their timing is an observable concern.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1392#discussion_r1549906403
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1392/review/1977078715@github.com>