While debugging test failures, I discovered that I had reversed the
`is_allowed_child` arguments. That made a bunch more tests pass, but
then also started to fail tests as we weren't clearing the previous
value and computing loose equivalence.
Therefore, this PR fixes the reversal and implements the relevant parts
of some algorithms as to not regress too much. There are two new
failures related to how integers should be parsed, but tackling that
separately.
Part of #25005
Testing: WPT
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This makes the most basic tests pass for the font-size command. Future
PR's will continue the work,
but since this is already large enough, this is a good save point.
Part of #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>
There is a chicken and egg problem here: to be able to restore the state
of nodes, we need the implementation of several other commands. However,
those commands then need some of the algorithms that are implemented for
storing the state.
Therefore, this PR has no behavioral changes, but includes preparations
to be able to first implement the functionality of the relevant
commands.
To that end, several changes were necessary:
1. Remove BaseCommand and instead use CommandName enum to define
behavior. The majority of the action part of the commands still exists
in separate files for readability (turn off whitespace changes in the
diff to make things readable)
2. Change the usages of a DOMString to the new CommandName enum in the
methods of execCommand. Both to make the enum work, but also as an
improvement to avoid operating on strings.
3. The {value,state}_override values in document need to be a map, not a
single boolean. I didn't understand these when I first implemented it,
but now it's clearer to me what their structure is.
In the end, the relevant recording and restoring state is implemented,
to the extent that it is possible. It does some light-weight
interaction, but most of the code doesn't do anything yet since the
relevant commands aren't implemented.
Part of #25005
Testing: no behavioral changes, only preparations for future work
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
These two commands are intertwined with the delete command. By
implementing them now, it becomes easier to triage actual
implementation issues in the delete command.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This continues implementation of the delete command for
document.execCommand. Unfortunately, since these algorithms are vast
(30+ steps) and partial implementation leads to lots of issues, this PR
is "draw the rest of the owl".
I have tried to keep things manageable, by only implementing a couple of
extra steps in the delete command, so that we can focus on the "Delete
the selection" part.
To do that, several algorithms had to be implemented. Most of these
algorithms are required both by commands and by algorithms themselves,
which is why they are now exposed on a trait.
Additionally, all code now uses `cx`, to make sure it is up-to-date with
the ongoing migration and since some of the DOM API's it needs to call
already require `cx`.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
In preparation of introducing traits for some of these methods,
let's separate them from the basecommand trait. They are not
related to each other and it was making reasoning about where
lives what more difficult.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This implements a baseline for these tests. By implementing these dummy
methods, we avoid a lot of test expectation clutter when debugging these
tests to figure out why they aren't passing yet.
For the delete command, since it doesn't have any state or is
indeterminate, we always return the same.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
There is no specification for this, but there are relevant
WPT tests in `selection/contenteditable`. This PR implements
the required changes to make sure that when such an element
is focused (programmatically), it selects the correct node.
The implementation is therefore entirely reverse-engineered
based on existing browser behavior and commented to hopefully
make it make sense.
Part of #7492
Part of #12776
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
What I thought would be a small algorithm turns out required tons of
other implementations of various definitions, most of it around nodes.
Therefore, to keep things manageable, it only implements this algorithm
and relevant parts, but leaves the other parts of the delete command
untouched. For now, it is good if tests keep on working without
crashing. Later, once the full delete command is implemented, more tests
should be passing.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
The first step of `execCommand` commands is to figure out
if they are supported and enabled. Therefore, implement
these two pieces with only 1 command: delete.
The implementation of `delete` is currently mostly dummy,
to have at least something going. But the main part of
this change is to setup the infrastructure to figure out
when commands are supported and enabled.
For the first part, its simply the list of commands we
currently have implemented, which is only delete.
For the second part, we need to consider the active range
of the current selection and do various checks, as well as
check the presence of `contenteditable`.
Part of #25005
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
