Re: [w3c/editing] Firefox + Chrome Desktop + Android: document.execCommand does not trigger a 'historyUndo' onbeforinput event after running document.execCommand('undo') (Issue #504)

johanneswilm left a comment (w3c/editing#504)

Call 2026-01-08:

> [torsdag 8 januari 2026] [17:24:17 CET] <dandclark> johanneswilm: Last one is 504. FF and Chrome desktop, Android. Question is whether execCommand triggers beforeinput on history undo 
[torsdag 8 januari 2026] [17:24:27 CET] <dandclark> ...didn't get full answer last time. Anyone on Chromium want to comment?
[torsdag 8 januari 2026] [17:25:53 CET] <dandclark> Rohan: question is should execCommand be considered user input event? Should we consider script calling command before input event? Say it's triggered on setTimeout after 5 seconds. OK to label as input or beforeinput triggered by user?
[torsdag 8 januari 2026] [17:26:18 CET] <dandclark> ...secondly, if web author wants to detect whether execCommand is doing undo or redo, can polyfill method to figure out when execCommand is being triggered
[torsdag 8 januari 2026] [17:26:33 CET] <dandclark> johanneswilm: Question is why we should have it only on user input
[torsdag 8 januari 2026] [17:26:56 CET] <dandclark> ...we still want input event for autocorrect, otherwise it messes up the DOM and you have to diff the DOM all the time
[torsdag 8 januari 2026] [17:27:11 CET] <dandclark> whsieh: I think the difference here is whether binding specifically is the one that triggered it
[torsdag 8 januari 2026] [17:27:44 CET] <dandclark> ...because the script itself is calling execCommand, it knows it will call it, whereas it doesn't know an autocorrect will happen because that comes from the engine on behalf of the user
[torsdag 8 januari 2026] [17:28:17 CET] <dandclark> johanneswilm: Spec says has to be triggered by user input, don't see what the point there is, because that would mean autocorrect under some circumstances might not be triggered. e.g. if you have async autocorrect that calls a service
[torsdag 8 januari 2026] [17:28:25 CET] <dandclark> ...comes back and tries to fix later
[torsdag 8 januari 2026] [17:28:36 CET] <dandclark> ...whereas with the other one we should be consistent
[torsdag 8 januari 2026] [17:28:50 CET] <dandclark> ...For some JS authors it might be more coherent if it does, but should be the same everywhere
[torsdag 8 januari 2026] [17:29:02 CET] <dandclark> whsieh: Another complication is extension authors or other library authors
[torsdag 8 januari 2026] [17:29:26 CET] <dandclark> johanneswilm: If you were to build grammarly sort of extension, how do we imagine they should do it?
[torsdag 8 januari 2026] [17:29:35 CET] <dandclark> ...with execCommand or non trusted beforeinput events they make themselves?
[torsdag 8 januari 2026] [17:30:02 CET] <dandclark> Rohan: Are you asking how grammarly detects undo?
[torsdag 8 januari 2026] [17:30:10 CET] <dandclark> johanneswilm: say grammarly wants to fix the spelling or reword something
[torsdag 8 januari 2026] [17:30:45 CET] <dandclark> ...until now, they have a library of known editing libraries, and they say "I'm in ckeditor or prosemirror, I do this based on where I am, like trigger click, to make it seem like the user did the action"
[torsdag 8 januari 2026] [17:30:54 CET] <dandclark> ...different strategies depending on which editor they're in
[torsdag 8 januari 2026] [17:31:11 CET] <dandclark> ...would be simpler if they could create their own input events
[torsdag 8 januari 2026] [17:31:19 CET] <dandclark> ...would work more like the browser built in behavior
[torsdag 8 januari 2026] [17:31:47 CET] <dandclark> ...they used to have a problem where when used in a smaller editor things would break. They're better now presumably because they know about more of these editors now.
[torsdag 8 januari 2026] [17:32:21 CET] <dandclark> ...If we say they should use execCommand for this kind of stuff, it's an argument for execCommand needing to trigger beforeinput
[torsdag 8 januari 2026] [17:32:37 CET] <dandclark> ...or are we against these kind of extensions?
[torsdag 8 januari 2026] [17:33:18 CET] <dandclark> Rohan: can we argue if execCommand was triggered in event handler, handled as user action, but if triggered async, not handled as user action?
[torsdag 8 januari 2026] [17:33:40 CET] <dandclark> ...but then we have to have beforeinput sent for undo execCommand too (only if from user synchronous action)
[torsdag 8 januari 2026] [17:34:14 CET] <dandclark> johanneswilm: But that means if they send something to a server and wait for the result <missed>
[torsdag 8 januari 2026] [17:35:03 CET] <dandclark> ...LLM does rewording, sends it back, want to make the replacement. If we tell them use an execCommand, now it's asynchronous.
[torsdag 8 januari 2026] [17:35:24 CET] <dandclark> ...but they probably won't just insert the replacement directly, they'd create bubble on top of the paragraph, confirm whether user really wants replacement.
[torsdag 8 januari 2026] [17:35:42 CET] <dandclark> ...if you click Accept button, now that triggers the actual replacement in the text, and it'd be synchronous.
[torsdag 8 januari 2026] [17:36:19 CET] <dandclark> ...But do we want to use execCommand for that?
[torsdag 8 januari 2026] [17:37:10 CET] <dandclark> ...Would be untrusted event, but that's OK for the JS editor
[torsdag 8 januari 2026] [17:37:44 CET] <dandclark> ...positive of using beforeinput directly is we don't have to rely on legacy tech, would work in EditContext as well
[torsdag 8 januari 2026] [17:38:05 CET] <dandclark> ...Wouldn't update anything automatically, but works as long as JS handles the event.
[torsdag 8 januari 2026] [17:38:18 CET] <dandclark> whsieh: Looks like the input event init dictionary only supports data, isComposing, and inputType
[torsdag 8 januari 2026] [17:38:22 CET] <dandclark> ...so not all the members
[torsdag 8 januari 2026] [17:38:36 CET] <dandclark> johanneswilm: So targetRanges isn't there?
[torsdag 8 januari 2026] [17:38:42 CET] <dandclark> whsieh: targetRanges and dataTransfer are missinug
[torsdag 8 januari 2026] [17:38:48 CET] <dandclark> johanneswilm: Could we add them?
[torsdag 8 januari 2026] [17:38:57 CET] <dandclark> whsieh: I think so, would need to update spec
[torsdag 8 januari 2026] [17:39:07 CET] <dandclark> johanneswilm: Let's add a new spec issue about adding those
[torsdag 8 januari 2026] [17:39:35 CET] <dandclark> ...Editors can choose to ignore the untrusted events, or not. Then don't have to rely on execCommand for this
[torsdag 8 januari 2026] [17:40:15 CET] <dandclark> ...To the original question. Is the wording good enough about that it has to be user triggered? Hope it'd also trigger if the browser has built in text replacements/autocorrect.
[torsdag 8 januari 2026] [17:40:26 CET] <dandclark> ...And execCommand, should it or should it not trigger beforeinput
[torsdag 8 januari 2026] [17:40:34 CET] <dandclark> whsieh: Async autocorrection should count as user triggered
[torsdag 8 januari 2026] [17:40:47 CET] <dandclark> johanneswilm: And that's clear enough with language as it is?
[torsdag 8 januari 2026] [17:40:53 CET] <dandclark> whsieh: Maybe worth note to clarify
[torsdag 8 januari 2026] [17:40:58 CET] <dandclark> johanneswilm: OK we'll add note
[torsdag 8 januari 2026] [17:41:17 CET] <dandclark> ...Main question, execCommand. Should or should not trigger beforeinput if we have these other things in place?
[torsdag 8 januari 2026] [17:41:28 CET] <dandclark> Rakesh: Spec today says it shouldn't
[torsdag 8 januari 2026] [17:41:36 CET] <dandclark> ...but I think we should be open to trigger if we should change it
[torsdag 8 januari 2026] [17:41:58 CET] <dandclark> ...based on discussion so far.
[torsdag 8 januari 2026] [17:42:05 CET] <dandclark> ...Don't have historical context
[torsdag 8 januari 2026] [17:42:27 CET] <dandclark> johanneswilm: Historical context for a lot of beforeinput was at different types tried to get rid of execCommand, or revive it, depending on who you ask
[torsdag 8 januari 2026] [17:42:46 CET] <dandclark> ...Some had approach that you only want to take user input, don't want other scripts to mess with things
[torsdag 8 januari 2026] [17:43:11 CET] <dandclark> ...which makes sense until you have editor that wants to take care of all of it, and when you have things coming in from other libraries that change the DOM and your editor doesn't know about it
[torsdag 8 januari 2026] [17:43:42 CET] <dandclark> johanneswilm: So Rakesh is saying maybe we should trigger beforeinput. This is the case in webkit?
[torsdag 8 januari 2026] [17:43:43 CET] <dandclark> whsieh: Yes
[torsdag 8 januari 2026] [17:44:14 CET] <dandclark> johanneswilm: And also used for testing? You have test runner that uses something like this? YOu're not thinking about changing it?
[torsdag 8 januari 2026] [17:44:17 CET] <dandclark> whsieh: Correct
[torsdag 8 januari 2026] [17:44:27 CET] <dandclark> johanneswilm: Are the others changing?
[torsdag 8 januari 2026] [17:44:36 CET] <dandclark> ...anyone from Chromium against changing?
[torsdag 8 januari 2026] [17:44:54 CET] <dandclark> Rakesh: I had question last time, if we have more use cases not possible without this capability
[torsdag 8 januari 2026] [17:45:06 CET] <dandclark> ...some examples of what happens if we don't support this. Would help build up a case
[torsdag 8 januari 2026] [17:45:31 CET] <dandclark> johanneswilm: Use case I see is, we talked about how to get beforeinput such that you can make untrusted events for editing extension. That can be recommended way.
[torsdag 8 januari 2026] [17:45:38 CET] <dandclark> ...but we don't control all extensions
[torsdag 8 januari 2026] [17:46:08 CET] <dandclark> ...Someone might build an extension or bit of JS on a Mac that creates these execCommands expecting an editor will pick them up, and it doesn't in Chromium
[torsdag 8 januari 2026] [17:46:34 CET] <dandclark> ...And right now you can't do it with untrusted events, so someone would be using execCommand for just this
[torsdag 8 januari 2026] [17:47:26 CET] Quit Ashish (~Ashish@2dbf1d10.publics.cloak) has left this server.
[torsdag 8 januari 2026] [17:47:36 CET] <dandclark> dandclark: We should get Mozilla comment before committing to change in Chromium
[torsdag 8 januari 2026] [17:47:50 CET] <dandclark> johanneswilm: Should we add comment requesting position from Firefox?
[torsdag 8 januari 2026] [17:48:09 CET] <dandclark> Rohan: Are we saying any execCommand could result in beforeinput?
[torsdag 8 januari 2026] [17:48:39 CET] <dandclark> ...Can it be misused by 3p extensions, e.g. send execCommand("insertText"), and it spoofs user input?
[torsdag 8 januari 2026] [17:49:00 CET] <dandclark> johanneswilm: Is the question whether the beforeinput event is trusted?
[torsdag 8 januari 2026] [17:49:20 CET] <dandclark> Rohan: Can JS distinguish untrusted vs trusted event?
[torsdag 8 januari 2026] [17:51:32 CET] <dandclark> dandclark: Yes
[torsdag 8 januari 2026] [17:51:38 CET] <dandclark> whsieh: I would not expect copy to trigger input events
[torsdag 8 januari 2026] [17:51:47 CET] <dandclark> johanneswilm: Because doesn't do anything to DOM
[torsdag 8 januari 2026] [17:51:49 CET] <dandclark> whsieh: Right
[torsdag 8 januari 2026] [17:52:17 CET] <dandclark> johanneswilm: System where you do everything with execCommand and it changes DOM, doesn't really work
[torsdag 8 januari 2026] [17:52:41 CET] <dandclark> ...but other parts of execCommand are used, like clipboard, table controls, undo/redo
[torsdag 8 januari 2026] [17:53:58 CET] <dandclark> ...The beforeinput event has this isTrusted flag?
[torsdag 8 januari 2026] [17:54:19 CET] <dandclark> whsieh: That flag is whether it's created via bindings? If it's created by the engine with execCommands, it would have trusted flag
[torsdag 8 januari 2026] [17:54:42 CET] <dandclark> johanneswilm: Right, either JS has to make their own input events, and you can see they aren't trusted so they come from other JS. But can circumvent using execCommand
[torsdag 8 januari 2026] [17:55:12 CET] <dandclark> whsieh: Ways to solve this problem would be new flag, like is user activation, or have a thing in spec that says if you're calling execCommand in input event, don't dispatch another
[torsdag 8 januari 2026] [17:55:29 CET] <dandclark> johanneswilm: Could we not say isTrusted is false if due to execCommand?
[torsdag 8 januari 2026] [17:55:47 CET] <dandclark> whsieh: Suppose it's 3rd option but would be deviation from notion of trusted event
[torsdag 8 januari 2026] [17:56:20 CET] <dandclark> johanneswilm: So action is we ask Firefox if willing to change?
[torsdag 8 januari 2026] [17:56:28 CET] <dandclark> ...or they want to push Safari to change
[torsdag 8 januari 2026] [17:56:42 CET] <dandclark> ...But none of us to see strong reason to see different behaviors for this

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

Message ID: <w3c/editing/issues/504/3891670807@github.com>