Firefox + Chrome Desktop + Android: document.execCommand does not trigger a 'historyUndo' onbeforinput event after running document.execCommand('undo')

[michael]

Repro: https://w3c.github.io/editing/repros/504.html

Also see michael/web-editing#16 for context.

[johanneswilm]

Step 4 in https://w3c.github.io/editing/docs/execCommand/#methods-to-query-and-execute-commands seems to specify that if a command is in the Miscellaneous commands section, then a beforeInput event should not be triggered. So this looks like it is spec compliant. However, I don't know why it should be excluded from triggering the beforeInput event. @zcorpan any idea?

[michael]

Addition: It is only fired in Webkit at the moment.

[johanneswilm]

Call 2025-12-11:

08:32 undo/redo are in the section of commands that should not trigger beforeinput…
08:32 https://www.w3.org/TR/input-events-2/#event-type-beforeinput - there is a mention about what needs to happen for before input here
08:32 unclear why this is the case
08:34 Ashish: long-standing behavior of not firing beforeinput event when handling execCommand-triggered commands
08:34 (in Chrome)
08:35 johanneswilm: isn't execCommand used to test input events?
08:37 Rakesh: "UA should not dispatch these events unless user-triggered"
08:38 johanneswilm: either the browser behavior should adjust to the execCommand spec or the spec needs to reflect what most browser engines do today
08:40 Rohan: intent of beforeinput is to give web authors a signal of user intent. but if they're the ones triggering it why do we need to send the event?
08:41 johanneswilm: LLMs might be interesting to consider — should asynchronously inserted text be treated as "user input"?
08:42 johanneswilm: need to be able to distinguish between human-generated text and system-generated text
08:42 johanneswilm: insertReplacementText vs. insertText kind of solves this
08:43 Michael: a button that the user clicks to trigger undo is, functionally, input triggered by the user
08:44 Michael: this issue came out of the other workaround to reset the DOM when undoing
08:45 Rakesh: if we do have use cases that are blocked for web developers due to not firing these events, let's note that
08:46 q+
08:46 johanneswilm: if it turns out execCommand gives a different result it probably is not a good test strat
08:48 1. Can we add to interop?
08:48 Rakesh: there are interop-related points of contact on our team, I can relay
08:49 2. Maybe we can consider adding a version of execCommand that triggers editing commands in a way that simulates user input
08:49 (WebKit's test runner has these primitives)

[michael]

I'll try to summarize the state of the discussion here, please correct me where I'm wrong:

There's two conflicting interpretations at the moment:

1. execCommand is considered a normal user input, hence onbeforeinput is fired (Safari)
2. execCommand is considered not a normal user input, hence no onbeforeinput is fired (Chrome, Firefox)

Considerations / Use Cases:

• execCommand is currently used for testing (WPT), which would assume it behaves like a normal user input
• if we decided that execCommand should not trigger input events, there should be some other documented way how to trigger events programmatically (for testing)
• Which behavior would an editor developer usually expect? E.g. if they render an undo button which when clicked runs execCommand('undo')?

---

Personally, I was expecting that triggering an undo programmatically (via execCommand) would result in the exact same behavior as pressing Cmd+Z or clicking Edit>Undo, so I was surprised that Firefox/Chrome did not trigger a 'historyUndo' onbeforinput event.