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

>Maybe a solution is to cover those execCommands that don't have a corresponding inputType by using just an empty string as inputType as I believe is what execCommand already does for the input event.

> I think that it's reasonable to make browsers dispatch beforeinput event if execCommand is used by addon because addon is a part of browser if you see it from point of view of web apps.

Both these seem completely reasonable to me.

> However, even in your case, the inputType the editor receives is insertFromPaste whereas it really should be insertReplacementText.

I fully agree that the latter is more correct, however using it would not work in many editors right now.

Broadly speaking, I think there are really four general classes of content editable editors:

1) **"Traditional" Editors**: E.g. old versions of CKEditor, TinyMCE or someone just sticking `contenteditable="true"` on a div. Here the DOM is the source of truth for the editor.
2) **"Controlled" Editors**: E.g. Quill or DraftJS. These editors differ from traditional editors in that they maintain their own representation of the document. Where in a "Traditional" editor, the DOM defines the document state, in these controlled editors the DOM is a reflection of the internal document state the editor owns. They pick up user inputs in a variety of ways (e.g. sometimes looking at DOM changes, sometimes looking at key events).
3) **Beforeinput "Controlled" Editors**: E.g. Slate>0.50 or to some extent Trix>1.2. These editors are like the controlled editors but they avoid the input confusion of (2) by responding to the `beforeinput` event and preventing its default.
4) **"Simulated" Editors**: E.g. Google Docs or Ace. User inputs are directed to a hidden editor where events are caught and responded to. The editing area the user sees and appears to be interacting with is drawn by the application separate from the true editing area.

Triggering `insertReplacementText` execCommands would work with (1) and (3), but could cause breakages with (2) and (4) as it's not something (2) and (4) are normally coded to respond to.  When an editor in (2) sees DOM changes that don't exist in their internal document state, they are liable to crash. An editor in (4) would likely completely ignore the `insertReplacementText` as they are only listening for specific user events. Going through the pasting route resolves this issue as all editors are coded to manage user pastes.

> I had your plugin still activated as I was typing an email. I had defined a shortcut "---" and the output included a tab. I had forgotten all about it as I was typing an email in gmail. Suddenly I activated it and the tab then wasn't pasted into the content of the email but instead activated some other function. I suddenly saw a message "This email has been marked as not important" or some such thing. 

Sorry for that!

I've found most extensions do their best to play well with others, but conflicts do happen. The most impactful one for us was when a popular extension with over 4,000,000 users decided to install a global event listener on the `body` of all pages that would call `preventDefault()` on any un`trusted` key events (this was unrelated to their actual functionality). We simulate backspace keys when deleting shortcuts so that broke that functionality for a bunch of users. They've since reverted that change.

We would really love some sort `send_key` addon/extensions API/permission where we could truly simulate key strokes (like in ChromeDriver). We've suggested it to the Chrome Extensions DevRel but I don't think it's in the cards at the moment.

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