The path is now relative to the Serenity source directory, and later
parts of the URL path are not simply discarded. This allows links into
subsection man pages to be checked correctly.
This is necessary for subclassing SectionNode, but generally allows more
code to rely on path() virtual dispatch always finding the correct path
regardless of the static type.
The responsible code was actually casting everything to a SectionNode
pointer, violating type safety all over the place and leading to
frequent crashes. I'm surprised this was not exhibited before; I guess
my recent changes made this bug surface.
- 👐 U+1F450 Open Hands
- 🙌 U+1F64C Raising Hands is modified to match 👐 and other hand emoji.
- ✊ U+270A Raised Fist
- ✴️ U+2734 Eight-Pointed Star
- ❇️ U+2747 Sparkle
- ❎ U+274E Cross Mark Button
- ❤️🔥 U+2764 U+200D U+1F525 Heart on Fire
- 〰️ U+3030 Wavy Dash
If text-top or text-bottom are given as values for the vertical-align
property, actually use them and calculate the respective position of
the element.
The actual calculations done (using the font_size, descent, etc.) are
not exactly how I imagined them when reading the spec, but the results
seem acceptable when compared to other browsers.
Both Element and DOMTokenList are GC-allocated objects so they can just
mark each other instead of using the old strong/weak pattern we use in
ref-counting ownership models.
The existing `load_from_gml()` methods look the same as before from the
outside. Inside though, they now forward to `try_load_from_gml()` which
returns Error when things go wrong. It also now calls the `try_create()`
factory method for Objects instead of the `construct()` one.
If a page fault occurs while interrupts are disabled, we were wrongly
enabling interrupts right away in the page fault handler.
Instead, we should only do this if interrupts were enabled when the
page fault occurred.
Currently, `ls` crashes when printing certain byte sequences.
This is likely due to an out-of-bounds error when iterating
through the `StringView` representing the file name to be printed.
We switch to using an index-based for loop to a range-based
for loop. This fixes#16678.
This allows you to enter TRUE or FALSE in a SQL statement for BOOLEAN
types. Note that this differs from SQLite, which requires entering 1 or
0 for BOOLEANs; having explicit keywords feels a bit more natural.
We were already handling the rmdir("..") case by refusing to remove
directories that were not empty.
This patch removes a FIXME from January 2019 and adds a test. :^)
Dr. POSIX says that we should reject attempts to rmdir() the file named
"." so this patch does exactly that. We also add a test.
This solves a FIXME from January 2019. :^)
The only difference between these two values is that `hidden` has
different behaviour for border conflict resolution for border-collapsed
tables in table layout, which we don't have yet.
This gets rid of the main border around the repository information on
the GitHub repository page.
The underlying reason is an unconditional call to consume(), even if
there is no reason to expect that the string continues.
This crash was discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42354
This bug exists since the code was first written in April 2021:
13abbc5ea8
This old symbolication exploit proof of concept doesn't link on aarch64
with the Clang toolchain. We should revisit these as as whole to see if
they're worth keeping around in general.
This is a bit messy: The spec says that PCSXYZ and PCSLAB are the only
valid profile connection spaces -- except for DeviceLink profles, where
all data color spaces are valid.
So this uses the existing ColorSpace enum for profile connection spaces
instead of adding a dedicated enum, to not duplicate all the color space
parsing and printing code. That matches what the spec does, too.
This saves about 100 lines of code, at the expense of less type
safety -- but further down the line we probably want to be able to
compare data color spaces and profile connection spaces, so the type
safety would likely get in the way then. (But if not, we can change
things around once we get to that point.)
Unlike client{X,Y} which is relative to the current viewport, these
offsets are relative to the left edge of the document (i.e they take
scroll offset into account).