script: Fire input events when executing commands#43087
Merged
TimvdLippe merged 1 commit intoservo:mainfrom Mar 26, 2026
Merged
script: Fire input events when executing commands#43087TimvdLippe merged 1 commit intoservo:mainfrom
TimvdLippe merged 1 commit intoservo:mainfrom
Conversation
|
🔨 Triggering try run (#22817924525) for Linux (WPT) |
|
Test results for linux-wpt from try job (#22817924525): Flaky unexpected result (22)
Stable unexpected results that are known to be intermittent (11)
Stable unexpected results (3)
|
|
|
TimvdLippe
force-pushed
the
fire-events-for-commands
branch
from
1c5b6f7 to
1620072
Compare
TimvdLippe
commented
Mar 11, 2026
| * expectedExecCommandResult: expected bool result of execCommand(). | ||
| * expectedCommandSupported: expected bool result of queryCommandSupported(). | ||
| * expectedCommandEnabled: expected bool result of queryCommandEnabled(). | ||
| * beforeinputExpected: if "beforeinput" event shouldn't be fired, set |
Contributor
Author
There was a problem hiding this comment.
This was always set to null, essentially meaning it shouldn't fire.
servo-highfive
added
the
S-awaiting-review
Collaborator
|
🤖 Opened new upstream WPT pull request (web-platform-tests/wpt#58422) with upstreamable changes. |
Collaborator
|
✍ Updated existing upstream WPT pull request (web-platform-tests/wpt#58422) title and body. |
For any enabled command, we should fire corresponding beforeinput and input events. Also update a WPT test to make it clearer what the expected behavior is. None of the test expect a beforeinput event. Before, it would fail with "expected undefined, but got", which is not descriptive as a failure to what's happening. We are failing these tests, since this behavior is currently unspecced and also requires changes in the input element to work with text edits. Part of servo#25005 Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
TimvdLippe
force-pushed
the
fire-events-for-commands
branch
from
1620072 to
be2f62a
Compare
Collaborator
|
📝 Transplanted new upstreamable changes to existing upstream WPT pull request (web-platform-tests/wpt#58422). |
TimvdLippe
commented
Mar 26, 2026
| [In <input type="password">, execCommand("defaultParagraphSeparator", false, div), a[b\]c): execCommand() should return false] | ||
| expected: FAIL | ||
|
|
||
| [In <input type="password"> in contenteditable, execCommand("delete", false, null), ab[\]c): should not fire beforeinput event] |
Contributor
Author
There was a problem hiding this comment.
I haven't dug into why this shouldn't happen and why browsers skip it. For now, I prefer to stick to the spec and in the end figure out what's what.
mrobinson
approved these changes
Mar 26, 2026
Comment on lines
+262
to
+278
| if let Some(affected_editing_host) = affected_editing_host { | ||
| let event = InputEvent::new( | ||
| window, | ||
| None, | ||
| atom!("input"), | ||
| true, | ||
| false, | ||
| Some(window), | ||
| 0, | ||
| None, | ||
| false, | ||
| mapped_value_of_command(command), | ||
| CanGc::from_cx(cx), | ||
| ); | ||
| let event = event.upcast::<Event>(); | ||
| event.set_trusted(true); | ||
| event.fire(affected_editing_host.upcast(), CanGc::from_cx(cx)); |
Member
There was a problem hiding this comment.
How do you we know if the command actually modified the tree here such as if the paste contents were empty? It seems we will fire too many input events here. I guess this can be handled in a followup.
Contributor
Author
There was a problem hiding this comment.
Well, we don't. The spec doesn't tell us anything about it.
The thing is, I think it meant the logic that we have here: if the editing host was selected before, we should fire again on it.
Still, based on the test results there is a lot more software archaeology left to do to figure out what's the correct behavior here.
servo-highfive
removed
the
S-awaiting-review
servo-highfive
added
the
S-awaiting-merge
servo-highfive
removed
the
S-awaiting-merge
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For any enabled command, we should fire corresponding
beforeinput and input events.
Also update a WPT test to make it clearer what the
expected behavior is. None of the test expect a
beforeinput event. Before, it would fail with
"expected undefined, but got", which is not descriptive
as a failure to what's happening.
We are failing these tests, since this behavior is
currently unspecced and also requires changes in
the input element to work with text edits.
Part of #25005