Both sides of the Editing internals now have to deal with some awkward
converting between UTF-8 and UTF-16, but the upside is that it
immediately exposed an issue with the `insertText` command: instead of
dealing with code units, it was iterating over code points causing the
selection to be updated only once instead of twice. This resulted in the
final selection potentially ending up in between a surrogate pair.
Fixes#5547 (pasting/typing surrogate pairs).
This exposed a few bugs which caused the following tests to behave
incorrectly:
- `tab-size-text-wrap.html`: This previously relied on a bug where we
incorrectly treated `white-space: pre` as allowing text wrapping. The
fix here is to implement the text-wrap CSS shorthand property.
- `execCommand-preserveWhitespace.html`: We don't correctly serialize
shorthand properties. This is covered by an existing FIXME in
`CSSStyleProperties::serialized()`
- `white-space-shorthand.html`: The last 5 subtests here fail as we
don't correctly handle shorthand properties in
`CSSStyleProperties::remove_property()`. This is covered by an
existing FIXME in said function.
Major browsers seem to preserve `white-space: pre/pre-wrap` styles in a
`<div>` when deleting the current selection through an editing command.
The idiomatic way to support this is to have a command with a "relevant
CSS property" to make sure the value is recorded and restored where
appropriate, however, no such command exists.
Create a custom command (internal to Ladybird) that implements this
behavior.
We do not fire `beforeinput` events since other browsers do not seem to
do so either.
The spec asks us to check whether a command's action modified the DOM
tree. This means adding or removing nodes and attributes, or changing
character data anywhere in the tree. We have
`Document::dom_tree_version()` for node updates, but for character data
a new version number is introduced that allows us to easily keep track
of any text changes in the entire tree.
Both Chrome and Firefox return `true` whenever the value string provided
is an invalid color or the current color. Spec issue raised:
https://github.com/w3c/editing/issues/476
The algorithm referenced to in the Editing spec whenever they talk about
obtaining the "resolved" style or value is actually implemented in
ResolvedCSSStyleDeclaration, so use that instead of going directly to
the computed styles.
