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

>> I guess this would be like level 1 of the spec. Would not that be weird in webkit though, as they have implemented level 2 which means that all of the beforeinput events can be cancelled? Is the `beforeinput` that comes with `execCommand` in webkit currently cancelable?

> Well, WebKit can cancel `beforeinput` event which is caused by `execCommand("bold")`. That's what I concern.

Yes, I think that is the case for all beforeinput events in level 2. So JS running on Safari may assume that it can always cancel all beforeinput events. And that's really where we want to go anyway, so I don't think we should move away from that.

However, level 1 does not specify that "beforeinput cannot be cancelled". It just says "beforeinput cancelable: Undefined" so that also those who implement level 2 are compliant with level 1. I suggest we do the same in this case - we set it to "Undefined".

> > > But once browsers start to dispatch `beforeinput` for `execCommand`, there should be an API to distinguish whether coming `beforeinput` event is caused by `execCommand` or appending prefix or postfix to existing `inputType` values might be better. E.g., "execCommand-insertText". Then, I think that it won't break existing web apps which check `inputType` value of `beforeinput`.
> > 
> > I think such a prefix would break the usecase described by @scottfr above.
>
> I meant that if the caller of `execCommand` is browser itself or part of browser (i.e., addons), such prefix shouldn't be added because it looks like a user's intention from point of view of web apps. So, I meant that when `execCommand` is called by web contents, adding prefix

In that case I am OK with your suggestion. Some legacy apps may use `execCommand` directly in the app, but those apps then don't need to also use `beforeinput` events, at least not in the non-prefixed version. 

I would also be ok with just using an empty string as inputType in these cases. 

>  or setting new attribute value of `InputEvent`.

I don't think I understood this suggestion. How would that work?

> I'm thinking about like this case (it does not matter whether such web apps really exist or not):

Ok, there are other ways of breaking websites and there is a limit as to how much baby sitting one can expect. Also, if we made Chrome be compliant with whatever behavior we specify here, then the developer would already notice the issue when testing in Chrome. That being said, I am totally OK with execCommand being treated differently if it is executed on the website than if it is executed by an extension/addon.

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