The QNetworkReply::NetworkError enum mixes all kinds of errors into one
enum, HTTP errors, network errors, proxy errors, etc.
Instead of caring about it, we now say that HTTP requests were
successful if their response has any HTTP status code attached.
This allows LibWeb to display error pages when using Qt networking.
If an HTTP response fails with an error code (e.g 403) but still has
body content, we now render the content.
We only fall back to our own built-in error page if there's no body.
This picks up any upstream brew changes that haven't been pulled into
the default Azure VMs. For example, the ffmpeg dependency of qt is
currently broken in the 8 day old brew commit they are using.
Make sure that we set SERENITY_SOURCE_DIR in ctest, and make sure to
pass the test root to the CI job.
More overhaul of test-js 'test root' finding is needed however.
When a constructor has an optional dictionary as argument, and those
members are of type new string, make sure that we release_value()
setting the dictionary members.
Changed the Action destructor to fix an issue where global scoped
actions without shortcuts were not being properly unregistered from the
application. Previously, this could cause crashes when attempting to
open the command palette.
Before doing a check if offset_in_region + num_bytes of the transfer
descriptor are together more than NUM_TRANSFER_REGION_PAGES * PAGE_SIZE,
check that addition of both of these parameters will not simply overflow
which could lead to out-of-bounds read/write.
Fixes#17518.
Keycap emoji, for example, begin with ASCII digits. Instead, check the
first code point for the Emoji Unicode property.
On a profile of scrolling around on the welcome page in the Browser,
this raises the runtime percentage of Font::glyph_or_emoji_width from
about 0.8% to 1.3%.
On a profile of scrolling around on the welcome page in the Browser,
this drops the runtime percentage of Font::glyph_or_emoji_width from
about 70% to 0.8%.
We will currently only wrap "words" at ASCII spaces and, when wrapping,
will break up multi-code point emoji. This changes word wrapping to
behave as follows:
When the wrapping mode is "anywhere", use the iterator-based font width
computation overload. This will compute the width of multi-code point
emoji, whereas we currently only handle single-code point.
When the wrapping mode is "word", use the Unicode word segmentation
boundaries to break lines.
For example, consider the Pirate Flag emoji, which is the code point
sequence U+1F3F4 U+200D U+2620 U+FE0F. Our current emoji resolution does
not consider U+200D (Zero Width Joiner) as part of an emoji sequence.
Therefore fonts like Katica, which have a glyph for U+1F3F4, will draw
that glyph without checking if we have an emoji bitmap.
This removes some hard-coded code points and consults the UCD's code
point properties for emoji sequence components and variation selectors.
This recognizes the ZWJ code point as part of an emoji sequence.
When clicking a position within a TextEditor, we should interpret that
position as a visual location. That location should be converted to a
"physical" location before using it to set the physical cursor position.
For example, consider a document with 2 emoji, each consisting of 3 code
points. Visually, these will occupy 2 columns. When a mouse click occurs
between these columns, we need to convert the visual column number 1 to
the physical column number 3 when storing the new cursor location.
Currently, we compute the width of text one code point at a time. This
ignores grapheme clusters (emoji in particular). One effect of this is
when highlighting a multi-code point emoji. We will errantly increase
the highlight rect to the sum of all code point widths, rather than
just the width of the resolved emoji bitmap.