You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scripts created by the parser don't have their slot values filled, which formally would cause the default policy invocation in prepare script url and text - and might cause the rejection of the values at parsing time since create an element for the token will append content attributes, to which we're adding validate steps.
When writing the attribute validate steps for scripts, we should accept the value and bail out if the algorithm was called from within HTML parser. We should also set the slot value in attribute change steps for script.src (and, later, for iframe.srcdoc). In fact, it's easier to move the slot setting for scripts to attribute change steps (right now it's defined at IDL level in https://w3c.github.io/webappsec-trusted-types/dist/spec/#setting-slot-values).
I'm not sure yet what to do with script bodies.
The text was updated successfully, but these errors were encountered:
Scripts created by the parser don't have their slot values filled, which formally would cause the default policy invocation in prepare script url and text - and might cause the rejection of the values at parsing time since create an element for the token will append content attributes, to which we're adding validate steps.
When writing the attribute validate steps for scripts, we should accept the value and bail out if the algorithm was called from within HTML parser. We should also set the slot value in attribute change steps for
script.src
(and, later, foriframe.srcdoc
). In fact, it's easier to move the slot setting for scripts to attribute change steps (right now it's defined at IDL level in https://w3c.github.io/webappsec-trusted-types/dist/spec/#setting-slot-values).I'm not sure yet what to do with script bodies.
The text was updated successfully, but these errors were encountered: