Re: [w3c/editing] Should execCommand dispatch beforeinput or not? (#200)

> From point of view of different position, there is consistency between setting `.value` and `execCommand()` if browsers don't dispatch `beforeinput` for every changes from JS.

I don't follow what you're saying here. What consistency are we talking about? What about `.value` and `execCommand()`?

> We've already been struggling with mutation event listeners for avoiding security issues so that I don't want new path to nesting edit actions.

This isn't really anything to do with historical source of security bugs in editing, which stems from firing events in the middle of editing commands. Since `beforeinput` event gets dispatched before the browser engine starts making DOM mutations for the editing command, in terms of reentrancy problem, it's akin to executing arbitrary scripts before entering editing command, which scripts can already before invoking `document.execCommand`.

> I feel it's odd. `Event.isTrusted` should be set to true if it's dispatched by browser and even if it's caused by JS API.

This is why I suggested an alternative which is to add a new boolean on `InputEvent` itself. However, is this even a use case that comes up? What are concrete use scenarios in which author scripts need to behave differently when `beforeinput` event is triggered by execCommand?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/200#issuecomment-527335189