I ended up rewriting the tests to remove the part that attempts to test “cancellation” of an edit operation — because as far as I can see, there is nothing in the spec to support that calling any event’s preventDefault() should cause any edit operation to be cancelled. And I couldn’t find that there was any way at all to cancel an edit operation.

And anyway, the test as written had not even been calling the edit operations themselves, but was instead just firing a textInput event with a particular input type, and relying on the fact that the implementation happened to be written to expect to get all the necessary data from that event.

The implementation of the textInput event had other properties beyond just what’s in the IDL and required by the spec. So the implementation had sort of just been using the event as a convenience to hang those other properties on. And that worked OK as long as the textInput event got fired prior to beforeinput — but not if the firing order of those events were changed.

But the event-firing order needed changing.

So I rewrote it all such that the code now instead passes on the actual data directly, and only puts what’s actually necessary into the textInput event (when it eventually gets fired later).