Closed lukewarlow closed 1 month ago
Solution is to do the enforcement before passing the value through to that algorithm.
But pending discussions regarding the [StringContext]
IDL attribute, this issue might resolve itself, as createContextualFragment
will take a union itself and then do the TT enforcement in the algorithm.
How does this work in Chromium today? Does execCommand()
call createContextualFragment()
at a time where it might not expect userland to be able to execute code? Does not sound like a great setup.
Chrome like WebKit doesn't actually implement this as specced from what I can see. It does the TT check inside execCommand and then goes through an editor_command file, which doesn't appear to call createContextualFragment anywhere.
It might be better to specify the TT check inside execCommand()
then.
https://w3c.github.io/editing/docs/execCommand/ is a bit dramatic about its status. It definitely needs to continue to be maintained.
cc @zcorpan
Yes, I've taken on editing of the execCommand spec but haven't gotten to working on it yet.
Okay I've updated https://github.com/w3c/editing/pull/460 to do the enforcement in the editing spec. It will result in the spec doing a double check because createContextualFragment will do one too but the editing spec probably shouldn't call that method anyway, and if it does then we can change the (soon to be upstreamed to HTML) algorithm to take a should do TT check boolean.
It shouldn't call that method directly, ever.
Currently
execCommand
is specced to just pass the union type value through tocreateContextualFragment
algorithm, but TT enforcement doesn't happen in the algorithm it happens in the IDL. So this won't enforce TT and also won't convert the Trusted type object to a string.