Previously we would paint the cursor the entire height of the text
fragment - this didn't look great with large line-heights. Now we only
paint it the height of the actual text, with the top of the cursor
aligning with the font "ascent" and the bottom the "descent".
Previously we were using the document's window - this was both contrary
to spec and causing crashes when the document did not have a window (for
instance the `temp_document` in `HTMLParser::parse_html_fragment`.
This means we no longer crash when navigating between pages on
https://rocketlabcorp.com
The spec for checking the no-validate state ends with a default return
value of "false". However, we were only hitting this case for form-
associated elements. If the submitter is the form itself, we want to
enter the form validation steps.
We currently delete a single code unit. If the user presses backspace on
a multi code point emoji, they are going to expect the entire emoji to
be removed. This now matches the behavior of Chrome and Firefox.
This effectively reverts da26941b50.
When the user double-clicks a word on screen, they are interacting with
the rendered text, which has e.g. whitespace collapsing applied. If we
acquire word boundaries from the raw text, the resulting selection is
not right.
We still have issues with acquiring the right selection via APIs such as
`document.getSelection`. The offsets computed here are effectively then
applied to the raw text. But this issue is present all over EventHandler
and this patch at least makes the selection visually accurate.
This adapts the implementation of `is_mutable` to align more closely
with the spec. Specifically, it is now also taken into account whether
the element is enabled.
The spec and comments say "set field's user validity to true", but we
now actually set it to true and not false.
This passes one subtest in WPT's css/selectors/user-valid.html.
The current Color::interpolate_color method does not follow the specs
properly. Started improving it by handling premultiplied alpha in color
interpolation.
Only one WPT test covers this (color-transition-premultiplied), which we
currently pass due to a different approach in Color.mixed_with.
Currently you need to use Git Bash or alternative bash implementations
to fully run the pre-commit checks on Windows. This will now allow
for formatting changes without bash.
This ports the lexer to UTF-16 and deals with the immediate fallout up
to the AST. The AST will be dealt with in upcoming commits.
The lexer will still accept UTF-8 strings as input, and will transcode
them to UTF-16 for lexing. This doesn't actually incur a new allocation,
as we were already converting the input StringView to a ByteString for
each lexer.
One immediate logical benefit here is that we do not need to know off-
hand how many UTF-8 bytes some special code points occupy. They all
happen to be a single UTF-16 code unit. So instead of advancing the
lexer by 3 positions in some cases, we can just always advance by 1.
Currently, the lexer holds a ByteString, which is always heap-allocated.
When we create a copy of the lexer for the lookahead token, that token
will outlive the lexer copy. The token holds a couple of string views
into the lexer's source string. This is fine for now, because the source
string will be kept alive by the original lexer.
But if the lexer were to hold a String or Utf16String, short strings
will be stored on the stack due to SSO. Thus the token will hold views
into released stack data. We need to keep the lookahead lexer alive to
prevent UAF on views into its source string.
For the web, we allow a wobbly UTF-16 encoding (i.e. lonely surrogates
are permitted). Only in a few exceptional cases do we strictly require
valid UTF-16. As such, our `validate(AllowLonelySurrogates::Yes)` calls
will always succeed. It's a wasted effort to ever make such a check.
This patch eliminates such invocations. The validation methods will now
only check for strict UTF-16, and are only invoked when needed.
When we build a UTF-16 string, we currently always switch to the UTF-16
storage mode inside StringBuilder. Then when it comes time to create the
string, we switch the storage to ASCII if possible (by shifting the
underlying bytes up).
Instead, let's start out with ASCII storage and then switch to UTF-16
storage once we see a non-ASCII code point. For most strings, this will
avoid allocating 2x the memory, and avoids many ASCII validation calls.
We now define GenericLexer as a template to allow using it with UTF-16
strings. To keep existing users happy, the template is defined in the
Detail namespace. Then AK::GenericLexer is an alias for a char-based
view, and AK::Utf16GenericLexer is an alias for a char16-based view.
* Remove completely unused methods.
* Deduplicate methods that were overloaded with both StringView and
char const* parameters.
A future commit will templatize GenericLexer by char type. This patch
serves to make that a tiny bit easier.
