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

> > If `inputType` value is empty string, I think that the `beforeinput` event should **not** be cancelable since it does not make sense preventing default of unknown events. Note that Firefox will dispatch non-cancelable `beforeinput` event for undefined edit operation with empty `inputType`.
> 
> 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.

> If it is, I propose we just don't specify what it is. That way you can do what seems to make most sense in Firefox. I don't have a strong opinion though.

If there are somebody who don't want `beforeinput` events coming from `execCommand` called by their web apps, they must use a flag like `isDoingExecCommand`. I'd like to avoid such design.

> > 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 or setting new attribute value of `InputEvent`.

> Also, given that `beforeinput` has not been present on Firefox so far, I think those editors that rely on it will likely additionally rely on some alternative methods anyway and know that they will update the app once Firefox has it. Could you describe a case in which an app would break because of this?

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

```
editor.addEventListener("beforeinput", event => {
  if (event.inputType === "insertText") {
    let filteredData = event.data.replace(/Something/g, "OtherData");
    if (filteredData != event.data) {
      event.preventDefault();
      if (filteredData !== "") {
        document.execCommand("insertText", false, filteredData);
      }
      return;
    }
  }
});
```

This example does not assume that this event listener won't be called again and if the developer tests only with Chrome, this works as expected. So, it may cause unexpected result due to recursive call or infinite loop.

As a developer of browser, it may cause web-compat issues of recursive calls of a `beforeinput` event listener. If it does not prevent default but modifies selection and/or editor value, it'll create really complicated case. So, I'd like spec to avoid complicated cases as far as possible. (If `beforeinput` event would be fired later asynchronously as non-cancelable event, it'd become simpler, though.)

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