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 web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

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 web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

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

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

With these changes, we now fail the minimum set of tests.
That is to say: we don't fail any test that no other browser
fails. All test failures therefore match at least 1 other
browser.

The one exception is the updated test expectation. That's
because all browsers fail this test in the exact same way,
hence updating the expectation. We fail it, since I don't know
how browsers reach to that point. I think it's related to
traversal of the contained children and the order that they
are traversed in. Unfortunately my attempts at fixing that
have not been fruitful, so leaving that one for now.

Part of web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

With these changes, we now fail the minimum set of tests.
That is to say: we don't fail any test that no other browser
fails. All test failures therefore match at least 1 other
browser.

The one exception is the updated test expectation. That's
because all browsers fail this test in the exact same way,
hence updating the expectation. We fail it, since I don't know
how browsers reach to that point. I think it's related to
traversal of the contained children and the order that they
are traversed in. Unfortunately my attempts at fixing that
have not been fruitful, so leaving that one for now.

Part of web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

With these changes, we now fail the minimum set of tests.
That is to say: we don't fail any test that no other browser
fails. All test failures therefore match at least 1 other
browser.

The one exception is the updated test expectation. That's
because all browsers fail this test in the exact same way,
hence updating the expectation. We fail it, since I don't know
how browsers reach to that point. I think it's related to
traversal of the contained children and the order that they
are traversed in. Unfortunately my attempts at fixing that
have not been fruitful, so leaving that one for now.

Part of web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

With these changes, we now fail the minimum set of tests.
That is to say: we don't fail any test that no other browser
fails. All test failures therefore match at least 1 other
browser.

The one exception is the updated test expectation. That's
because all browsers fail this test in the exact same way,
hence updating the expectation. We fail it, since I don't know
how browsers reach to that point. I think it's related to
traversal of the contained children and the order that they
are traversed in. Unfortunately my attempts at fixing that
have not been fruitful, so leaving that one for now.

Part of #25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

There is a tricky bit of text nodes that also consider their ancestors
effectively contained. To make that properly work, when computing all
nodes that are effectively contained, we now traverse from the
editing host, rather than the common ancestor container.

However, that then would fail numerous tests. That's because when
text nodes are moved, their positions would be updated to be the
new parent, instead of the original text node. The spec states that
this is implicit, but turns out it is not. It might be that this is
related to the implementation of ranges in Servo, but for now let's
make it explicit it when moving. I also think this is nicer anyways,
since we should retain the original selection and that should be
the text node.

Overall, this makes more tests pass, while also fail others. I will
continue investigating why, but unfortunately that's the nature of
this suite of WPT tests.

Lastly, during debugging I needed to know the exact text contents of
these text nodes. Therefore, update the way to format nodes to also
consider characterdata, for nicer debugging experience.

Part of web-platform-tests#25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>

There is a tricky bit of text nodes that also consider their ancestors
effectively contained. To make that properly work, when computing all
nodes that are effectively contained, we now traverse from the
editing host, rather than the common ancestor container.

However, that then would fail numerous tests. That's because when
text nodes are moved, their positions would be updated to be the
new parent, instead of the original text node. The spec states that
this is implicit, but turns out it is not. It might be that this is
related to the implementation of ranges in Servo, but for now let's
make it explicit it when moving. I also think this is nicer anyways,
since we should retain the original selection and that should be
the text node.

Overall, this makes more tests pass, while also fail others. I will
continue investigating why, but unfortunately that's the nature of
this suite of WPT tests.

Lastly, during debugging I needed to know the exact text contents of
these text nodes. Therefore, update the way to format nodes to also
consider characterdata, for nicer debugging experience.

Part of #25005

Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>